Roger Ngo's Website

Personal thoughts about life and tech written down.

Grind! The Technical Interview!

I had given pretty much my personal record in terms of technical interviews this year while at my most recent company. Since realizing this, I've taken some time to reflect on how the industry does interviews. I have an opinion on how they should be given, and have this belief that most technical interviews are broken.

To clarify, I'm finding it common amongst companies that a candidate must solve a programming problem within an X number of minutes in a time and space efficient manner and to add to the overall pressure... in a bug-free state!

Given that most technical interviews are only about 45 minutes to 60 minutes long, the expectation in most top technology companies is that candidates are expected to solve not only one, but two of these problems within the allotted time.

When did this happen? I remember in almost every company I had interviewed at a few years ago, the goal was to impress your interviewer with your problem solving ability and thought process.

Was that not the whole point of these interviews? Weren't these types of interviews used to judge a candidate on how well they approach a given problem and have the interview determine whether or not they would be a great teammate?

I'm now on the other side of the table now giving these interviews. I still have this belief that we should use technical white-board interviews as a demonstration on what it would be like to solve a problem in a day-to-day setting with the candidate. Because of this, even when I give white-board interviews, I also have a dry erase marker on my hand and am standing with the candidate. We solve the problem together.

The following flow is typical:

  1. I give the candidate the problem to solve.
  2. I hand over a second marker to the candidate while holding onto mine.
  3. I allow some time for the candidate to digest the problem in front of them. I am also waiting for them to start solving the problem.
  4. While keeping the marker on my hand and standing next to the candidate, I am simulating the notion that it is also the first time I've seen such a problem. This is very important in keeping a fresh and happy attitude in the interview environment.
  5. We solve the problem together. Depending on how difficult the problem is, I will usually let the candidate drive the problem solving process. If the candidate is having trouble, I have no problems stepping in and drawing out some hints to help them out on the whiteboard.
  6. I judge the interview performance based on how they reacted to not only on how they solved the problem and their code, but based on how they reacted to being stuck, and how they reacted to me stepping in and helping them. The final two points are important in that they actually simulate a real white-board design session for day to day work.

From my experience in not only being the candidate and the interviewer on several occasions, I notice that the we interviewers often sit on the table watching the candidate code while taking notes on the candidates performance. This is NOT OUR FAULT!

Unfortunately, with the requirement to take detailed notes by the interviewer, we sometimes put too much focus on the note-taking and lack of focus on the candidate to really judge their technical ability and also be available to give insightful hints and clues on how to solve the problem.

As Software Engineers, we don't perform design sessions this way. We don't leave our teammates to fend for themselves up on the board when working through problem. We're a team for a reason. We work together. Therefore, as one who is more familiar with the problem, interviewers should work on giving insightful thoughts and opinions on how to approach the problem differently which will hopefully, and ultimately lead to a solution by the candidate.

But wait, isn't that what software development is? I believe we shouldn't judge intelligence, or feel the need to flex your engineering culture off of a white-boarding session.

Let's take a look at it from a Jungian perspective. Yes, I just made that up. You know the whole introvert-extrovert thing? In a non-scientific and purely personal opinionated statement - but probably agreed by consensus: Most software engineers are introverts. This is something to consider as most introverts do not thrive being on the spotlight, or in stressful social settings. Giving someone a programming puzzle they have never seen, paired with unfamiliar faces and an unfamiliar environment is just a recipe for a stressful situation for the introvert. That's something to take into consideration.

Most introverts do better digesting a problem on their own time and figuring out what to do rather than be expected figure out something on the fly in front of a very intimidating engineer who they have met just five minutes ago.

The interaction of the interviewer and candidate is very important, but also the type of problem given. A good programming problem to give in judging technical ability should be closer to the the type of problems one would encounter in your engineering team on a day to day basis.

Since there is only really 45 minutes to solve such a particular problem, I believe the obscurity in these problems should be removed and instead be massaged to really test the ability for the candidate to translate their thoughts into code. The problem should not be designed to cause a candidate to claw their way to a "valid" approach.

Yes, if you've worked a similar problem before, either a variation, or even the same problem, you'll look great! But, if you have never even seen the problem, it's likely you'll end up looking like a dog with a bow-tie writing random things on the whiteboard with a sense of urgency that falls in the spectrum of running your first red light and getting caught by the cops, and maybe forgetting to give your grandma a visit (you had one job!).

As interviewers, we're supposed to judge on the thought process with regards to how the candidate approaches solving the problem. A candidate who does well is likely to be the one who presents their approach in a way that I can ultimately agree with. Unfortunately, this is the bias everyone must deal with. But it isn't so bad. We naturally want to see people succeed and so, benefit of the doubt is usually given.

However, I'm finding it more and more common where the expectation is that the candidates must get the problem solved within 20 minutes in a perfect, bug-free manner, then solve the follow-up problem with equal expectations.

I'm not sure whether we've lost sense of what the real purpose of white-board technical interviews are supposed to be for.

A Good Experience

When I first interviewed at TSheets (now Intuit), I remember getting a phone screen from a lead engineer and was tasked with actually coding not a programming puzzle, but an actual mini-exercise that involved all aspects of web development. The type of problems that would occur on the day-to-day job. The problem was by no means "easy". It was just that it was more in line of what I was already currently doing at my job.

When it came to the on-site interview, I remember sitting in the conference room with J.D. Mullin (Engineering VP) and I was ready to be grilled with some tough programming puzzles.

Contrary to my initial thoughts, the first thing J.D. told me with the friendliest smile on his face, as if he knew what I was thinking. This was along the lines of:

"We're going just have a nice chat about tech and your background. There aren't any tricks to to this interview. No obscure white-board programming problems, just things to test your basic background."

And so, the interview was exactly like he promised it to be. It was simple, and enjoyable. In fact, I felt that I enjoyed it too much and that it was too simple to even be a tech interview! I initially thought that the company may have had a low-hiring bar. I now believe my initial thoughts were naive and completely wrong.

After much thought, and now in this present day where I am more mature as a person and engineer, I am fully now aware of what J.D. was trying to do.

The initial phone screen was already deliberately designed to test my technical ability. In reality, our jobs aren't always about recreating academic algorithms, but rather producing practical code that can drive a product of a business to keep their customers happy.

I had proven that I was technically competent in the phone screen already. Why repeat the same thing and not get any other interesting information during the on-site interview? Instead, I believe what J.D. did was spot-on. I felt that he was trying to gauge whether or not I had the passion for software development and the hunger to learn and improve as a person, problem-solver and engineer. J.D. was looking for cultural fits with regards to his team, and that there's nothing stopping a person from learning and improving their skillset as long as they have the proper attitude to do so.

As a result of this interview approach and during my time at TSheets (punny - look it up), J.D. had built the engineering team and culture at TSheets consist of the smartest and nicest group of people I had the pleasure of working with at the time. Everyone was high caliber. My time there was filled with excellent learning and just pure fun software development.

That is not to say that the other interviews at my past jobs were not great. I would not have taken the offer and become a contributor to the team if I had not felt comfortable. I think I have been lucky thus far in my career to always have had a great panel of interviewers who really put an effort into giving a great interview experience.

While at IBM, I was trained to "Interview the IBM Way". Essentially, this means to give the interviewee the best experience possible -- to treat them in a manner that you would want to be treated yourself given in the same situation, and to provide a critical evaluation without any biases.

I took this training very seriously and came up with my own pattern and process for conducting technical interviews. To this day, I make an effort to follow this belief and mindset.

I was also very fortunate and blessed to have a great panel of interviewers during a recent Microsoft interview. All the Engineers were great and placed me in a setting where it was an evaluation on collaboration and problem solving. After a few minutes in each interview, I had forgotten that I was white boarding and every interviewer was up at the board with me -- solving the technical problem and providing constructive crticism to my problem solving approach.

To end that note, it is the realization that the technical interview a company gives does not immediately reflect the overall intelligence of the engineering team.

Giving the Interview

Okay so you're the interviewer and you want to change the process! But what if you’re stuck with the white-boarding model? What can you do as an interviewer? I personally try to stave off the temptation to get lazy with my interviews. I try my best no matter what to always perform as if I was just a teammate of the candidate trying to solve the problem on the board.

A few things I look for in both the behavioral side and technical side:

Behavioral Skills

  • Look for good behavioral skills. Find out if the candidate is friendly and can be a good, and honest person to work with.
  • Try to see if they know their resume very well. A lot of candidates tend to forget what they wrote on their resume upon job application submission. For me, this gives a huge red flag in that they may have just falsified some of the information.
  • Look to see if the candidate can strongly recall some of their projects really well, and can recall any of the challenges involved in the project. To me, the ability to willingly admit struggles in hindsight is a huge positive when shortcomings are openly admitted.
  • Can they recall their favorite aspects about their past work?

Technical Skills

  • When asking a technical programming question, does the candidate respect you? Do they let you complete your thoughts to them and do they take time to ask any clarifying questions after you have presented the problem? Candidates who take the time to ask any clarifying questions show that they respect the question you have just asked and are open to the challenge.
  • Does the candidate try to write down a solution, or at least express their solution before coding? If they need some time to think of a solution and one does not immediately come to their mind, make them feel comfortable in that you should let them know they do not need to hesitate to ask for a few minutes to think. Knowing this as the interviewer will at least let you be informed on what is going on in their mind.
  • Don't fault the candidate for not communicating aloud constantly. Most candidates tend to focus too much on trying to make sure that their interviewer knows that they are thinking aloud that they lose their own train of thought. This is a sign of "saying something just to say something". Communicate to your candidate that it is ok to let you know where they are in the problem solving process such as: "I am currently think of...", and then have them follow up with a few moments of silence. This is okay. Again, the fact here is that you now know where they are in the problem solving process.
  • You both give each other your time. The candidate gives you their time by interviewing, while you should give the candidate your time by being patient when they are jotting down thoughts on the whiteboard. If it takes them 4 different cases to test out code in a step-by-step manner, do not rush.

Conclusion

With that, I leave you with the basis of my opinion on technical white-board interviews.

They are still a great tool to judge a candidate, but we have to go back to giving them in such a way that allows true collaboration between interviewer and the candidate: Problem solving and communication of thought processes.