How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

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!

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.