Technical Interview Practices

You can ask candidates for a piece of code they've written in the past and discuss the code with them. That should be adequate.

I don't do live coding in my interviews because it's silly. We talk about the person's past projects, their contributions to it, insights the gained, mistakes they made and how they would avoid them again, etc. Sometimes they may share some code they wrote and we walk through it and they explain it to me and why they made the choices they made. Sometimes I'll make suggestions and see how well they receive that feedback.I'm looking for people who can demonstrate tha

I've done over 800 interviews, and I call bullshit on this.I've spent 30min talking to candidates about their projects, experience, tech they used, choices made, etc. and been super excited and positive about them.Then I ask them to find the intersection of two lists in better than O(n^2) and they completely fail to write functional code in their preferred language in the next 30 minutes. This isn't even "leetcode" level of challenge.If I'm hiring you to be

I am super bad at interviewing — I just want to see how well the candidate can code :-(

I heard you guys make your interviewees write code for you, then you go ahead and use that code..

I prefer to ask the applicant to either submit code that they are proud of, or to do a small toy problem if they don't have anything they can readily share. Then we talk through their code during the interview, asking them questions like: what problem were you trying to solve, did you solve it, what problems did you run into along the way, how would you design this code differently, and of course any specific questions if we find glaring technical issues in their code.I've found thi

Seeing whether someone can code has to be part of the recipe. It's surprising how many candidates can't demonstrate basic coding ability. The coding component is better if it requires the candidate to ask questions about what is required, where they can demonstrate their thought process and approach to the problem at hand. Anything that requires more than 15 minutes on a whiteboard is probably overkill. Brainteasers and the like are mostly a waste of time.

I've been doing this for a long time now. I present the candidate with a function (on paper) that compiles and runs. It does the job but it does everything poorly: an embedded connection string, leaves the connection open, no error handling, bad variable names, no comments, etc... EVERY candidate can find something wrong with this code and the things they pick up is informative. Juniors can find the easy stuff, more senior-level folks find the deeper flaws about the basic structure of the c

I've found that I get a lot more signal out of asking people to actually solve a problem by writing a program than by asking them about past experience. Hence I spend most of the interview time on the former. It's surprisingly common for people to be able to talk about something in a way that sounds impressive, but then after seeing their actual coding skills you realize they were likely not a star performer on the team and were just summarizing the work that others mostly did (which

I do tests for prospective candidates, but my approach is slightly different.After the interview I email them a small unfinished program. I then give them a set of instructions on what I would like them to do to finish it off, and they can then do it at home on their own dev setup; with the internet and any other resource they would normally use for development.I give a coding style guide, and in the areas where some specific technique is required I make that explicit.The app has a few