4 ms·

I had a similar interview once. They asked me to bring in a code sample, we discussed what it did and various details around it, then he showed me an actual cla

I had a similar interview once. They asked me to bring in a code sample, we discussed what it did and various details around it, then he showed me an actual class in their codebase (printed out), asked me to explain figure out and explain everything it did, and there was also a couple mistakes included in the code for me to find as well. The guy also asked me a few relatively simple technical questions, then said "Okay I know you can handle the job, let's see what you really know," asked me some really difficult questions, when I said "I don't know" to some he actually spent a few minutes teaching me the concepts. That same guy was the lead programmer on some famous arcade games, btw. Did a lot of assembly programming back in the day. He had serious technical chops. Got a job offer the next day. 1 interview, 1 interviewer, a little over 30 minutes spent. Best interview experience I ever had. If more interviews were like that I wouldn't feel dread every time I felt the urge to switch jobs. Also if that's all someone of his caliber needed to determine applicant quality, I don't see why everyone else feels the need to go through all this other bullshit.

naniwaduni 4y ago
> Also if that's all someone of his caliber needed to determine applicant quality, I don't see why everyone else feels the need to go through all this other bullshit. Flipping it around, it takes someone of that caliber to be able to determine applicant quality with just that. Can we replicate it without having to spend some of your most valuable employee-hours, let alone in a way that doesn't leave you open to accusations of all sorts of bias?
- rapht 4y ago
  If successful recruiting is not worth some of your best employee-hours -- which by the way should be the same people in charge in their respective fields -- then what is?
q7xvh97o2pDhNrh 4y ago
I like this a lot! Somehow, that little detail you mentioned at the beginning -- that he had the code printed out for you -- feels like a lovely subtle little green flag. I've long felt that 60 minutes is sufficient for a competent interviewer. In a past life, I was tasked with interview-slots where I had to both assess the candidate and double-check the signal other interviewers got, and I would spend: - 5 minutes on intros, - 15 minutes on a coding exercise, - 15 minutes on architecture discussion about something else, - 15 minutes on "behavioral" questions about something other than *those*, - and 5-10 minutes on "do you have any questions for me." Et voila -- that was the whole interview. A fairly simple recipe, and it turns out it yielded equal-or-better signal than all the other interviewers on the loop put together, > 90% of the time. I love the fact that your interviewer got it down to 30 minutes, and I especially love that part of his interview process was sitting down with the candidate and teaching something new on-the-fly. (If I had to guess, it was your "I don't know" -- followed by how you handled being taught something -- that sealed the deal for your offer.) That sounds way better than a lot of the behavioral-question fluff that I used to try when I was still finding my way as an interviewer. I'll have to give that a try.

naniwaduni 4y ago

> Also if that's all someone of his caliber needed to determine applicant quality, I don't see why everyone else feels the need to go through all this other bullshit. Flipping it around, it takes someone of that caliber to be able to determine applicant quality with just that. Can we replicate it without having to spend some of your most valuable employee-hours, let alone in a way that doesn't leave you open to accusations of all sorts of bias?

rapht 4y ago
If successful recruiting is not worth some of your best employee-hours -- which by the way should be the same people in charge in their respective fields -- then what is?

q7xvh97o2pDhNrh 4y ago

I like this a lot! Somehow, that little detail you mentioned at the beginning -- that he had the code printed out for you -- feels like a lovely subtle little green flag. I've long felt that 60 minutes is sufficient for a competent interviewer. In a past life, I was tasked with interview-slots where I had to both assess the candidate and double-check the signal other interviewers got, and I would spend: - 5 minutes on intros, - 15 minutes on a coding exercise, - 15 minutes on architecture discussion about something else, - 15 minutes on "behavioral" questions about something other than *those*, - and 5-10 minutes on "do you have any questions for me." Et voila -- that was the whole interview. A fairly simple recipe, and it turns out it yielded equal-or-better signal than all the other interviewers on the loop put together, > 90% of the time. I love the fact that your interviewer got it down to 30 minutes, and I especially love that part of his interview process was sitting down with the candidate and teaching something new on-the-fly. (If I had to guess, it was your "I don't know" -- followed by how you handled being taught something -- that sealed the deal for your offer.) That sounds way better than a lot of the behavioral-question fluff that I used to try when I was still finding my way as an interviewer. I'll have to give that a try.