I recently published a post How NOT to design Netflix in your 45-minute System Design Interview?. First, surprisingly, it got pretty popular. Secon...
For further actions, you may consider blocking this person and/or reporting abuse
Please ignore this article, and this comment.
Not really. Some good points are made. But this kind of absolute articles don't do good to anyone.
Never assume what your interviewer wants. Please just stop assuming that interviewers want short or long answers. You will need to find your way to what the other person in front of you wants.
We all misunderstand things. Point number one shows that we don't know what the interviewer really wants.
Do whatever you want. It is a whiteboard, you can erase things, evolve, do pseudocode first. You have an editor in front of you? Much better. Just do something. Think loud, because again you don't know what the interviewer is looking for, so you better dump whatever you're thinking.
Sean said it better in another comment.
Test, check, run. If you're in a whiteboard test you cannot "run" your code, you're the cpu of your code, you better run it. Not only you will find bugs, but you will have some time again to explain your solution.
As an interviewer.
Tell the people what you want and stop them if they're talking to much. Direct them to the topics you're interested.
No, the candidate didn't misunderstand the problem. You didn't explain it correctly.
You've seen this problem 100 times in 100 candidates. Perhaps this candidate sees the problem for the first time. Understand that. I know you like the problem, but it is your... BIAS, do not force into the candidate.
Sean said it better.
Drive the candidates to speak loud about the solution they've implemented. If you arrive to the end of the interview and you haven't told them to speak or asked any question and expects them to say anything... you might have set the wrong expectations.
And for candidates.
If your interviewer is not clear about how much detail of things they want... they might not care at all about the interview, you, or whatever you end up doing in that place if you get hired.
If you make a wrong assumption and the interviewer is there to point at you at the end and say "HAHA", you might not want to work in this kind of environment where everybody is waiting you to FAIL to punish you.
If your interviewer is looking for their solution, you might want to run away from a place where there is no alternative ways. Sooner or later the "my way or the highway" will push you out.
You might not want to go to a place where they do not evolve software.
Back to point two, you will miss things, but if the interviewer is waiting for you to fail, it might not be a good sign of culture and environment.
Thank you for this! All of your points make sense. :)
Disagree with 4. As an interviewer (for Amazon), I will never accept a candidate without a working solution. But I will accept a candidate who writes down the brute force and then walks me through a better solution. I've failed many candidates who tried to come up with the perfect algorithm and ended up empty-handed.
Glad you revealed Amazon uses the similar idiot technique for an interview, this solidifies my opinion that I will NEVER want to work for Amazon if it cares so little about it's employees that their test is a fucking toy programming test.
If talking to me doesn't convince you I know my shit, you're doing a bad job at interviewing.
Totally agree with you, Sean. It was geared towards candidates who don't even try to find the solution and become content with the brute-force solution. Some candidates don't even try to come out of their comfort zone and that's a red flag.
IMHO both are red flags: candidate who writes only the perfect solution, candidate who writes only the worst solution.
The solution should be a way to discuss (and learn) as many things as you can.
4 is tricky. I am also an interviewer and agree with Sean. Some working code is more important to me than the optimal version. But I don't work at a tech company and my department is producing code that runs mostly in batch jobs. We do have an upper time limit, but as long as the job is nowhere near this limit, we don't waste time on optimizing code.
However when I applied recently for a job at a tech company I focused on delivering a working solution with a test case. It had O(n). My interviewer wanted me to optimize the code and I came up with an O(log n) solution. But it wasn't good enough. I got declined. Directly after the interview I found a clever solution with O(1) on SO.
But I would never decline a candidate in an interview who doesn't find the clever solution, as long as I can talk about optimizations with him and see that he knows this stuff.
agreed.
It's crazy to me when people seem to constantly give advice on how to do at shitty interviews, when really the answer is that if you are put in front of an interviewer who doesn't understand the "gibberish" you're talking of, you're talking to the wrong person and the company doesn't care about you -> apply for a job somewhere else.
"Your interviewer is calibrated on a certain question and expects you to come up with the optimized solution to get a Hire" and "If she’s asking for a solution with linear time complexity and O(1) memory complexity" are also great red flags on places that don't give a shit about how talented, or passionate you are, or how quickly you learn actually relevant things. You can do better, apply for a job somewhere else.
This is a very helpful article. Thank you!