In the fast-paced realm of technology, where innovation is the name of the game, a burning question echoes through the minds of job-seeking tech enthusiasts: How can you stand out in an industry that’s always on the move? The answer might surprise you.
Join us on a journey where we explore the delicate balance between specialization and versatility, the pitfalls of diving too deep into one topic, the art of maintaining professionalism in your career narrative, and the power of asking insightful questions. In this exclusive interview, we engage with a seasoned tech luminary, Vassil Popovski, who unveils the keys to mastering ‘boring’ technologies as your secret weapon to triumph in your next tech job interview.
Popovski’s extensive career spans various sectors and roles. Currently the owner of CTO Quest, he specializes in guiding companies to success by addressing technical, people, process, and organizational challenges, offering CTO services. Just recently, he became VP of Engineering at Alcatraz AI. In 2023, Vassil served as an Interim CTO and Technical Advisor at Taylor & Hart. His investment experience includes roles as an LP at LAUNCHub Ventures in 2021 and Eleven Ventures in 2020, along with angel investments in SessionStack and CEO Angels Club. As Chief Technology Officer at DesignTechnologies from 2022 to 2023, he led a team of 35 engineers. Vassil’s prior tenure at Leanplum saw him in leadership positions, including VP of Product Development and General Manager of Leanplum Bulgaria. He co-founded Connecto.ai in 2016, serving as CEO until its acquisition by Leanplum in 2018. Earlier in his career, Vassil played key roles at VMware.
This article is the third part of our “Mastering the Tech Interview” series. Check out Part 1 where we learn what’s the “Wow Effect” CTOs are looking for and Part 2 where we discuss the new AI battlefront in tech interviews!
The Recursive: What are some common technical interview mistakes you’ve observed, and how can candidates avoid them?
Vassil Popovski: I’ve noticed a few common mistakes. First and foremost, some candidates tend to dive too deep into a specific topic during the interview. Typically, technical interviews have a predefined agenda, specific areas that candidates need to cover. As the interviewer, I have a list of technologies to assess and I also look into the candidate’s previous work experiences to gain a clearer understanding of their background. Often, candidates get too fixated on a particular question or technical detail, which, of course, can work in some cases. However, most of the time, the technical interview has a structured framework that needs to be followed. This is one of the mistakes – candidates overly focusing on one specific aspect.
Secondly, speaking poorly about previous employers is another common mistake. It reflects a lack of maturity and professionalism.
And third, in my opinion, candidates not asking enough questions can be a pitfall. Regardless of the type of interview, whether it’s for leadership/management positions (which I’ve been conducting more frequently lately rather than technical roles), I always aim to put candidates in a mindset where they understand that the interview is a two-way process. It makes no sense for me to like and hire someone only for them to join the company and realize it’s not a good fit for them.
There needs to be mutual chemistry, and candidates should be proactive in asking questions. I encourage them to do so. Towards the end of the technical interview, there’s typically time for candidates to ask questions. They should know that during the final roundtable discussion, where the interviewer shares their experience with the candidate, one of the criteria is whether the candidate showed interest in the company and asked questions. Simply answering questions without engagement is considered passive behavior. Besides, if the candidate does not ask questions, they might not even receive an offer, as this is viewed negatively.
One more thing that has piqued my interest is the optimal number of interviews needed to assess a candidate’s suitability. Google conducted a study on this since they have thousands of candidates and interviews. The result, which I highly value and apply in my practice, is 4. After 4 interviews, the candidate’s success rate (which is the primary criterion for how many interviews are required, how long they take, and what the performance reviews will look like in the company) plateaus significantly.
The difference between 4 and 10 interviews is just a 1% or 2% increase in the probability of success, which is minimal. From a candidate experience perspective, 4 interviews may be the optimal number for the company to learn enough about the candidate and for the candidate to understand what the company is all about. Some companies boast about having a very fast interview process, claiming they can make a decision in just one hour, but I find that somewhat unserious. It’s a different extreme. For junior positions or internships, it might work, but for senior positions and above, 1-2 interviews are insufficient. The only way to truly understand the company, its work culture, whether it’s a good fit, and how well the candidate can integrate into the team is through 4 interviews. So, 4 is the optimal number.
Could you share an example of a particularly impressive technical interview performance? What set that candidate apart?
It really depends on the seniority level I’m interviewing for. When I interview candidates for junior or intern positions, my main focus is whether they can write code. They don’t need to be familiar with a specific algorithm, although Binary Search is quite a fundamental algorithm that I expect most candidates to know, but I don’t necessarily expect everyone to be familiar with it.
However, if I explain Binary Search to candidates, I do expect them to be able to write it afterward. This serves as a kind of hire/no-hire filter – can the candidate write a standard Binary Search? After a candidate writes Binary Search, I give them an additional task, not just to find where a particular element is located… i.e., its arbitrary position but also to tell me how many times it occurs. For example, if you’re searching in an array like 1-1, 2-2-2, 3-3, the candidate should be able to say that the ‘2’ appears from position two to position four, inclusive, meaning they can provide a range where the element occurs and not just the first occurrence. To achieve this, they need to perform another Binary Search, but with some modifications to make it more efficient. Throughout my career, out of over 500 interviews for junior and intern positions, only one candidate has accomplished this, which I find surprising because it’s not an overly complex task.
I attribute this to the fact that, in many companies, programming is somewhat of a craft. I don’t say this disrespectfully, but in my opinion, a strong candidate, whether junior or senior, should have a solid foundation to build upon. For junior and intern positions, this foundation consists of algorithms and data structures, which are taught in the first year of university. Many people somehow overlook this aspect.
It’s one thing to watch ten Udemy videos on how to write a React application. You’ll probably learn how to write React, but when it comes to computer science – algorithms, data structures, algorithm complexity, and how to make things as efficient as possible, that’s often overlooked by candidates. But for me, it’s essential because otherwise, how can you evaluate a junior or intern candidate? I don’t expect junior or intern candidates to be experts in a specific framework because they’re still junior. I expect them to have learned the fundamentals in university and not just memorized them but to demonstrate skills such as describing a simple Binary Search. For senior positions, however, the criteria are slightly different.
For senior candidates, what impresses me the most is not just knowing how to do things but knowing when to do them. Many candidates, if I were to ask them right now, could provide excellent answers on how to implement microservices, how microservices collaborate, which frameworks to use. But very few candidates know when it’s the right time to implement those microservices. Often, companies rush into ORM engineering and introduce microservices much earlier than necessary. I always say, ‘When instead of how.’
To me, this sets senior candidates apart from junior candidates. It might be counterintuitive, but younger candidates tend to get caught up in the hype surrounding new technologies, technologies that haven’t been tested yet. Senior candidates, on the other hand, rely on ‘boring’ technologies, but in 95% of businesses, those ‘boring’ technologies are the right ones. Especially in recent months, when I’ve been collaborating with various companies offering CTO-as-a-Service, I see this clearly. In some very specific cases, you might use Go for high performance, but I genuinely see many companies running on PHP, and that’s perfectly sufficient. Facebook is built on PHP, it’s been modified, but WordPress (Automattic) is one of the billion-dollar unicorns globally, and it’s based on PHP. That’s why I say, junior candidates easily get carried away with new technologies.
If I’m hiring someone at an architect-level, someone above senior, a technical leader, I expect that technical leader to prefer ‘boring’ technologies but to have mastered them and know how to apply those ‘boring’ technologies in the most effective way, rather than jumping on the hype bandwagon and saying, ‘Let’s write this in Rust because it’s trendy.’ But why would you write it in Rust? To make it high-performing. But does a website with 10,000 monthly visitors really need to be high-performing? Again, I say, ‘When instead of how’.
What are some effective ways candidates can demonstrate their problem-solving abilities and technical skills during a technical interview?
Personally, I use standard techniques to evaluate problem-solving abilities and technical skills during an interview. For problem-solving, I assign a homework task that takes a few hours to complete. However, this can be a double-edged sword, as it demands a significant time commitment from the candidate. In some of the companies I’ve worked with, we offer a hybrid approach where the candidate can choose to solve the task at home or during an on-site technical interview. Speaking of on-site interviews, I’ve rarely been conducting in-person interviews recently, but when candidates choose to solve the task remotely, they are given a specific challenge, something to code. It’s a cooperative process where you can see how the candidate writes code.
For candidates who are more introverted and prefer to sit down and think about the problem, we give them a homework task with a several day deadline, followed by a discussion during the technical interview. However, to ensure that the candidate came up with the solution themselves and not someone else, precautions must be taken. This approach works well, but it’s essential to strike a balance. The balance lies in combining tasks or questions with a brainstorming session lasting around an hour and a half, where a problem is posed, thoughts are shared on the problem, and code is written collaboratively. Writing code is a crucial part of the technical interview process for me.
Joel Spolsky, the creator of Trello, had a highly active blog that he actively developed between 2000 and 2005-6. He also wrote a book called ‘Smart and Gets Things Done: Joel Spolsky’s Concise Guide to Finding the Best Technical Talent‘. One of the important things he mentions that has stuck with me and that I use often is this: In a circus, when you hire a juggler, you want to see that juggler juggle. The same applies to programmers. When you hire engineers, regardless of the role, it ultimately comes down to writing code. So, coding should be an integral part of the technical interview, whether it involves homework tasks, standard tools, or any other method to assess how a candidate writes code. Even if a candidate sends their GitHub repository with the code they’ve written, that’s sufficient. You need to see if the candidate has experience in writing code. Otherwise, everything else is just noise.
Do you prefer candidates who are domain experts or those with a broader range of skills? How can candidates strike the right balance between specialization and versatility?
It entirely depends on the type of company and organization. In DesignTechnologies, one of the companies I’ve worked with, we were migrating from PHP to Java. At that time, we explicitly wanted to hire several high-profile Java lead-type architects. In such cases, specialization was necessary because you expect these individuals to have deep knowledge of Java since they need to demonstrate to others how to write quality Java code.
However, in other setups where you just need to add someone to the team to help with specific tasks, you incorporate enough time for the person to be properly onboarded and get into the workflow. In that case, you’d prefer more versatile skills. It really depends. If you’re a very small company and, for instance, have strong AI projects, then you’d probably prefer to bring in an AI person with AI skills. But if the company has grown a bit and has gotten larger, then you start looking for more versatile skills within the various teams.
For small companies, it’s a bit risky to hire people with very specific skills if it turns out you want to change technologies at some point. But, at the same time, in the early stages, it’s good to have more specialized, niche expertise rather than something broader. So, the answer is that it really depends. I believe a candidate can be valuable in both setups, both with narrow and more versatile experience. It also depends on the company. This should be assessed early in the interviews, and the candidate should be able to ask questions and determine what the company values—whether it’s breadth or depth—and tailor their responses accordingly.
In an era of remote work and distributed teams, how do you adapt your technical interviews to assess a candidate’s remote collaboration skills and self-discipline?
I think it doesn’t differ much from office work. Generally, you look for small things—first, whether the candidate will arrive on time, how they’ve structured their CV, whether there are many spelling errors—these are signals of a lack of discipline. As for remote collaboration and self-discipline, a lot of it relies on references because these things are hard to verify in the technical interview process.
That’s why companies have a probation period because you can’t have 100% success from one interview. In most companies, I’ve aimed for an 80% success rate. That means out of 10 people, you might have two wrong hires. Otherwise, if you aim for 100%, you risk reducing your success rate because you start looking for candidates who are close to perfect. And if you fall below 80%, you risk the interview being too superficial.
That’s why you have a trial period and references that help you evaluate the candidate. I really like references—how the candidate performed in other companies. Regardless of the questions you ask about remote collaboration and team collaboration, you can easily see when the candidate hasn’t done this before. You can easily reach a ‘no’ for that candidate, but it’s very difficult to be 100% certain and say, ‘Yes, I’m sure this candidate has done all of this.’ You can easily weed out about 15-20% of candidates with a few questions like ‘What did you do in the project? How did you collaborate with others? Did you help others?’ You can easily get to red flags that tell you this candidate isn’t suitable. However, these questions can’t give you the certainty that the candidate is right for you, which is why it’s good to seek references.
In your opinion, what sets apart a good technical interview from a great one?
For me, the great interviews have been the ones that are two-way. It’s not just me asking the candidate, but the candidate also firing questions my way, and for some things, even challenging me.
For example, some time ago, I had decided that it was time for one of the companies I worked with to implement microservices. The team had 50 people with the idea to grow to 150, and with part of the re-platforming, we decided to implement microservices. I interviewed a lead architect to help with this transition, and perhaps half of the interview was him questioning me and asking why we have decided to implement microservices and if now was truly the right time.
He wanted to make sure he wasn’t going to a place where microservices were being introduced too early. That, for me, is a great technical interview, and I was absolutely sure I wanted to hire that candidate. Other people interviewed him as well, and we all liked him a lot based on this.
To me, a great technical interview is one where there is a lot of back-and-forth. The candidate asks various questions, I question them, and I feel there is a connection, something between me and the candidate. Somehow, we reach something that we can work on together. The candidate shouldn’t be afraid to ask challenging questions.
As a leader in tech, how do you see technical interviews evolving in the next five years to keep up with the changing industry landscape?
Perhaps AI is the changing factor here. AI can be useful in validating code. Currently, websites like HackerRank rely on the fact that they have tests for each task, and when you submit the task, they run the tests to see which ones pass and which ones don’t. However, these sites still don’t evaluate the quality of the code. Whether the candidate has used the right algorithms, written quality code, followed coding conventions, and so on.
I believe that AI, given its rapid development, can be of significant assistance – meaning it can perform automated code quality checks and, accordingly, assess whether the candidate writes quality code or not.
But writing code is only 10-15% of the engineering work. The other part is the personal touch – that’s indispensable. I believe these tools will help better assess core engineering skills, but they won’t be able to assess whether the person is a cultural fit for the team, whether they’ll fit into the environment, or how they’ll work with others. That’s why human interviews and experienced interviewers are still necessary. That won’t change.
Perhaps the first part – code quality checks – can be automated and made better, but the second part – the personal touch – will remain. How people work with requirements, what systems they use, and the actual act of coding. As I mentioned, that’s a small part of engineering work. There are many other aspects that AI can’t verify, at least not at this stage, at least not in the next 5 years.
What guidance would you offer to aspiring junior developers who may be experiencing discouragement due to concerns about AI potentially displacing their roles?
It’s a fact that AI is currently at the level of a junior developer. If you describe the task very well, AI will excel at it. So, it’s certainly capable of taking over some junior developer functions. But let’s not forget that the idea behind a company hiring juniors or interns is not for these people to stay in junior positions for a long time. It’s not about cheap labor – the idea is to catch someone very early in their career and successfully develop and shape them according to your company’s processes.
So, what I can tell them is that juniors need to become non-juniors very quickly, and in my opinion, that’s the path. Right now, there are plenty of opportunities and resources to help them learn and get better. As I mentioned earlier, coding is only 10-15% of the job, and they should be interested in understanding the business requirements. They need to think about how the code they’re writing actually helps the business. If they can demonstrate that quickly, I believe they can grow in their careers rapidly and leave behind the junior label.
If they can go past the junior role, which they should be able to do in a year or two, they have nothing to fear anymore. Because there are even jokes that in order for AI to write quality code, clients would have to describe their requirements perfectly. Describing clear requirements is very close to writing code, right? So, AI can never fully master that – understanding when and in what cases you do what. Young professionals just need to focus on quickly raising their level. That would be my advice to them.
