Daniel Doubrovkine (aka dB.) is one of the tallest engineers at Art.sy. He founded and exited a successful Swiss start-up in the 90s, worked for Microsoft Corp. in Redmond, specializing in security and authentication, dabbled in large scale social networking and ran a big team that developed an expensive Enterprise product in NYC. After turning open-source cheerleader a few years ago in the worlds of C++, Java and .NET, he converted himself to Ruby and has been slowly unlearning everything he learned in the last 15 years of software practice. Daniel has posted 46 posts at DZone. You can read more from them at their website. View Full User Profile

Five Ways to Torture Candidates in a Technical Interview

  • submit to reddit

When I joined Microsoft in ‘99 I was taught how to properly interview candidates. I was shown the wheel of competencies, a kind of a wheel of fortune where a color represents the candidate’s technical skill, ability to solve complicated problems or to communicate with their peers. Each  slice included broad interviewing suggestions, which often gave birth to elaborate puzzles. What could possibly be the best way to figure out whether the candidate is capable of thinking out of the box? Ask them why the potholes are round. Can they crank complex working code on a deadline? Ask them to implement a memory allocator in 30 minutes or less in C.

As the interviewee I’ve been given all these problems myself. I hated the puzzles, but I loved the code, even though I failed my share of coding interviews - one that I still remember was for a team within the Windows division, where I was asked to implement “malloc”, which I think went well, and then some other simple string manipulation in C that I totally missed because I didn’t listen to the problem carefully enough. I also bombed an interview at Google because I’m still not capable of doing a power of 2 after 4 years of hardcore college math.

Below are some well-researched and widely practiced techniques of breaking even the best interview candidate.


1. Whiteboarding

Ask an expert C++ level candidate to reverse a string in C.


This is guaranteed to be insulting to someone who has demonstrable success developing software in any relevant technology. It’s the first thing taught in any C class and should take you about 45 seconds. The fact that many just cannot do it is irrelevant, those should never make it past a phone screen. By giving this problem to someone you’re telling them that you don’t trust their resume and that their demonstrable experience is completely irrelevant. It’s a single, efficient blow to their ego.

2. Dehydration, Starvation and Solitary Confinement

Create a system in which the candidate does not have access to food, water or bathroom for extended hours and spends significant lone time in a small, preferably windowless space.


After each 1 hour interview, grab the next interviewer and interrogate the previous interviewer on the strengths and weaknesses of the candidate. There’s a series of canned questions to ask: What did you ask the candidate? What did they answer? How well did they do? What are the areas that they failed at and that need to be drilled further by the next interviewer?

This is a clever management technique that extends the interview schedule by about an hour. The candidate is left in a conference room alone, while observing their incomplete solution for the previous problem on the whiteboard. I’ve never seen a candidate walk out to find a bathroom or a glass of water - they don’t want the next interviewer to come to an empty room. The bladder will speak in the middle of the next round, at which point it’s not polite to ask to take a break either. Lunch will be skipped since everything is running so late and the CEO only has a 2:00-2:01 PM window to meet.

3. Pitchcapping

Ask the candidate to solve a simple problem in a completely different way, until you run out of time.


This is akin to pouring hot pitch on a candidate’s head, letting it cool and then restarting again. It’s theoretically a good exercise if the question is complex, but it’s guaranteed to stump even the best programmer on the fifth “Can you please implement fib(x) in yet another completely different way?” iteration. You’ve succeeded when the candidate gives up and says that there’s just no other reasonable way to do this, at which point you end the interview, shake their hand and walk out.

4. Keelhauling

Lead the candidate to a stopping point where they are drowning in a problem, then maintain them underwater.


Pretend to be helpful. Finally, give them a few minutes to concentrate and solve the problem alone. Have a smoke outside. Come back 15 minutes later to see no real progress. Ask them to explain what they wrote and keep a concerned look. Finally, shoot them with a “this is good, although pretty far from working, and we’re out of time”.

5. Flaying

Ask an executive-level, non-programming interviewee to implement a sort algorithm of their choosing.


Guaranteed to remove any kind of skin that one developed over their 20 year long career. In small companies low rank developers interview their future executive-level bosses. Guide the candidate to talk about how they got started and wait for the story about their small, yet relevant programming experience. Mention with a smile that you’re impressed by their solid CS foundation and that “they must surely be able to implement a sort function with a bit of help, even today”. The candidate will definitely bite. The next step is a whiteboard.

About 10 years ago, one CTO candidate told me that he would walk out of the room if I was actually seriously about asking him to code a sort. He complied though, got sweaty and nervous and finally broke down with the next interrogator after me. His interview was cut short.


In a future post I will talk about great ways to interview people. In the meantime, I would like to apologize to all my past interview detainees and ask you to post your torture stories in the comments!

Published at DZone with permission of its author, Daniel Doubrovkine. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Robert Saulnier replied on Wed, 2012/12/12 - 9:02am

Why would you want to ask a CTO to code during an interview? Do you plan on having the CTO write some code if you hire that person?

Lukas Eder replied on Sun, 2013/03/31 - 2:57am

In the past, I have refused to continue talking with those interviewers that employed "funny" techniques like these. For instance, I once had to tell a joke, because the interviewer read in some article just like yours, that they can distinguish those guys that would choose to tell dirty jokes to strangers (and thus be unprofessional). How unprofessional by himself...

Encountering a company for the first time leaves a big impression on both sides. I try to be as professional as I expect the opposite side to be. What I read here is a bit embarassing for those companies you've done interviews for. I hope they've noticed...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.