Talk with any software engineer, and they will gladly tell you that software engineer interviewing is sorely broken. There is an incessant thread of articles and opinions about how the interview process should be like. I contributed to the already vast literature around interviews a few years ago, when I wrote an article where I explored some learnings and personal opinions about interviews.
This time though, I'd like to look at the same problem but from a different perspective, trying to imagine and come up with what my ideal interview process, from a candidate's perspective, would look like.
By the very nature of this exercise, the result will be fairly biased to my own experience (and probably what I perceive as my own strengths). It will end up being more how I'd like to be interviewed rather than how software engineers should be interviewed, but it might still be useful and insightful, or at the very least trigger a constructive conversation on this topic.
Let's first look at some overarching guidelines I wish where built into all interview processes. At a minimum, interviews should be humane, transparent, and fair. Now what do I mean by that?
Interviews are (for the most part) human interactions. As a candidate, I would like to be treated as a fellow human, and the interviewers in the process should be cordial if not friendly. As much as possible, the interview process should be accommodating. I want to be in a position where I am comfortable enough to perform at my very best. Creating such an environment is also beneficial for the company, as they can assess candidates at their best. Being considerate of people's time is also something I wish to see in my ideal interview process. Do companies really need a week to get back to a candidate after a 30-minute interview? Ultimately, interviews should be treated as an exchange of ideas and a learning opportunity from both sides of the table.
My ideal interview process is transparent. Starting from the job description, it is clear what the company does, which are the requirements for the position, and what are the steps that comprise the interview process. During the interviews, I'd expect plenty of opportunities to ask questions about the company, the job, the team, etc ... Finally, regardless of if my profile ends up fitting the position and the company, detailed and actionable feedback should always be freely provided at the end of each step.
At last, as this is in a way a utopic exercise, my ideal interview process is fair. The company should have a clear idea of what signals they are looking for in a candidate, and how those signals correlate to success in the position they are interviewing for. As such, most questions asked during the interview process should be related to the actual day-to-day role. I would also expect the interview process to be as unbiased as possible. In practice, that means, among other things, having a multiple and diverse set of interviewers to interact with.
Now that we have set up some guidelines, let's get into the format my ideal interview process would have.
Of course, it all starts with the egg (or was it the chicken?): the job description. As described in the above section, the job description should be, among other things, as accurate as possible about the role. Do I need to perform guitar solos on a weekly basis? Then you probably don't need a rock-star engineer! In my ideal process, my resume (and cover letter if required), would be reviewed by a fellow human being. If my resume gets rejected, it would be highly appreciated to get some feedback as to why my profile didn't match, instead of a generic rejection email, or just plain silence. That is even more true if my application ends up being rejected, not by a human, but by an automated system.
Companies might base their decisions on a lot of diverse factors, but ultimately the interview process fits the purpose of assessing candidates for their skill set and their culture fit. A lot of keystrokes have been exchange about the best way to assess software engineering skills, with each side of the debate bringing up decent arguments. As this is my very own ideal interview process, I will unapologetically talk about my own perspective on the matter. Not everyone needs to have publicly available code (e.g. on GitHub), but if I make the effort to maintain open-source projects, I expect my interviewers to pick cues and signals from those, and only require coding challenges if they are unable to check all the signals they are looking for. Please, don't make me write yet another weather app as part of your interview process ...
Writing code is arguably the easiest part of the job as a software engineer. My ideal interview process would focus a lot more on understanding existing code, communicating as a team, and being able to understand and break down complex problems. None of that requires me to spend a week-end (or more) writing some useless code. Most interview rounds should be centered around conversations about tech, past experiences, and future perspectives. Culture fit should very closely tie to company values and have a predefined set of questions and signals to look for in candidates. Conversations about culture fit should provide enough room for candidates to reverse interview the company they are applying to.
Usual last steps in any interview process include reference calls and contract negotiations.
I've always doubted the actual utility of reference calls, other than checking that a candidate has worked with a couple of people with whom they got along well. The signals provided by reference checks are usually extremely skewed towards candidates, as most people won't volunteer references that might not talk in glowing terms about them. It feels like the very last chance companies give themselves to uncover any red flags their process might have missed. As such, my ideal interview process would go without any reference checks and instead trust itself and the interviewers to uncover all the needed signals to make an informed hiring decision.
Now, my ideal interview process will also go without any contract negotiations. Salaries and career paths should be completely transparent and clearly communicated during the interview process. Signals gathered from the process would then put me in the corresponding box in the grid. There is a lot to say about salary negotiation and how not having transparent compensation schemes in companies hurt underrepresented groups in the workplace, so I won't paraphrase what more eloquent people than me have expressed multiple times.
Finally, as signing a contract is usually the beginning of a journey, my ideal interview process would very naturally flow into my ideal on-boarding process, but that's probably a discussion for a different article!
If your company's interview process looks surprisingly similar to what I've described above, and you are looking for a software engineer, please feel free to reach out!
Top comments (0)