[0] http://reginaldlong.com/i-failed-my-tech-interview-and-i-don...
1. You didn't make enough progress on the problem.
The interviewer didn't properly explain the scope of the problem.
2. You were too slow and didn't get through all of the problems.
Again, a scoping issue on the interviewer's part. When I interview, I have one _single_ problem that I pose. I interview largely for embedded security folks, so I write this on the board:
void func(char* arg) { char buf[128]; strcpy(buf, arg); }
And I will ask them to explain what's wrong with it. Most people can answer that question fairly easily. With this simple problem on the table I now have a base to start more questions from:
- How would you fix this problem? - In a large codebase, how would you find this problem? - What's really happening here on a machine level? - What sort of system-level mitigations can I implement?
These are all branches I can take, and once I feel like the interviewee is out of his depth in any one of them I jump back up. I'm trying to assess the skill-level of the person, not whether they meet some minimum bar (though I can do this afterwards, of course).
3. Your solution is complicated.
There's a little bit of shared blame here. The playing-field isn't level in an interview as the interviewee is naturally going to be nervous. You as an interviewer can help level it a little by giving some broad strokes help. "That solution looks like it might end up a little complicated. Do you think there's a better one?". I have given no technical guidance, but have given the interviewee a chance to step back and think.
4. You didn't communicate well enough with the interviewer
Everyone works differently. When I'm solving a problem, I like being alone in my head to focus. Some people more naturally are drawn towards collaborative problem solving. An interviewer that doesn't recognize this is a poor interviewer.
You as the interviewer can solve the problem by occasionally asking "So, what direction are you thinking?" or "Can you write me out on the whiteboard where you're going?".
5. You ignored the interviewer's feedback
Yeah, ok, that one is on you.
I'd much rather solve this one - and talk about maintaining legacy systems, than any of the other interviews I've done.
I found that I really like the "pick one problem/question and go deep and/or wide" approach. The above example I can go anywhere from compilers (Q: "What's the smallest function a compiler could legally output given this code?" (I love this one :P)) to C (Q: "How is 'buf' allocated?") to static analysis (Q: "How would I statically find all instances of this pattern?") to exploits (Q: "How would I exploit this vulnerability?") to mitigations (Q: "Given a stack overflow, what can I do to make it harder to exploit for the attacker?"), etc. etc. etc.
It's a young field, there will be more and more people who code into their 70's and 80's as the first batch of gen-X matures.