Do you ever feel nervous before the technical interview because you are nervous about the coding puzzles? Do you ever think these code puzzles are blocking you from getting your dream job? If your answers are yes, then you are not alone.
After doing many technical interviews during my career, I found out solving coding puzzles is a skill of its own. It's a skill like other software engineer skills. The only difference is it's not related to your daily job. It's something you need to learn and practice for the interviews. For many years, I expected myself to take technical interviews with more experience and solve coding puzzles in a limited time (1-hour maximum). I can't. It's so difficult (at least from my side) to go to interviews where the interviewer asks you to solve a coding puzzle without a significant amount of preparation and practice.
On-time I got interviewed by a company. In this company, what they do is that they give you one business problem, and you need to build a solution for it in your time (take-home assignment). The goal here is to check whether:
- You can understand the requirements.
- You can make assumptions, state them, and build your solution on them.
- You can create a production-ready solution (with the time limitation).
- Can you communicate your solution?
- Can you structure your solution and How?
Testing engineers with a small scale of your business problem is one of the ways to test and assess the engineering dimensions you are looking for.
Is the hiring process broken? The answer is yes. I understand that companies need to make sure you are good enough for the job; this is fair. Are coding puzzles assessing the skills required for the job? The answer is no.
Let's check a story for two software engineers, one called Ali and the other one called Julia. In this story, I'm not stating that one engineer is better or worse than the other. They've different passions.
Ali is a software engineer working hard to learn new skills to improve his added value in his company. Imagine he's learning Docker, Kubernetes, and Terraform. He succeeds in building his team's deployment pipelines. After a while, he starts looking for a new job. Will the code puzzle shows and assess what he can deliver with his skills? I don't think so. What does Ali need to do to prepare for the technical interviews? He needs to set a time to practice and learn how to solve these code puzzles.
Julia is a software engineer focusing on competitive programming. She adds value to her company, but she sets a time to practice competitive programming. Imagine after a while; she starts looking for a new job. I'm sure she can ace the technical interview.
What I'm trying to say is this is unfair. These puzzles test one dimension of being an engineer. I feel this kind of interview is testing/assessing something other than what the engineer is hired for. Software engineers are hired to find solutions for your problems. Give them the time to work on creative solutions and ask them about them. Don't limit their creativity with time (You have 30 seconds to understand the problem, build algorithmic solutions, and fix the edge cases)
While I was writing this post, I was wondering and asking myself. Is it me, or are there others who can see the problem? Yes, some people know about the issue.
I was relieved when I read Jacob's articles about a framework to solve the same problem. I like his framework, and I hope there'll be a better way to interview software engineers one day.