How to give a technical software interview

September 30, 2014 3:21 PM

I’m a software developer at a small startup. I'm giving a technical interview next week. My CTO will be doing the interview with me, and wants me to ask several algorithms/data structures whiteboard questions. I have very little experience either giving or receiving technical interviews, no traditional CS background, and am stressed out by whiteboard coding (also just socially anxious in general). What questions should I ask?

The only other technical interview I've given went poorly - I didn't have time to prepare in advance, then blurted out a question I hadn't thought through fully, then froze with anxiety when the candidate started asking me follow-up questions which made me feel like the interview-ee rather than the interviewer.

My goals are:

• Come up with a couple solid whiteboard-ey questions I can recycle in future interviews. Not too easy, not too hard...something that will give useful insight into the candidate’s thought processes even if they don’t know the answer, and has good follow-ups I can ask if they know the answer immediately.
• Prepare for likely related questions/alternate approaches/common mistakes the candidate may make in response, and how to handle them. I understand that I can't anticipate everything and it's OK not to know everything, but I want to project confidence and be able to mostly stay one step ahead in our discussion.

I've tried to google for ideas about questions to ask, but got overwhelmed because there are so many out there and I don't know which will work well in practice.

I'm also interested in reading about alternate interview techniques that don't involve CS101/whiteboards, since I'm not convinced they're all that useful...but that's a secondary concern. For right now it's more important for me to get comfortable doing things the traditional way.

The person I’m interviewing this week is junior to me, but is a web dev (whereas I do desktop/embedded stuff). Later on, though, I’ll also be interviewing people who are senior to me.

posted by introcosm to Work & Money (15 answers total)

Make sure to start with some warmup questions, and have a way to signal your co-interviewer if the person has bombed and its time to finish the technical part and wrap things up. Also, don't let the interviewee know how many questions you have prepared. It's incredibly painful to watch someone out of their depth struggle through the harder questions!
posted by Blue Jello Elf at 3:37 PM on September 30, 2014

i'd suggest getting a programming book that has a lot of problems (+solutions) in it. then you can pick and choose something that you understand well. here are a couple books i've found useful:

Programming Challenges
Cracking the ... Interview
Puzzles for Programmers and Pros
posted by bruceo at 3:39 PM on September 30, 2014

Also, it can be useful to have problems that are somewhat ambiguous and see if the person asks questions, and which ones they ask.

I mostly interview sql developers, so we'll give them a toy database and ask them to, say, query for how many employees work at each store. We look to see if they notice start/termination dates in the employee table, etc. They don't have to notice everything, but we like to see which things they do ask for clarifications on.
posted by Blue Jello Elf at 3:42 PM on September 30, 2014

I would suggest that a lot of the popular brain teasers, algorithm, "write compilable code" type questions are primary designed to stoke the ego of the interviewer than to figure out if the the candidate knows anything.

I've had the best luck by asking essentially open-ended questions that invite the interviewed to go as deep as they can or think is appropriate. For example, if this is a web thing, perhaps something like "how is a typical web request made?" This seemingly simple (and relevant) question can open a rabbithole of discussion with simple "how does that work" type prompts.

One of my personal favorites, which may or may not be relevant here, is "how does a database do a query". You have the whole part about how a connection works, how the parser works, how the database goes from a parser to a plan, what role statistics play in that, how the database can make poor choices, to IO, to software knowing about hardware to determine plans, to what results look like etc.
posted by H. Roark at 3:47 PM on September 30, 2014 [3 favorites]

There has been quite a bit of criticism of whiteboarding, since you're not interviewing for whiteboarding skills and people do not write code with a pen. Similarly, I would recommend not delving too deeply into data structures and algos unless they directly relate to the work the hired person will do. Many times they are simply trivia quizzes that do nobody good in an environment where the balance of power is wildly skewed, the interviewee is understandably nervous because who knows if you're going to ask about patricia tries or some other thing that nobody but CS people have been forced to learn and at any rate do not regularly use.

By those tokens, there is a lot of support (or at least I like the way the discussions are going in this direction) for work-sample tests. You give them problems to solve in code, on a computer, which if you're good you make directly relevant to the business you work for. Matasano sensei tptacek on the topic.

"Thought processes" is highly unscientific, and a persons ability to articulate a solution they can write is different than their ability to solve a problem. Ask about the problem, not their public speaking skills.
posted by rhizome at 3:57 PM on September 30, 2014 [5 favorites]

Can you take note of any problem that comes up where someone collaborated with a co-worker on figuring out what the best way forward was?

Pick a problem like that - something that you don't know the answer to, or has no objectively best answer and collaborate with the interviewee on figuring out the best way forward together, as if you two were equals and co-workers on a team, working together.
(though this might not help much if your work challenges usually come out of in-house technology that is opaque to outsiders)

It seems a more informative approach to me, because you also get a feel of working with the person, not just whether they're capable, and it might also alleviate some of the social anxiety that comes from the interrogation/prisoner model of interviewing.

If people typically don't collaborate on problems at your work, then ignore me. :)
posted by anonymisc at 4:18 PM on September 30, 2014

Ask candidates to bring a laptop with them and expect to write code, in their language of choice, using their own tools. Ask them very easy questions. Make the questions harder as they show more skill. Your job is to find out what they know, not what they don't. Watch how they interact with their computer. That can't be taught, it's gained through experience. Someone who is comfortable at their own workstation using their own tools will be more comfortable showing you what they know.

The downside of this is that as an interviewee, it doesn't feel good, and it is very hard to gauge how they did.

Whiteboard coding sucks, and even as I've gotten to the point where I can do it, I never feel like it is good code, and its easy to miss simple things outside of a development context.
posted by bensherman at 4:24 PM on September 30, 2014 [1 favorite]

Technical interview questions are dicey.

Here's why: suppose you ask a tricky question and the candidate absolutely nails it immediately.
Did the otherwise lackluster candidate know the solution of the cuff or did the candidate derive the solution in her head in blazing speed and solve it on the spot. If it's the latter, you want to hire her immediately. You might not want to hire the former.

When I was out of college, one of my interviews included me being asked to write a solution to The Towers of Hanoi problem. I knew the solution cold, so I asked the return question, "recursive or non-recursive?" which rocked the interviewer on his heels.

You should seriously discuss the usefulness of this process with your CTO. Puzzles and "in the moment" coding are very common, but are frequently done without any decent goal to the questions which makes the questions themselves either inherently unfair or useless.

Therefore, you should think about what qualities you would like to see in your candidate and ask questions that go for that particular outcome.

For example, I would like to be able so ask, "so, are you a good communicator?" and every candidate on the planet that wants the job will say, "of course!" So instead, I will pick one of the items of either work or personal experience and have the candidate tell me about it. I'll ask tons of in the moment questions to drive the candidate into extreme detail. If he was really working on this project, he should be able to talk for HOURS about it. Pick something you know a little (or a lot about) and ask Devil's advocate questions, "couldn't you just use a hashtable?" "Why not keep it all in memory?" "Shouldn't a greedy algorithm do well enough?" All of these should get your candidate talking and you should be able to judge if the communication is clear and if it's not, do some active listening.

I will often ask a relatively simple coding question, knowing full well that most people will introduce bugs in the process. And the reason I keep it simple is that I will count the number of bugs that I see and report that by saying, "I see n bugs in your code: p syntax errors and q run time errors, please fix them." Now you get to see process (and communication). A good candidate will start methodically going over her code and talking about assumptions and sample input and output. Some candidates need a nudge to get going (example input, etc). After the bugs are out, I ask them to gauge the performance in time and memory.

Before I start the coding, I make it clear that I DO NOT CARE about whether they can remember the arguments to all the flavors of exec(). I tell the candidate that for all intents and purposes, I'm google. You don't know something, ask me and I'll answer. If I don't know it, we'll make it up on the spot and agree on the answer. This is to remove the pressure that this is not a trivia contest and that they don't need to answer in the form of a question.

So before I got in, I have several specific things I want to see in a candidate:
passion
knowledge
communication
experience
critical thinking

And I ask questions that masquerade as standard interview questions but are subterfuge to figure out if they have those qualities.

Notice that puzzle solving isn't up there. Notice that knowledge of a specific language or technical skill isn't up there. It's nice to have overlap with those things, but if you give me a person with a technical skill and all the rest, I know that the candidate will be able to do what I need in short order. See also a blog I wrote on this.
posted by plinth at 4:29 PM on September 30, 2014 [6 favorites]

I will also add for the record that candidates I interview remember my interviews for a very long time afterwards. Sometimes they get together and ask what question I asked them to do.

In an interview, I'm able to ask 3 maybe 4 major questions and I allocate about 1.5 hours for the interview and it's an intense block of time. Each question will inevitably spawn dozens of follow up questions which you can't anticipate including questions that don't have any particularly gi=ood answer like "is the null string pointer a palindrome?"

As such, as a human courtesy, I make sure that they have the opportunity to take a bathroom break or have a glass of water.
posted by plinth at 4:41 PM on September 30, 2014

How did you get this job?
posted by oceanjesse at 5:57 PM on September 30, 2014

Response by poster: How did you get this job?

By answering technical questions to my interviewers' satisfaction!

My issue isn't that I have literally never been to an interview, or that I don't understand the subject matter I work on. It's more that I've only interviewed a few times so don't have a very large body of experience to draw from, and am intimidated by the performative/artificial nature of the traditional process.

I like a lot of the advice people have given here about alternate methods that give a more authentic picture of a candidate. I'm not sure if I'll be able to put them into practice this time around, but I want to move in that direction in the future.
posted by introcosm at 6:47 PM on September 30, 2014

If you're going to stick with a straight whiteboarding approach for now, a few suggestions:

- write the problem yourself first. Write down the time you start, write down when you predict you'll finish, write out the solution on a whiteboard, debug it/mentally unit test it/whatever until you're satisfied, write down the time you do finish, then type it all into a computer and run the tests you wrote.
- now make someone else do that. Without telling them the problem in advance. And resist the temptation to think, "Oh, I know Jim, I'm sure he really meant..." Actually make him write out every line, and actually make yourself read what he writes.

It's easy to fool yourself into underestimating the difficulty of a question whose answer you know. If you asked me, "how long would it take you to implement file globbing if you only had to handle . and * ?" I would have said twenty minutes. I forgot how long I actually took, but it was more like forty.
posted by d. z. wang at 9:12 PM on September 30, 2014

I do a lot of technical interviews for new starters at our company so have experience in the field (whether it's good or not is subjective).

I would start off by thinking about what you want to know to hire this person: Is there any particular technologies they should know? Is there any way to structure stuff that you favour?

We often ask about how they re-use code which often shows up the minefield of people talking about static methods, util classes or (heavy) inheritance whereas composition is the favoured route for us.

We never have a question that can disqualify them. The idea is to get a breadth of their knowledge, see how well they can present and defend ideas even if they are difference and get a feel for personality and whether they'll fit within the (small) team.

We have a take-home test for actual coding because I find the whiteboard sessions can be very awkward in an interview. No-one codes that well with someone watching (unless they've done peer programming for a number of years) and coding with someone watching in a high pressure situation is enough to make you forget everything you know (or you only end up hiring extremely confident people which is not a requirement for a dev team).
posted by Wysawyg at 5:16 AM on October 1, 2014 [1 favorite]

If I had more time I'd write something shorter..instead I'll paste what I've written for some coworkers learning to interview. This is focused on phone interviews w/collaborative website for coding, but it can be used as a simpler whiteboard problem too...

---
A recent question...

"I'm looking for some good phone screen questions. Ones I can think of:

• Merge part of merge sort
• Reversing a linked list
• Finding the intersection of two arrays
• Returning the nth fibonnaci number"

My answer:

I like finding the intersection of two lists of integers the best, it's not the most common question interview in the books so less likely to have been practiced, and it has just enough complexity to be a decent coding problem for phone screens - you can cover data structures, algorithms, and performance, and coding, as well as testing (do they walk through their code with sample data?). Everyone can identify the O(n^2) solution, most can hack away at the O(nLogn) solution with parallel cursors, and a few figure out that using hashtable can get them O(n).

Also, you can easily twist the question for advanced candidates to report duplicates in the output:

// Write an efficient method to find the intersection of two lists of integers,
// with performance better than O(n^2):
//
// intersection([1 2 3 4], [2 4 6 8]) => [2 4]

Normally, you ask for this output:

[1 2 3 4], [2 4 6 8] => [2 4]
[1 2 2 3 4], [2 4 6 8] => [2 4]
[1 2 3 4], [2 2 4 6 8] => [2 4]
[1 2 2 3 4], [2 2 4 6 8] => [2 4]
[1 2 2 3 4], [2 2 2 4 6 8] => [2 4]
[1 2 2 2 3 4], [2 2 4 6 8] => [2 4]

but if they can do that easily, ask them to modify their solution to report matching duplicates:

[1 2 3 4], [2 4 6 8] => [2 4]
[1 2 2 3 4], [2 4 6 8] => [2 4]
[1 2 3 4], [2 2 4 6 8] => [2 4]
[1 2 2 3 4], [2 2 4 6 8] => [2 2 4]
[1 2 2 3 4], [2 2 2 4 6 8] => [2 2 4]
[1 2 2 2 3 4], [2 2 4 6 8] => [2 2 4]

Sometimes the candidate's solution does the 2nd version as a bug, have them fix it first, then ask for the second.

Obviously you should already be familiar with the solutions yourself before asking :)

Merge is an OK question, but there's really only one solution, so it's hard to increase the challenge if you have a good candidate - they'll answer it quickly and then you're stuck trying to find another question.

Reversing a linked list & returning nth fibonnaci are classic interview questions so usually the candidate has already studied them. If you do ask them, let the candidate solve it and then have the candidate solve it again using recursion (or iteration if they used recursion originally). This challenges most candidates b/c they've only studied (memorized) one approach and can't actually solve the problem. Also many candidates have challenges converting iteration to recursion and back (even though they are logically equivalent).

Be sure to get them to discuss the solution with you before starting their coding, and emphasize that we're looking for the "best solution" so the n^2 approach isn't good enough (that's the worst possible solution). Don't want them to waste time coding n^2 just to have you ask them to try again with something better. Much better to discuss it first and get them started on a better solution.
posted by jpeacock at 4:46 PM on October 2, 2014

Also, if I find a candidate already knows the solution to my question (studied in the past or was recently asked the same thing) then instead of desperately trying to use a backup question I'll turn the interview around and ask them to teach me the question: what's the best solution, and why? what are common mistakes/pitfalls? what assumptions are made, how do you test the solution?
posted by jpeacock at 4:48 PM on October 2, 2014