Technical Interviews Are Not Completely Broken
Technical interviewing is all over the place. Some people claim the system is completely broken and it might be more efficient to pull a random name out of the pile. But the process has remained unchanged while the times have moved forward. The majority of the companies are still using a whiteboard to test candidates' knowledge, including both common and not-so-common algorithms, data structures and brain teasers.
For a lot of candidates, this can be a terrifying experience. It can be humiliating, discouraging, and even depressing. Especially for those who are just out of school or haven't interviewed for a long time. I have been on both sides, both interviewer and interviewee. In my career, I have conducted over 500 interviews and interviewed at top tech companies as well as startups.
Having experienced this confusing process firsthand, I want to share my thoughts on it.
Knowing how to code doesn’t equate to good interviewing skills. The key is preparation. If you're not prepared, you have a reduced chance to showcase your real expertise.
Learning data structures is important, not only for your interviews. It will make you a better programmer. The most common data structures are Arrays, Dictionaries, Linked lists, Trees, Stacks, and Queues. Your programming language has them incorporated. Just like having more than just one hammer in your toolbox, knowing these data structures gives you an option to use the right one for the job, like picking the right tool.
This topic is the most criticized part of the interview process. Is it important to know how to reverse a linked list or to decode an alien dictionary in order to become a productive software engineer? Most people will agree, that the answer is "no". Why do the companies continue asking these questions, then?
The answer is to test problem-solving skills. The nature of software engineering is to solve ambiguous and hard problems using technology. Although most engineers rarely have to use fancy algorithms to solve these problems. Knowing common algorithms and data structures make you a better problem solver. The more problems you solve, the more you can connect them and build mental patterns.
Interviewers only have 45 minutes to assess your knowledge and make a decision if you will be an effective contributor. It's not an easy task. The cost of making a mistake is high, which is why the interviewers choose more difficult challenges than real life.
Imagine being asked about the "find the closest bikes" challenge. You are able to explain why you're using certain data structures and understand what the O(n) time and space complexity are, then chances are high that you can figure out how to query a database and return it as a JSON.
If you took the time to study and prepare, it's a good indicator that you have discipline and patience, which you'll need to be an effective contributor and grow in the future.
I still think there are more effective ways to test someone's skills. Either build a small project or pair program in the real codebase on a new feature or to debug an existing bug. But unfortunately, it's not realistic for many companies. It will take more time and effort for interviewers, who are not big fans of doing the interviews in the first place. Interviewers are software engineers too, and they want to code. Every interview interrupts their schedule. Besides the actual interview, they need to prepare, review your resume and think about what they should ask you. After the interview, they have to write down detailed feedback about the candidate and often meet with other interviewers or the hiring committee if there is a disagreement on the final decision.
Don't get discouraged
Almost everyone has failed technical interviews, and it can be a humiliating experience. If you fail, use it as a learning experience to identify your weaknesses and practice more. You'll start seeing patterns and cross-reference the different problems you've solved in the past. Remember, knowing how to build software doesn't translate to successful interviews.
An interview is a sales pitch, where you're trying to convince an employer you're capable of solving complex problems. And hopefully, an employer is selling their company as a great place to work. It shouldn't be a one-way conversation. If a company is asking ridiculous questions or not treating you well, perhaps it's not the place you belong in or the type of company you want to work for.
Don't forget that it's a conversation. If you're stuck, be honest about what you know and what you don't know. Ask for help or syntax if and when necessary. Collaboration is one of the qualities they will evaluate you on. If you're asking the right questions, generally moving in the right direction, it's okay to ask for some hints and bounce some ideas back and forth. It's impossible to know everything.
Interviewing is an acquired skill. The more you do it, the better you get as an interviewee and software engineer. It's like a sport or public speaking. You can memorize words all you want, but as soon as your time to perform - you forget almost everything. That's why practicing is important. Start small: ask your friend to interview you, use services like Pramp, interview.io, and others. The best resource so far is LeetCode, where you can try to solve as many problems as you can. One of the best resources to study common algorithms is AlgoExpert (you can use my coupon
sjtul-65 to save 15%);
Studying for interviews forces you to learn new concepts and re-learn what you have forgotten, including programming fundamentals, data structures, and common algorithms. Even though you don't use them for everyday tasks, it's still important to know them.
By solving different interview challenges you can discover different ways to approach problems: logical, mathematical, algorithmic.
Preparing for interviews will make you a better software engineer.