Consider this… You are a smart, seasoned software engineer with a decade or more experience in the field. You can write code backwards and forwards in your sleep, and often do. You can architect and develop and design and integrate and document and test and debug. You know your shit and you know it well.

But lately, your company has not been showing you the love you want. So it’s time to look for a new job.

You polish the resume, you find some matching places on Wellfound or levels.fyi or, god forbid, Indeed, and make some inquiries. Of course as a seasoned technical professional, your resume is solid and you get some responses. You go through the first few rounds of interviews: the technical screen with the recruiter person, a more substantial interview with the hiring manager, and then you get to the technical interview where you are meeting another engineer (or several) in the company, someone whom would probably be your peer(s). You talk through some code samples of your stuff, maybe dive into some of your open source work or another past project, and you are absolutely crushing it. You nail the small code points to show you know how to write code, and the big architecture things to show you know how to build systems. And then the interviewer says the following:

We’d like take fifteen minutes for you to take a look at this sample project we wrote and tell us what it does.

OR

We’d like you to find the problems in it.

OR

We’d like you to finish writing this code and get it working.”

And you panic. Your heart starts pumping faster, your breathing accelerates, you start sweating. And you start making mistakes. Which only makes things worse and you start spiraling. But you certainly do not want to show any sign of upset or consternation; you cannot show any weakness, but things are going sideways and they are going there fast. And you’re not at all sure how you got here.

GUN TO THE HEAD INTERVIEWING

This, my friends, is what I like to call “Gun To The Head Interviewing”. I call it this because they have taken a task that is normally something you do in your own way, at your own pace, in a measured and even approach, and they jammed it into fifteen minutes, with a bunch of people staring at you and demanding you perform like a trained seal at SeaWorld. It is hyper aggressive, it is extremely stressful, and it is completely unrelated to how you would actually perform the job.

Given any of the above possible questions asked by the interviewer, to expect a software engineer to read the code, understand it, understand the poorly defined problem space, validated that the code works or not, and write or discuss a solution, IN FIFTEEN MINUTES is not at all realistic.

Yet, this keeps coming up. We keep seeing this kind of “pressure test” to verify a software engineer can write code. Except it is not testing writing code, it is testing performance under pressure and that is a very different thing.

Also, without even realizing it, this comes close to being discriminatory. It favors people whom do not suffer from anxiety or anyone whom could be triggered in pressure situations. It does not mean that these disabilities make people worse employees, it just means that you as the interviewer are not opening yourself and your company up the the wealth of diversity that these candidates can offer you. You are doing a disservice to your employers.

Software engineering is a field known for requiring thoughtful, researched, and reasoned answers. To expect someone whom works in this field to perform under extreme stress is not testing whether or not they can do the job you need them to do, it’s testing whether or not they can handle your extreme aggressive bullshit. Honestly, it should be a red flag to the candidate of a sign of things to come if they do take the job. They should put that at the top of their list of reasons to not accept.

Interviewing is a process for establishing an initial space of trust. Bi-directional trust between employee and employer. The employer wants to believe that they will get the talent that they pay for and that the employee can do the job needed. The employee wants to believe that the company can deliver on their promises of pay and growth and mission. The interview is the process by which this initial trust is established. At the end of the interview when the offer is on the table, it all comes down to this initial trust.

HOW WE INTERVIEW BETTER

So, of course, this begs the question of how a hiring company should be testing whether or not someone can code during an interview. How does the hiring party truly assess a candidate’s ability to sling code without making it an aggressive pressure situation, one in which they are given time to reason and react in a thoughtful approach.

First, I would argue that if you cannot judge an engineer’s technical ability just by having a conversation with that engineer then you have no place being involved in the interviewing process at all. Asking technically deep questions and probing around the answers and into the details can give you a solid idea for a candidate’s technical abilities. It might take a little longer to get into these details, which can run afoul of HR’s desire to have every interview last less than thirty minutes, but it is time well spent.

Second, do not spring the problem on the candidate halfway through the interview. Tell them the problem a few days before the interview so they can spend a little time thinking it through. Share the sample code, if any, well before hand to give them a chance to read it, to try it out, to understand it. Give them time to get comfortable with what they need to talk about instead of forcing it adhoc at the last minute.

Now, there are those out there that are worried a potential candidate will just search the internet for the answer and copy and paste that. To this I say, “So what.” We all copy code from the internet, we all search DuckDuckGo for the answers. By obfuscating the question ahead of time, all you have done is tested whether or not we have searched Google for the answers ahead of time and guessed correctly what your toy problem might be. A tiny bit of conversation and inquiry around the answer a candidate is providing, even if they copied it right in front of you, will give you a very strong sense as to how well they understand what they are doing.

Third, time boxing to fifteen minutes or thirty minutes or whatever is entirely unrealistic. We all know that we as software engineers are incredibly bad at estimating and we know that holding us to the estimates of others is an awful idea. So why are we doing this for our candidates. Everyone works in their own way, in their own time frame. I like to write code in a very iterative manner where I keep refining over and over until I have the right solution, but that all goes out the window if you tell me I have fifteen minutes to do it in or your going to shoot my brains out.

Finally, do not do this with more than one interviewer. For each interviewer you add to an interview panel you ramp the pressure up by an order of magnitude. And for each interviewer present, the process for the candidate becomes more a performance and less a demonstration of ability. If you want to do these kinds of panel interviews, do it in the earlier phase where the candidate is intentionally being asked to present something to the group, an open source project or past project on which they have worked. This gives the candidate a chance to prepare for the act of presenting in front of a group and to organize their thoughts into a clear and concise form for transmission to a group.

THE PERFECT INTERVIEW PROCESS (IMHO)

All the above is all well and good to talk about to discuss, but how does a company put it into practice? How do we vet a candidate and at the same time build good rapport, good trust with that candidate?

Here is my ideal way to do this. Some may feel this is too much of a commitment, too many people involved, too much time required. From my experience companies generally spend around four to six hours interviewing a candidates, over four rounds, with four to five people. My process below requires six and a half hours, six meetings, and five people. It is a little bit larger than what we are doing today. But I would also argue that what we are doing today is not working and a little bit more may be exactly what we need.

1. The Recruiter Screen – 30 Minutes – Recruiter talks with candidate and tells them about the company, the role, and the benefits. The candidate is given a chance to give their five minute experience summary about their career. A few simple questions from the interviewer here can also be used to make sure the candidate meets the minimum technical requirements of the job.
2. The Hiring Manager Screen – 1 Hour (minimum) – The interviewer, usually the manager looking to hire someone for their team, talks more in depth about the role and the work. The Candidate does their five minute experience summary again, but this time the interviewer dives deeper into the experience. This is the chance for the manager to ask deeper technical questions and drill down. This is not quite the technical deep dive, but it should help narrow the field more.
3. The Technical Presentation – 1 Hour – The candidate is asked to present a past project, including showing code samples, and to talk about some of the challenges they faced in delivering their solution. The presentation portion of this can take up to thirty minutes, but the remaining thirty minutes should be used by the interviewing panel to ask follow-up questions and delve far more deeply into the technical answers. It should be noted that the point here is not to pick apart the solution or shit on the candidates choices. Instead focus on understanding why the candidate made the choices they made and whether or not they would make those same choices again. It is not about pointing out errors or other ways to do things, it is about seeing if the candidate can find those things themselves.
4. Technical Conversation – 1 hour – This is where you have a conversation with the candidate for their technical knowledge. This is not a challenge/response kind of thing, but a chance for you to understand how the candidate thinks about specific technologies while also assessing how much of that technology they know and understand. Your questions will need to reflect the experience the candidate has with the technology, but should never come across as a “prove to me” kind of thing. Again, keep it conversational, but steer it deeper and deeper. There are not wrong answers here, only wrong questions. Ask generalized questions about the technology and then drill down into the details. Why does the candidate like or dislike a specific technology? How would they overcome a dislike? How would they make the technology even better. Get specific. If done correctly this replaces any need for a live coding demonstration entirely.
5. The Culture Interview – 1 Hour – The interviewer, usually a senior leader in the company, meets with the candidate to determine if there is a culture fit for the candidate. Not a technical discussion, but a discussion about culture and communication and process and flow.
6. The Reverse Interview – 1 Hour – The candidate interviews the hiring manager this time for the candidate to determine if they want to work for this person, team, and company. This is about giving the candidate a chance to see how the company is going to live up to their needs and expectations.
7. Negotiations – As long as it takes – Always negotiate.

I realize that doing this kind of interviewing is not easy. It’s a significant time commitment, on both sides of the table. But as a good friend recently said (paraphrased)… you are entering into a long term agreement, for hopefully many years; spending six hours or more on this is not a bad thing. The amount of money, and I’m talking beyond just a salary, is enough to warrant taking your time and making sure you are getting these things right.

AND FOR THE CANDIDATES

Of course, all this advice is about how the interviewers should be doing things, but what about when you, as the candidate, get sideswiped by the pressure interview. How do you handle it when John Travolta points a gun at your head and demands you hack or die? (This is a reference to the movie Swordfish where in the very early part of the movie John Travolta puts a gun to Hugh Jackman’s head and demands he hack the government. It is very unrealistic but it is also a perfect example of Gun To The Head Interviewing.)

And just a caveat before I dive into this here: Doing some of what I am about to suggest can be risky. Companies do not like to be told they are doing these thing wrong or discriminating or not amazing people. Their process has worked for three other hires and it should work for everyone. Yet, if you do not speak up, if your remain silent and suffer through their very poorly designed process you are setting yourself up to fail. It is a risk, to be sure, but we are not going to get better as a society at this unless we try to change the shitty ways we do it.

A lot of times these type of interviewers say they just want to “see how you think and reason.” But what this really means is that they want to see if you think and reason exactly like they do, which I assure you, you do not. This is a huge disservice to both you and the company. You do not think like they do and that is actually a really good thing for everyone involved. Different opinions and different ways to approach a problem are really important for innovation and innovative growth. A bunch of “yes men” is a huge disadvantage in the marketplace and in the growth of your company.

Those caveats aside…

Initially, I would recommend trying to avoid it altogether. Usually, very early in the interviewing process a company will describe the steps they are going to put you through. This is the first chance to speak up. You must champion you and say something like: “Unfortunately, I have found that I do not perform really well at pressure coding. I’m wondering if we could try a different approach.” And then outline something that might work better, something like what I propose above. Feel free to reference this article to them and suggest that they do better. At worst you lose the interview entirely, to which I suggest maybe this is not the company for you in the first place.

Next, challenge the time constraints given you. A recent interview of mine suggested I would be able to understand the problem, read their code, validate it, figure out what I would do better, and write that code, in less than fifteen minutes. When faced with this situation, be frank and up front and say something. Unfortunately, most interviewers are not going to be happy when you push back like this, so I refer you back to point number one above in trying to avoid it altogether.

Finally, when faced with no other option, here is the sure fire way to get through this process. Write this down on a post-it note or some such and stick it next to your screen so you can refer back to it without anyone seeing.

1. Say “I’m going to read the code” and then read the code through, line by line, no matter how long it takes. Do not talk during this part, just read the code.
2. Pay careful attention to any tests they are running or that can be run to validate any potential changes you are going to make. The tests almost certainly signal the problem areas.
3. Run the tests/code. Often times the test results will hint at where the problems are. Do this even if they have stubbed in a place for you to write code. Get a sense for things.
4. Outline where you think the problems are or what you think needs to be done. Do not just go fix them or write code directly. Take your time. Write these out in pseudo-code in a new file and enumerate them. Reorder as you go, moving the more important ones higher.
5. Write code incrementally and test your solution as you go. Write a couple of lines, run the code. Write a couple of more lines, write the code.
6. Do not spend any time on boilerplate. Languages like typescript are great for defining types and type safety. Do not waste your time on this. Solve the problem instead and then if you have time, which you will not, go back and add this later.
7. When wrapping up, talk about all the things you would have done if you had more time. These can include type safety, validation, error handling, abstractions, pattern implementation, etc.

PUSH BACK FOR ALL OF US

Again, it is a risky move to push back, to challenge someone you are hoping to collect a paycheck from. It is even more risky when you consider how much you need a paycheck, which the media says nearly 60% of people in the USA do on a day to day basis.

Yet, we must push back. These practices are not helping anyone. Companies consistently lose out on quality talent while complaining there is not talent out there; candidates get overlooked and sidelined just because how an interviewer approaches a problem is different than some one else; everyone loses out.

Now, I want to be clear here that not all companies do this. Every company you interview is going to be different. I might argue that that is not actually a good thing, but that is an entirely different blog post and article for the future. Instead, I encourage companies to reconsider their practices and try to implement a hiring process that is more equitable for everyone, more open to alternative points of view, and far, far less stressful for everyone involved.

The system of pressure interviews for software engineering has to change. We cannot hold a metaphorical gun to a candidate’s head and expect to produce results. It is unrealistic, aggressive, discriminatory, and just poor for business. And the only way we change this is to demand change in the first place. We, as companies, as interviewers, as candidates, need to speak up, point out the fallacies in these practices, and strive to change them. It is only by striving for change that we can hope to move the needle forward and make the process better for all.

So stop accepting this as fact, and start speaking up to get it changed. It’s the only way.