4 ms·

The tactic I’ve employed at my company when vetting a candidate is to give them a link to a small code sample (usually a single class or service for backend, so

The tactic I’ve employed at my company when vetting a candidate is to give them a link to a small code sample (usually a single class or service for backend, some JS/CSS for front end) to review the day before the interview. The code itself will include some obvious issues, some less obvious issues, some language specific opportunities for improvement, etc. We then walk through their notes (if they made any), and the code sample itself together. I have them make any observations, critiques, suggestions, or other thoughts together with me. This gives me an idea of how they think, what issues they saw, how they would improve things, how familiar they are with the specific language, and coding in general. It also gives an opportunity for some light “conflict” resolution , if I push back on their thoughts. This has worked really well. Those that don’t do well on the spot can make notes ahead of time (but aren’t expected to spend time coding for hours) and those that are confident can walk through it live.

rubylark 4y ago
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.
lenocinor 4y ago
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.
rapht 4y ago
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,
phreack 4y ago
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.
cableshaft 4y ago
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.
bambax 4y ago
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.
jdthedisciple 4y ago
I really like your approach and wish more employers employed it (haHaa). As an applicant I'd certainly appreciate it.
dcminter 4y ago
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.
LocalPCGuy 4y ago
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.

rubylark 4y ago

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.

lenocinor 4y ago

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.

rapht 4y ago

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,

phreack 4y ago

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.

cableshaft 4y ago

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.

bambax 4y ago

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.

jdthedisciple 4y ago

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

dcminter 4y ago

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.

LocalPCGuy 4y ago

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.