Senior dev interviews are broken

In my career, I have done more or less 100 interviews, either as an interviewee or interviewer. I noticed that, in the last years, the interview approach changed following the Google/Spotify approach but very few companies are able to apply it correctly.

Let's start with what happens before the interview: it's rare that someone does care about your articles or open-source projects that describe your background. These kinds of projects, if the candidate has one, tell a lot about the candidate's attitude and mindset.

In general, the interview process focuses on the least part of a senior dev day-by-day activity.

When you work as a senior software engineer you'll pass 90% of your time reviewing code, writing documentation, gathering requisites, defining testing strategies, and having an idea about how to structure the service you're working on.

The latter is a very important part: defining how to encapsulate integrations with external systems is fundamental to having clean and readable code. Knowing how to implement the business logic with pure functions having strict control on function calls and dependencies (mocks) is fundamental to covering the business logic with meaningful tests. Quite no one asserts these skills during the process.

Instead, Interviews are designed around the activities senior dev does 10% of the time. The usual steps followed by companies are:

• Coding
• System design
• Troubleshooting

Coding

This activity is like "find the solution to a Hackerrank/Leetcode problem". That's meaningless for a senior dev. Solutions to Hackerrank problems are easily manageable by anyone who has a graduate or a couple of years of experience. A senior dev is typically able to find and implement a solution even if not optimized. An optimal solution is just a matter of the right intuition at the right time, nothing about seniority.

If the goal of this step is to understand if the candidate is able to write some code let's do this differently. Propose some requisites and check if the code is written well and provided some tests. That's all. Just to filter imposters.

It's really hard to fake clean code writing, separation of concerns, and test-driven mindset. But to find the optimal solution at the first sight is something doable by any dev, with some luck.

System design

This phase might have a sense. But, from my experience, there is a tremendous dependence between the information given by the interviewer and the final result of this step.

Designing the best and optimal solution to an unknown system design problem is a matter of how well the counterpart is able to communicate the requisites. No one cares about the fact a senior dev is aware of patterns: asynchronous communication (queues), synchronous communication, different type of storage (relational, document), cdn, and load-balancing. Everything is focused on: did the candidate find the one that is considered by us as the best solution? Even this is a matter of the right intuition at the right time.

So, start asking about very specific choices in very specific parts of system design. For example how to integrate with third-party systems, which kinds of tests to provide, and how to deal with third-party outages. Or what is the best pattern to follow for time-consuming yet best-effort tasks? Those kinds of questions are very hard to fake and the responses are the consequence of authentic expertise.

Troubleshooting

This is absolutely the worst and most meaningless part for a senior dev. Obviously, if a developer has more than 1 year of experience, he/she did some troubleshooting on a running system. What's the point in asking troubleshooting questions without having a real system where to investigate?

A good way to test the seniority in this step is to ask about an issue the dev already solved in his career. How did the dev address it? How information was gathered? What suggestions were taken from the information? Which changes have been suggested to improve the system reliability? What were the issues that caused the system to fail? Did the fix involve also organizational changes?

In the end

As far as I've seen in my career the "best" candidates are the ones that are able to overfit themselves in passing interviews, not the ones with the best experience in the role.

An exception to this is top companies (MAANG) that are not looking for seniority and expertise, but their main focus is to hire the smartest people in the world. Then the brain teaser questions have some meaning. Even though people invest up to 2-3 years in overfitting with this kind of brain teaser approach. And, we're back to the previous point.

For all the others: they should be aware that they are not hiring the best candidate but the candidate that had the right intuitions at the right time and did the right questions during system design and troubleshooting. The same candidate might have badly performed if the interview was the day next. There is no objectivity in such a process.

Alternatives

Good alternatives to the steps above, in addition to the different approaches already stressed, are:

• Ask how the candidate would write documentation for a given Github project. And let the candidate write it during 30 min interview. (Even though documentation is supposed to be written during the development)
• Ask how the candidate would test a piece of code or a system. And ask for further questions about the reasons for the approach in testing.
• Ask the candidate what is his approach to product development since part of the time of a senior dev is to understand and support product definition.

Results

The result of this process is that some good practices are not empowered in companies like tests or developer experience or any other expertise-related approach. Companies hire for intuition and luck and this influences, even more, the gap spreading between the needed expertise and the one existing in the team.