Scribd
Upload
9 views4 pages

Sde Interview Experiences

Uploaded by

j20559584
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views4 pages

Sde Interview Experiences

Uploaded by

j20559584
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

SDE 2 INTERVIEW EXPERIENCES

1. Nutanix
Role: MTS 2
Team: Distributed systems

Round 1:
2 dsa medium questions
Q1: Find the k most frequent elements in a given array
Eg: [1,1,1,2,2,3] k = 2. ans = [1,2]
What went well?
-> Was able to give both nlogn and nlogk approach using min heap
What went wrong?
-> Made error while adding the element in heap {a,b} instead of {b,a}.
Took some time to debug this but interviewer pointed out in a haste.

Q2: Given an array of heights, find the cut height such that the total area above and
below cut is equal.
Ex : [3,4,5]
If i make a cut at h = 2,
we have the total area above = 6
total area below = 6
Think of it as a bar graph and you make a horizontal cut across the bar graph;
Ex: [1,1,1]
If i make a cut at h = .5
we have total area above = 1.5
total area below = 1.5
What didn't go well?
-> I assumed the answer would be an integer and went with a best effort
solution for this. Interviewer pointed out it will be a decimal with the second example (only
then i could come up with bsearch).
-> I did not pay heed to double comparison in cpp. used == and made a
fool of myself.
What went well ->
-> Was able to write the code for it. But only after interviewer hints (sed life)

Observations:
1. Interviewer was focussed on micro optimisations. First question where k>size of
array i needed to return the unique elements all together w/o going to min heap.
2. Interviewer was hasty and would provide me hints very quickly. This means i need to
be faster at thinking the solutions and writing it down on the very first go
3. Need to pay attention to things like double conversions and comparisons. I knew
those and it totally slipped my mind during the interview.
4. Double comparison:
#include <cmath>
#include <iostream>
using namespace std;

// function to check if the given numbers are equal or not


// using epsilon value
bool isEqual(double a, double b, double epsilon)
{
return fabs(a - b) < epsilon;
}

int main()
{

// initializing two numbers


double num1 = 0.3 * 3 + 0.1;
double num2 = 1.0;

// checking if numbers are equal or not


if (isEqual(num1, num2, 1e-6)) {
cout << "Given numbers are equal." << endl;
}
else {
cout << "Given numbers are not equal." << endl;
}
return 0;
}

Overall: would rate myself 3/5 given the massive hint I needed for the second problem and
the double comparison mishap.

Verdict: Move to round 2.

Round 2: HLD + LLD + Resume

Originally intended to be a 1hr round. It went on for 2 hours.

First I was grilled on my resume. Interviewer asked me about a significant impactful work
done.

Post that he started with an ice breaker question. Why do you need distributed systems?
-> Explain this using a single instance sql server example. Expanded on scalability, reliability
and availability. Post that discussed replication. techniques suitable for read heavy and write
heavy workloads.

Then he moved to hackerrank and asked for a preferred language. I told cpp.
Then the interviewer asked me to design a task scheduler and I instantly switched to golang.

Started off with assumptions here regarding the LLD bit (Made a mistake here. Interviewer
wanted a mix of both. I was keen on impl bits, clarified this later).

Divided my JobScheduler into 4 components


1. JobFetcher
2. JobDispatcher
3. JobExecutor
4. JobNotifier

Wrote some interfaces around it.


Had some discussions around dbs, queues, and scale.

What went well :


1. Good communication. There was no mute periods
2. Was able to explain similar concurrency patterns in go with that in java since the
interviewer was from a java background.
3. Was able to discuss trade offs
4. Was able to explain certain design decisions around databases, queues and how it
would scale later.

What went wrong:


1. Assuming LLD and working code is needed had led me to some assumptions around
the way i store jobs. i used a cmap but later moved to db after a mix of lld and hld
was asked by interviewer.
2. Since there were 4 moving parts it introduced 4 points of failure. This had to be
justified to interviewer.

Overall I'd rate myself 3/5 on this interview. Good experience.

Round 3: Resume and Distributed systems


While I expected it to be a design round this was different from it.
The interviewer had gone through my resume thoroughly and asked me in detail about each
technology i had mentioned. I had mongo,cockroach,postgres and es on my resume. So the
nature of interview was highly centered around database internals.

1. Isolation levels and how its implemented in postgresql


2. What is vacuuming and why is it not good in postgresql
3. He asked me to comment on is no sql really needed? Or are ppl just being lazy.
Explained him design philosophies behind the two databases, how schema on read
and schema on write works. Why attaching a new column to relational db is not a
good idea and how document dbs like mongo help in this case.
4. Then he wanted to know why did my current firm move away from cockroach to
postgres. explained him how i interpret a distributed system. How adding multiple
layers on top of a design leads to increased latency rather than having the concepts
baked in already. (this started because i explained him how cockroach even though
is a k-v store at core, provides strong acid guarantees)
5. How indexes work. How would deletion of column works.
6. What is the need of idempotency in distributed systems. Explained this with some
examples. but the keyword he was looking for was network partition and split brain.
7. Asked me regarding 2 phase commits and what happens when one node out of x
nodes fail in a 2pc. Then follow up on how quorums can improve the performance of
2pc ( this was new to me since 2pc doesn't have quorum as a design choice.
Apparently dynamoDb does this)
8. Since i had worked with temporal, the interviewer wanted to know how event replay
in temporal works.
9. Asked me about need of coordinators in a distributed systems. How do you mitigate
coordinates being the bottleneck in the system. Explained him about failover standby
coordinators (took it from load balancers primary secondary configuration). Then he
asked how does the second coordinator know where to pick up from. Explained him
how write ahead logs works and heartbeat mechanisms around it.
10. Since i had java and go both on resume he asked me to compare and contrast go
and java. I explained him from a developer's pov. then from language internals.

Overall it was more of a candid conversation than an interview.

What went well:


1. I was able to control the flow of interview
2. I was able to deduce and relate my learnings in distributed systems well
3. It felt like a conversation

What didn't go well:


1. I should have been able to explain idempotency in context of distributed systems
better.
2. I could have gone into more depth at some places.

Overall i feel this was a 4/5 interview.

Round 4: Director + rapid fire:


It was a 30 mins chit chat with director. What my expectations are, what i am expected to do.
Then was asked some basic stuff like tcp vs udp. Design a website counter. How is a query
executed on sql server.

Overall it was not very deep. It was fairly simple round.

Verdict: Selected.

You might also like