How to do Software Engineering Interviews: Notes to Interviewers
As I mention here, I recently started my new job at Gusto as a software engineer. In celebration I read every sock joke I could find.
Here’s the TL;DR of the first post:
To summarize, while the circumstances were slightly unusual (the startup that I worked for was getting acquired), the engineering interview processes were essentially the same. I did my first onsite interview on March 3rd and signed my job offer on March 24th. In the end, I had four job offers from the five companies that I interviewed with.
I’ve taken some time to reflect on the process. My notes are divided into two mains sections: Go here to the first post, for the section, Notes to Interviewees. This is the second section, Notes to Interviewers.
In my 10+ year career as a software engineer, I have interviewed more candidates than I can count. Going back to being an interviewee after years of being an interviewer gave me an opportunity to think about how software engineering interviews are being conducted and how they can be improved.
Here’s a quick legend to the companies I spoke with:
- Teeny Tiny Inc.: Small B2B startup.
- Thoughtful Inc.: Beautiful product with lots of users.
- Gusto: ⭐️
- The Other G Inc.: Medium-sized company that builds a necessary product.
- Cash Money Inc.: Recent IPO.
Programming tests
Programming tests are usually about two hours, and involves solving a coding problem. Hopefully this is in a language and IDE that the candidate is familiar with. I ❤️ programming tests because it’s the closest thing to my day-to-day job that is replicated by an interview situation. However, it’s important to note that timed programming tests are stressful and not all engineers are good at writing code in a timed scenario. This does not imply incompetence and it is important that companies take this into account when evaluating test submissions.
As a candidate, the first question I ask about a programming test is — what is the most important thing about this exercise?
For example, is it the design of the code, or is it that a set of unit tests should pass, or is it to implement an algorithm. In my experience, to perform well on a programming test it is crucial to know what the goal of the test is. Especially given the timed nature of the exercise.
Some companies however, didn’t do such a good job at this. To my 😱, there were at least two interviewers who could not tell me the goal of their test. My feedback here would be to revisit the programming tests and consider what the end goals are. This provides a tangible method for evaluating a candidate, rather than a nebulous or gut-feel evaluation strategy.
Gut-feel evaluation strategies are problematic, especially when you want to increase diversity in your company.
For example, Cash Money Inc., has one of the best programming tests that I’ve taken. They have three stages of extensive unit tests, and the goal given was: starting with Stage 1 make as many unit tests pass as possible. How clear is that?!
Another company, The Other G Inc., administers a remote programming test. The test states only two features to be implemented. My gut instinct, was that this was a 2D matrix question, but it was clear that based on their problem statement I could implement just-the-stated features without using a 2D array. Therefore, I took the shortcut and used a hashmap instead because… well, who wants to deal with a 2D array when you can use a hashmap? Reader should note, I was feeling overconfident with three job offers in the bag already, but my point still stands! Nowhere in the problem statement did it say what the goal of the exercise was except to implement the two features, which I did with accompanying unit tests. Needless to say, The Other G Inc. was not impressed by my little shortcut.
Feedback
Dear Interviewers, Please please please provide feedback 🙏. As a candidate the only way I can possibly do better, and minimize this life-reducing anxiety is if you tell me what I did wrong. The Other G Inc., for example, never gave me any feedback though I asked. Meh.
Caution: Hard Hats Required 👷🏽♀️
If you are a candidate, there’s a good chance that you might encounter interviewers who aren’t very nice. Try not to get frazzled or angry, like I sometimes did.
I don’t know about you, but I don’t react well to threats. And I was surprised by a few interviewers who came across as well,… dicks. At least twice, I encountered communication styles that appeared to want to intimidate or challenge my intelligence. Being polite and respectful is not inversely correlated with being smart and capable, and I see no reason why interviewers should try to be intimidating during this process.
In contrast to this experience, Thoughtful Inc., which is the company that I would consider to have the best interview process that I experienced had one interviewer start by saying “I’m not trying to trick you or intimidate you.” And then he said it twice more. Thoughtful Inc. did the best job of validating my skills as a software engineer. I believe that their style of communication helped me perform better.
As much as you are interviewing the candidate, the candidate is also interviewing you.
Engineers want to work with people who respect their experience and skillset. They want to meet their potential peers who work in similar functional areas and are similarly experienced. If you are trying to woo an experienced candidate, have them meet with your most experienced engineers. They want to meet leaders at the company who believe in their potential to contribute towards the missions of the company.
To my frustration, I encountered Mr. Rote-Recollection at Cash Money Inc., who was primarily a backend focused engineer with little javascript experience. My experience in the last two years however had been a lot of React, Node and ES6. To my dismay, Mr. RR sat behind a laptop and asked a lot of rote-recollection-type questions about technologies that he had seen listed on my resume. One of our interactions went like this:
Him: “What is a single page application?”
Me: <Explains about SPAs and how we built a couple at my last company.>
Him (dismissive): “Isn’t that just AJAX?”
Me: 😒
As a friend remarked after hearing about this exchange, “that’s like saying, aren’t websites just http?”
I hate to admit this next part, but Sheryl Sandberg says it’s OK. By the end of the day, this interview left me in tears. I was exhausted but also highly frustrated by the disrespectful communication style and snide remarks. Shockingly and ironically though, not only did Cash Money Inc. want to hire me but monetarily speaking, they also made the best offer that I received — about 25% better than other offers. But to say I wasn’t thrilled by the idea of having to work with someone like this, is an understatement. I joke about the high salary compensating for having to 😭 about once a week.
Agenda
At least two interviewers appeared to be unprepared for the interview and had a meandering interview style, with interviewers resorting to small incremental questions to fill up the time.
Candidates can very quickly discern whether the interviewer has a plan for the interview or not.
One interviewer said to me, “if you don’t ask me any more questions I will ask you an algorithm’s questions”, and laughed a little at the co-interviewer. We had ten minutes left. Was he implying that I couldn’t handle his question? That I’d be better off asking him more filler questions? That was annoying. And more importantly, was there still a question on his mind about my ability? For the record, I solved his algorithms question in about five minutes.
But here’s the problem — you would assume that an algorithm question was critical to my evaluation, and if that was the case why was it left till the last ten minutes of the interview? If I was him, I’d have chosen a better question which covered all the basics, such as software design principles, use of a complex data structure, and execution of a complex algorithm.
In the end, however, this type of agenda-less interview and semi-disrespectful communication style didn’t make me excited to work for this company.
Grading rubric
As I mentioned, Thoughtful Inc., had an enjoyable and effective interview process. It was clear that they had ‘thought’ about tangible characteristics, knowledge, skills and values that they were looking for in candidates. It was clear that interviewers were communicating with each other through the process about their discussions with me, minimizing redundancy.
Conclusion
Conducting software engineering interviews can take up precious time and resources for companies. It is also anxiety-inducing and stressful for candidates. Making this process as short and effective as possible is a win-win for everyone involved.
Programming tests are awesome as long as they are well thought out, in terms of priority of the exercise and evaluation strategy. Companies should consider a grading rubric for interviews to avoid nebulous or gut-feel evaluation strategies. Candidates are interviewing you as much as you are interviewing them. Be respectful about their skillset and experience. Make sure interviewers are familiar about the candidate’s specific expertise, so that they can have a meaningful conversation during the interview. Make sure to have an agenda for the interview, as candidates can very easily discern whether you have a plan for interviewing them or not. Please give your candidates feedback on their performance.
In the end, I chose Gusto because I met some amazing and inspiring people there. The team did an awesome job of describing their vision, culture and opportunity for me to have an impact. They did a great job of explaining how my career could evolve at Gusto, and made me feel truly excited to join. Side note, they have the best “you got the job call” I have experienced!
Thanks for reading this far! Feel free to reach out if you have any thoughts.
Many thanks to Jayesh Sureshchandra, Alicia Liu, Dilan Dane, Brian Zotter, Tim Kral and Derek D’Souza for thoughts and feedback on this post.
