Inefficient technical interviews: Remembering algorithms means nothing
Technical interviews
Hello! Of the readers here present, how many times have you had to go through a technical interview for a software development position? Surely many, many times.
We're already used to having to face technical interviews. 1, 2 or even 3 technical interviews for a hiring process. The typical "share your screen and solve this algorithm problem in X minutes". Or the open question "Explain to me how a binary search tree works and give me an implementation example in whatever language you want".
Usually these interviews are supervised by the technical team, even the team leader or the CTO. The idea is to evaluate your technical knowledge, your problem-solving ability and your way of thinking.
How are problem-solving processes in day-to-day work?
Well, this goes a bit based on my experience, clearly I'm not a sociologist or psychologist, but it's very noticeable that not all people approach problems in the same way. Some take time to analyze the problem and then execute it very quickly. Others need to meditate in silence, make diagrams, write pseudocode, etc.
In my case, due to concentration issues, the fact of talking and thinking about a solution is tremendously counterproductive. It doesn't let me read clearly, it doesn't let me think clearly. I need silence, concentration and time to analyze the problem. Then, once I have the solution in mind, I can explain it and write the code quickly.
But live algorithm resolution processes frustrate that dynamic a lot. The process expects that, while you think, you're revealing everything you're thinking to the interviewer. What for? Well, it must have its reasons, but the practice is that it's not for everyone. Some people feel uncomfortable talking out loud while thinking, others simply can't concentrate that way.
Does remembering algorithms mean anything?
Well, this has nuances, knowing algorithms makes you a person who seeks efficiency in your solutions. But the fact of remembering 30 algorithms and knowing how to implement them to the letter, doesn't mean you're a good developer.
But it can mean that you're an applied person, who studies before an interview and cares about the position you're applying for.
The point doesn't go through preparing or not, in fact I think that a large part of interviewees prepare to face a technical interview. The question is: Is it worth preparing by doing Leetcode exercises?
What really matters?
Before hiring a new member for your team, you should ask yourself: What do I really need from this person? What tasks will they perform day to day? What technologies will they use? What level of experience do I need?
Of course it's not strange that in specific moments, especially in large applications, performing iterations on information processing, calculations, caching management, etc. May require specific algorithms to optimize performance. But in most cases, a developer won't be implementing these algorithms, the reality is that in high-level languages, many of these structures and algorithms are already implemented in standard or third-party libraries.
Do we waste time creating A/B trees from scratch when solving some feature? The truth... I doubt it. Maybe there are jobs that are dedicated to this, but it's not common.
Let's go to what we do in frontend
Here I address my personal experience, I don't think it's valid to speak for any type of job, but in this sense, if you're hired as a frontend web developer, most likely your day-to-day consists of:
- Implementing user interfaces based on designs provided by a design team.
- Consuming APIs to obtain and display data in the interface.
- Optimizing web application performance.
- Ensuring compatibility between different browsers and devices.
- Applying i18n and accessibility concepts.
- Working and implementing microfrontends or reusable components.
Now, it's not the only thing, there are always many collateral elements, but in general, these are the most common tasks.
Questions for seniors
Cookie management and policies, security layers, performance, search engine indexing, use of native browser functions, image compression, real-time rendering, design systems, correct use of stores, fetching strategies, testing, module federation, packages, code splitting, CI/CD. Have they asked you this type of questions? The truth... very little to me, and I think it's fundamental. For example, do you know IndexedDB? Do you know how caching works in browsers? Do you know how service workers work? Do you know how to optimize a web to load fast on slow connections?
I would love to face interviews that allow me to talk about these topics, I think that for a senior professional, asking them to remember a DFS tree doesn't bring much value, but yes talking about performance, security, architecture and good practices.
What about communication management questions?
For me, practically absent. How do you face a critical problem when one of your developers who has been working on a critical feature that must go to production in 2 days, suffers an accident that incapacitates them for a few days? How do you handle a situation where 3 days before finishing a sprint, they change all the planning knowing that it will negatively impact the team environment? How do you explain to your team that we need to work overtime to meet an important deadline without demotivating them?
A senior must know how to communicate these situations. Waiting for a Project manager or a product owner to pat you on the back and tell you "You have to work overtime" is not ideal. A senior must know how to communicate to the team the importance of meeting deadlines, but they must also know how to listen to the team and understand their needs.
Situational and conversational interviews
Dialogue in an interview, with an open question, can be much more enriching. It allows the interviewer to know how the candidate thinks, how they approach problems and how they communicate. Additionally, it allows the candidate to show their experience and knowledge in a natural way.
Normally, in day-to-day work, when a proposal or an issue to solve comes up, the ideal is always to talk about the topic with some colleague. It works a lot for me. What do you think if we approach the problem in X way? Do you think we should evaluate the performance of what we're going to solve before uploading it? This type of relationships not only enrich the work, but also foster a collaborative and continuous learning environment.
Many times it's said that seniors in a company should be open to mentoring, and yes, it makes a lot of sense. But at the same time, that senior can't measure with a standard yardstick any person who is starting. A person with high seniority doesn't have such an abysmal gap in technical knowledge with other peers. Your seniority, after many years, is given to you by social experience, empathy and the ability to listen.
What about non-seniors?
Talk about your projects! What impact do you think what you've done has had? What did you learn in your previous jobs? How did you handle situations that escaped your current seniority? How do you communicate with your colleagues? How do you handle feedback?
This doesn't mean we don't expect a solid response based on technical knowledge, but in dialogue, that happens naturally. If a person has worked on real projects, they'll surely have a lot to tell. And if they haven't, well, it's an opportunity to know their desire to learn and grow.
So, I would NOT do technical interviews
It may sound risky, but when you're looking for seniors, you know perfectly when a person is one, just by talking to them. What do I care if they solve an algorithm in 20 minutes, if they don't know how to configure headers to protect their requests, what do I care if they remember a heap sort if they have no idea how to use workers to optimize background processes. It can't be more irrelevant to me that they remember the sliding window algorithm if they can't handle React rerenders well.
Let's talk about what's relevant then, let's talk about reactivity, storing, fetching, performance, security, dependency auditing, testing, accessibility, i18n, SEO. And above all... Let's talk!
To finish, being a bit contradictory, I'll make some articles talking about a few algorithms that can save your life in a technical interview. Don't learn 20... Learn 3!