*At the date of this article.

I do not know many people who would claim to love interviewing for jobs. The interview process can feel like torture, especially when there are multiple hurdles to clear before the final hired/not hired answer. It has become the norm to talk with multiple people on different rungs of a company ladder, emphasizing not just about the job, but benefits, company culture, and possibly more.

In the tech industry, a necessary evil is the tech interview as a way to assess an applicant's technical skill. After tens of tech interviews, I can confidently say I have not experienced the same tech interview twice. They have ranged from understandable to infuriating, making me wonder how the interviewers could possibly know my skills well enough for the job I was applying to.

I have written out code on paper and white board; done quizzes; created a small app from scratch; live coded while one or more interviewers watched on; answered questions about hypothetical scenarios, to name a few types of technical interviews.

At best, I would remain neutral about the job; at worst, it would leave me discouraged about the whole interview process.

But this article is about one tech interview that was different.

Full disclosure: I didn't end up getting the job. But the interview has stuck with me. And I wanted to share what made it such a good experience so that other engineers could be on the lookout for similar green flags in the hiring process.

The Technical Interview:

The Process

After a 40 minute screening call with the recruiter, I was given the outline of the next part of my application process for a full stack engineer position. I would have two tech interviews, one for backend code and one for frontend. 48 hours (minimum) before the scheduled tech interviews, I would be given access to the relevant pull request (frontend or backend), that would mock code from a supposed teammate for me to review through asynchronous comments.

The technical interview would go over my background, my comments, and continue from there over the course of 90 minutes.

Step 1: Receive and review two Pull Requests before the respective interviews.

While I was told that I would have up to 48 hours for both pull requests (commonly known as PRs), I was given over a week with each pull request. Without even starting the actual PR reviews, the company was making sure I had some knowledge of git; that I could clone the repo with the PR branch down to my computer and run the code locally.

The exercise itself was clearly mimicking a regular task in the day-to-day for the job I applied for. By reviewing code, I was asked to read, interpret, and form meaningful opinions about the code and communicate those opinions through written comments. The instructions linked to a page for a preferred comment convention, which checked my attention to detail and ability to follow directions.

In practice, this task showcased my communication skills asynchronously and through text, a must for most collaborative coding projects nowadays. I made sure to offer solutions when I found ways the code could be improved. I also made sure to comment on what I thought the PR author did well or if I learned something from their code.

Overall, I was thrilled because I could take my time with it. The PRs were small and gave both myself and my interviewers an idea of what it would be like if I was a member of their team.

I also double checked whether or not my solutions worked locally before I made the comment. This really helped me in the next step:

Step 2: A 90 minute tech interview.

I have had technical interviews as short as twenty minutes and as long as three or more hours, so this was definitely on the longer side. For most of those interviews, I was lucky to even have an idea of what to expect. This was the rare occasion I felt incredibly prepared because of my previous task of reviewing the pull requests ahead of time.

The first 15 to twenty 20 was spent on introductions, a very light overview of what the interview would entail, and then a walkthrough of my comments and the code itself. I was given a chance to clarify and expand on any of my comments.

After that, we spent the majority of the time “pair coding” as I “took over” the pull request and applied the changes I had commented/recommended in the PR review.

I think this is a brilliant way to do a live coding interview. At this point, I already had a*t least 48 hours with this code* and took advantage of it. I had tried out several of my suggestions to make sure they worked before I left my comments. And, once again, it mimicked a real-life situation that I would probably experience on their team.

The interviewers were mostly silent, allowing me to “drive” or lead the live coding exercise. However, they were not completely passive. I was allowed (and did) ask questions as we combed through the code. In one situation, I clarified that I would ask the product/design team if there were any conventions when changing the layout on the frontend and confirmed that normally I would use an existing component library. I was able to convey that I understood the makeup of a tech team and how to work with different disciplines.

Another example of this interview giving a real pair coding experience is that the engineer was able to see that I understood the code and the end goal, but for whatever reason was not able to find the best answer for the framework. This allowed him to course correct, and I was not stuck for too long on a problem that I could have figured out given more time, but didn't let me wallow in fruitless internet searches.

This pair coding exercise was also a chance for me to get a feel for the company’s culture. Beyond the still present pressure of an interview, the facilitators treated the sessions like we were already teammates. They talked with me through my solutions, sometimes tweaking the parameters to see how I might solve a slightly different problem.

On more than one occasion, both interviewers were able to point out specific tricks that were unique to the frameworks or practices their team preferred. They were quick to affirm that I was on the right track and only helped me when it was obvious I would figure it out given enough time on my own, but wanted to see what I would do at the next step before time ran out.

Final Thoughts:

How often has a promising candidate been hired and started, only for their team to later learn that they’re unwilling to learn a new stack or practice? Or that they grate with other teammates or the scrum master? Or that they have a rigid way of thinking that makes any sort of communication painful?

Or, from the candidate’s side, how often does the interview feel like an honest representation of the company and the job they are looking to fill?

The process described above, while not perfect, left me feeling like I was able to show my range of knowledge and skills (both “hard”--writing code, problem solving--and “soft”--communication, teamwork). I was not frustrated and worried that I didn’t know what the company was looking for or wondering how I could have done better in the moment. While I was disappointed when I wasn’t offered the job, it was a valuable learning experience. I had a good idea of what skills to improve on.

I can only guess what it was like on the interviewer’s side, but I felt like they had the best picture of me as a candidate and potential employee/teammate. When they said no, they must have felt confident I wasn’t right for the job. And honestly? If that’s the case, I’m glad I didn’t get the job. That’s what a good hiring process is for; it’s a place where both the candidate and the company get to evaluate each other to make sure it’s a good fit.

Connect with Me

• Twitter
• GitHub
• Website