February 12, 2020
I’m convinced no one likes interviews. Candidates dread it. Interviewers, hiring managers, and companies don’t like wasting time, especially if the candidate is lacking.
It makes sense for employers to run due diligence when considering a candidate to fill in a role. They wouldn’t want to hire someone just to find out a couple of days later they don’t know what they are doing. That’s not only detrimental to the team but a drain in the bank. Similarly, a candidate shouldn’t work for a company that raises many red flags like toxic work cultures and teams with poor direction and management.
Interviews are two-way streets: candidates should take the opportunity to interview the team and ask questions to learn about the company for fit.
I think we can agree interviews are smart to carry out for both parties. However, I’m not convinced there’s a perfect way of running them. A recent article from Hired on the State of Software Engineers stated:
Only 31% think coding exams effectively test their aptitude, while two-thirds say most coding exams are irrelevant to the daily job of an engineer.
Along with that metric,
42% of people said the coding exam is the most stressful part.
Isn’t that a rubbish experience for the candidates? How useful are the types of problems employers ask candidates to solve? Is being good at memorizing a very specific set of algorithms and problems useful for 99% of them? While it may be practical to measure some basic set of skills of computer science fundamentals, aren’t most companies putting an unreasonable amount of pressure on their candidates and turning away potentially awesome people?
I remember Gayle Laakmann McDowell mentioned top tier FAANG companies stress the fundamentals because they want to hire the cream of the crop and find it worth their while to sacrifice potentially great candidates to prevent false positives. The reasoning: exceptional candidates with strong problem-solving skills can still test as false positives, but at least there will be “less” of them. Less time is wasted. Less time is spent to find talent.
Sure, that can be tough to swallow if you never heard that before. Solution: If you don’t like it, then just don’t interview at those companies! There are tons of companies that don’t interview that way. It stinks, but I don’t think this is going to change any time soon.
It’s no secret I was unemployed up until recently. One of my previous posts celebrated my freedom, but also realistically I had been thinking about my retirement. I need to start working again to fuel my future!
As a side note, I’m a frontend engineer so I get the extra special awkward experience of not knowing how employers would interview me. They were usually one or a mixture of the following types of roles:
As a part of the job search process, I started to study. I knew I’d have to cram in the standard “irrelevant” things employers like to test you on, especially with the added fact that I didn’t know how I would be interviewed:
On top of those standards and since I advertise myself as frontend, I generally also go over these fundamentals:
As is standard for software engineering roles, the general process for every company I talked to looked like this:
Take this call as an opportunity to learn about the company. Depending on who you talk to, you may not get all your questions answered. For example, I generally take this time to ask about the engineering team structure, the tech stack, and the projects they are working on. However, recruiters may not know all the details here, but hiring managers may.
Sometimes you get to talk to the VP of Engineering. This is a great time to drill them on how they build the team and their engineering vision. If they cannot provide coherent answers, this is a great big red flag.
If you don’t like the product, service, values, or goals of the company, use that to gauge whether or not you would like to take the next steps. The entire purpose of the introductory call is for them to get to know a bit about you and for the company to sell you the idea of the job, team, and company.
Being able to weed out your candidacy at this stage is important for you to save time.
I had several different types of technical screenings, and spoiler alert, I do have a favorite.
Sometimes it’s a mixture of the screenings above are used. Don’t feel incompetent if a company requires more than one screening: it may be a normal part of their process.
Example sites companies asked me to use screenings. All of them had pre-generated links or profiles to use for the actual screening:
I prefer the takehome exams because more often than not they were more practical and relevant to my skill set and for the position. One I’ve had recently was not relevant to my job, so that was a bit annoying.
Each company has their onsite slightly differently, but it’s common to see the following themes:
Some companies will kick you out if you perform poorly during the early stages (savage) and some will keep you around until the end (hopefully they like you).
I’ve sat in on a couple of interviews where the last round was me sitting at a table full of people representing different teams: engineering, product, design, and customer support. It was a two-way round-robin of questions and answers, an excellent environment to get to see the dynamics of the team and to learn about the company quickly.
Although I don’t have a solution for the perfect interview for both the company and candidate, I think two things stand out from my recent experience:
Practical takehomes are beneficial to learn a candidate’s coding style and problem-solving skills. Candidates also get to carve out time to focus on the problem in the comfort of their environment without an over-the-shoulder peer. Onsite team round tables are great for many eyes to assess a potential new colleague and provide candidates the lens to see actual company culture. Though I can see it being disruptive to teams, it seems invaluable to get an excellent candidate vetted by multiple teams.
I hope better interview processes and experiences are created in the future to save everyone time and stress.