I Can See You

the problem(s) with tech interviews

I browse LinkedIn sometimes. I’m not sure if it’s a valuable use of my time, or if it’s just filling muscle memory vacated by my near abandonment from twitter…or …X (?!?), but it’s where I sometimes find Five for Friday fodder, and more often these days, where I catch up on how many of my old friends and colleagues are looking for work - and how many of those folks have to go through poor interviews.

As Appropriate

I spent about fifteen years at Microsoft as an “As Appropriate” - aka AA or AsApp interviewer. This meant that I was the last interviewer on an interview loop - assuming the candidate didn’t fail spectacularly before then. They saw me if it was “appropriate”. Sometimes, a candidate would be all hires, then my job was to sell them on the role and work on closing (or, in rare cases, veto the loop). More often, there was some split in the yeses and nos, an my role was to figure out what was what and make an overall recommendation. There was a little bit of orchestration / directing during the loop to make sure the loop covered the right balance of appropriate technical and behavioral questions, and to make sure as many holes were investigated before they got to me - which I liked, because I had some say over fixing bad interviews in real time.

Over those fifteen years, I probably did a few hundred AsApp interviews, and I got pretty good (wish I still had the stats) on figuring out who would do well, and who wouldn’t. I fucked up a few for sure, but I like interviewing, and it was a good experience overall.

F&%# Leetcode

I’ve written thousands of lines of code that has been used by millions of people. Yes, I had to work for Microsoft to make that claim, but it’s still sort of cool, and I hope says something about my abilities. I’ve even convinced a few smart people over the years that I’m good at writing scalable, production code.

Also, I’ve never, ever passed a coding interview.

Ever!

I want to blame my introversion, but I think I’d need a larger case study. I’m really good at coding when I write a little of the code, and then stop and think about it. I reflect. I think. Eventually (sometimes minutes, sometimes hours later), it clicks and I can write it. Or it could just be that I read books on defensive programming and code structure before I mastered, mostly learned a single language, so maybe my approach is just different.

When I moved to XBox, I went through a full interview loop. Everyone loved me except for the clown who wanted me to write a multithread safe sorting algorithm on the whiteboard.

After I finished, the hiring manager told me I failed the tech interview, and asked me if I could do another “technical” interview. Fortunately, I was confident enough at that stage of my career that I told him that I wouldn’t, because I would fail that one too, and that if he had any doubts about my ability to contribute significantly to the project, that he could pass, and I’d find another gig. He thought about it for about 4 minutes before calling me back and giving me the job.

And I wrote a shit ton of code on that project.

But, but, but…

How will we know if they know how to code?

Here’s the hard part. Look - I understand that you can’t just take a candidate’s word for it - nor can you tell from their resume. But - do you know what’s more important than someone’s ability to regurgitate an algorithm under pressure? For one, their ability to collaborate and problem solve. So instead of asking them cold to write FizzBuzz (which I actually think is a pretty fun algo to write), start by asking something like,

“we want a program that counts from 1 to 100. But, every number that’s divisible by 3 we replace with the word ‘Fizz’. For every number divisible by 5, we replace it with ‘Buzz’, and for anything divisible by 3 AND 5, we replace it with ‘FizzBuzz’. What do you think are going to be the biggest challenges in writing this program?”

And then you can start by talking about code. They may talk about the challenge being able to handle the FizzBuzz part, and you can ask them why. You can ask them what the flow would look like (are they using if/else, case statements, or even a full on OO approach) to get an idea of how they approach the problem. Ask them how they’d test it (TDD has more than one use!). Honestly, writing the code is the easy part - especially with editors, stackoverflow, and (now) ChatGPT - so focus on how they approach the problem. Then, when you’ve talked through it, whip out an editor, and pair-freaking program with them. I don’t care who drives, but when I drive, I make a few mistakes - partly to show them that it’s ok to make mistakes, partly to see if they catch them, and partly because I just make a lot of mistakes when I’m coding in a freaking interview no matter which side I’m on.

Or try reviewing existing code - and then adding practical functionality. Experiment and figure out what works in helping you figure out if the candidate has enough “technical” (coding) experience to add value to your team.

If you are basing the coding portion of your interview entirely on someone’s ability to write a graph search on a whiteboard, you are likely missing out on many better qualified candidates. Your call. You do you.

---

Oh - I almost forgot to mention take home tests. Surely, this battles the issue with introverts like me wanting to think about code before writing?

Nah - if I ever had a take home test, I’d just pass and go onto the next company. That’s what your candidates will probably do too.

Bad Behavior…

Behavioral questions are fantastic. “Tell me about a time when you ….” You get a real story - plus a lot to dig on in follow up questions. You can tell a lot from hearing someone describe how they’ve tackled specific issues.

Of course, if you only ask behavioral questions, you’re going to hire some fakes too. What I’ve found is that some people who are really good at giving answers to these questions are also full of shit. In fact, I once read of an “interview coach” who specialized in helping people absolutely crush behavioral questions using made up scenarios and fictional problems. I talked with them about it, and I was convinced. With some coaching and training, almost anyone can crush a behavioral-only interview. Even if they’re toxic and don’t have the skills to do the job.

..and Balance

The trick, of course, is balance. You’re not hiring “a coder” - you’re hiring a teammate. Culture add is important (along with their ability to do the job). The job you hire them for is going to change over time, so even though you really need someone who can write a backend component in Java now, you may need them to generalize more in the future. In fact, another thing that AA interviewers did at msft was to make sure that we were making hires for the company, not just for the role.

---

My goal at the end of an interview loop is that no matter if we make a hire or a no-hire decision, that we accomplish two things.

1. We (the interview team) feel like we have learned everything we need to know to make a hire / no-hire decision

2. The candidate (hire or no-hire) feels like the interview was a great use of their time, and they walk away respecting the company

I don’t know how any other outcomes are fair.

And a Bit More

What would a Weasel Speaks post be without a book reference. I’m going to partially recommend Smart and Gets Things Done by Joel Spolsky. No link, because I think a good chunk of the book is crap (because he recommends many of the things I mentioned above, and I think a bigger chunk is extremely dated). But there are a few nuggets in there - if you can read it with a critical eye, I think you can find some.

A better resource is from (once again) Pat Lencioni in The Ideal Team Player, where he talks about the trio of humble, hungry, and smart. What Lencioni says about awesome employees is that they are:

1. Humble - obvi, nobody wants to work with assholes (also see Sutton’s The No Asshole Rule). We want people on our teams who care about the team success above whatever satisfies their own ego. Also - humility is just a solid trait.

2. Hungry - I often ask candidates how they learn - or ask them to tell me about the last thing they learned - or what they want to learn in the future. Great employees are hungry to learn and want to continuously improve. Again, balance here is important, because sometimes people can be so hungry that they’re also a jerk.

3. Smart - Lencioni isn’t referring to IQ points here - he’s referring more to emotional quotient - or “people smart”. We want teammates who can use active listening, interact well with others, and make good decisions.

In the end, there’s no formula for hiring. There’s no blueprint that works for every team in every company, but I can say that this approach has worked well for me across multiple companies. But I’m me, and you’re you, so you’re going to have to figure out what works best for you - but I think that we - as a tech industry - have plenty of room to improve how we hire.

-A