3 ms·

I agree that there are many reasons why someone can "fail" a technical interview (I wrote about some of them here[0]). It's just as important "how" you solve th

I agree that there are many reasons why someone can "fail" a technical interview (I wrote about some of them here[0]). It's just as important "how" you solve the problem and that you come off as someone people will want to work with. [0] http://reginaldlong.com/i-failed-my-tech-interview-and-i-dont-know-why/ http://reginaldlong.com/i-failed-my-tech-interview-and-i-don...

axoltl 9y ago
Neither of which can be solved by 'studying' for an interview. I'll argue that the required skills are on the interviewer, not the interviewee. As an interviewer I'm trying to assess a skillset, be it social, be it technical. All the points you listed (except #5) I deem to be a failure on the part of the interviewer: 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.
- NTDF9 9y ago
  There is a wide disparity between "embedded" type software dev interviews and "crud" type software interviews. Amazon, Google, FB are CRUD type. Their interviews are exclusively Algos and data struct memorization and slapping perfect code on the whiteboard in 20 mins.
- voltagex_ 9y ago
  > void func(char* arg) { char buf[128]; strcpy(buf, arg); } I'd much rather solve this one - and talk about maintaining legacy systems, than any of the other interviews I've done.
  - axoltl 9y ago
    I'll be honest with you, I've conducted some attrocious interviews. It's taken me a long time, and a LOT of interviews, to get to the point where I feel like I'm not horribly butchering them most of the time. 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.
axoltl 9y ago
Out of curiosity, were your interviewers largely young? 20-28 years old?
- reggylong 9y ago
  Most of my interviewers were between 20-30s, but I've also interviewed with people old enough to be my parents.
  - falcolas 9y ago
    That still leaves more than a few decades worth of an active programming lifespan out. Assuming you're in your early 20's, your parents are likely in their early 40's; retirement age is still in the late 60's. 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.

axoltl 9y ago

Neither of which can be solved by 'studying' for an interview. I'll argue that the required skills are on the interviewer, not the interviewee. As an interviewer I'm trying to assess a skillset, be it social, be it technical. All the points you listed (except #5) I deem to be a failure on the part of the interviewer: 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.

NTDF9 9y ago
There is a wide disparity between "embedded" type software dev interviews and "crud" type software interviews. Amazon, Google, FB are CRUD type. Their interviews are exclusively Algos and data struct memorization and slapping perfect code on the whiteboard in 20 mins.
voltagex_ 9y ago
> void func(char* arg) { char buf[128]; strcpy(buf, arg); } I'd much rather solve this one - and talk about maintaining legacy systems, than any of the other interviews I've done.
- axoltl 9y ago
  I'll be honest with you, I've conducted some attrocious interviews. It's taken me a long time, and a LOT of interviews, to get to the point where I feel like I'm not horribly butchering them most of the time. 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.

axoltl 9y ago

Out of curiosity, were your interviewers largely young? 20-28 years old?

reggylong 9y ago
Most of my interviewers were between 20-30s, but I've also interviewed with people old enough to be my parents.
- falcolas 9y ago
  That still leaves more than a few decades worth of an active programming lifespan out. Assuming you're in your early 20's, your parents are likely in their early 40's; retirement age is still in the late 60's. 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.