Hacker News Reader

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.

> 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?

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?

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.

Yeah I'm baffled why people do such weird random leetcode challenges when this option is so good. At a place where I used to worked they'd give people a couple of class and ERD diagrams with obvious issues and give them about an hour for them to think about and how they'd change things.

It was such a good trigger for discussion and we could easily measure a candidate's fit in moments. Some would just go "yeah this code's perfect" and not argue at all, some would spend ages with irrelevant details, and the couple of people who immediately looked at the diagram and spotted the most glaring OOP issues turned out to be great at their job.

There is a strong argument in favor of this, which is engineers spend more time reading code than writing it. It's a very important skill that whiteboard coding doesn't assess at all.

That's the kind of thing I'd be fairly happy with as an applicant.

One swift interview process I did included a single short page of code and the invitation to (with pen and paper) review it; I was given some time to think about it on my own and then to talk it over with the technical interviewer.

I liked that one and they had what I thought was an above average quality of developer when I joined. Anecdotal but interesting.

I really like this strategy. After one god awful experience at a company that led me to quitting after 3 months, I will not work for a company that doesn't show me a snippet of their own code. The whole experience at that terrible job could have been avoided if I could see their coding practices: early returns, gotos everywhere in C++, 7(!) different languages that compile into one >1GB executable over the course of an hour. They only did white boarding questions which told them a lot about me, but told me nothing about them.

I've had 4ish interviews since that job, and all of them gave an on-the-spot code reading assignment to walk through their code to find the bugs. It let me see who has old style coding standards, who takes advantage of modern C++ utilities, and that the interviewers are competent enough to walk through coding examples, too.

I really like your approach and wish more employers employed it (haHaa). As an applicant I'd certainly appreciate it.

This resembles to what we do in a very different field (finance) at my organisation for positions with less than 10 years of experience-- only the prep is time limited, at our offices,

I’ve used a similar interview technique at a previous job and it was great. The candidates and I both generally liked it a lot.

We've done this with real-world PRs from our code base (chosen from a project that matches the job they are interviewing for), especially for more senior devs it is good to see how they parse through the code, what they look for, comments they make, and how they communicate.

The one thing I didn't feel just asking for review/discussion accounted well for was their ability to build/add something new to the code, and so we have followed up the code review/discussion with a very specific/small exercise to evaluate the process (architecture, pseudo-code) they'd use to do that, and then discuss that as well.