How to spot a bad developer in a few minutes
I have been in development for over 13 years with Aventique. During this time, I have recruited hundreds of developers, and more importantly, met thousands of them. Recruitment is not an exact science, but reducing the risk of a bad hire remains the ultimate goal of any process.
Sometimes, and not so long ago, I had to meet forty profiles just to pre-select 3.
Whether we are talking about backend, frontend, web, mobile, Java, C#, or JavaScript developers, it is possible to filter out average developers or those who lack the required level in an exchange of just a few minutes.
The recruitment process we use at Aventique:
- An initial 15-minute exchange to filter profiles.
- A second, more advanced interview (live coding, etc.).
- Final interview.
It is during the first exchange, and within just a few minutes, that I know if I will not recruit the developer I am meeting.
A good developer is someone who masters the fundamentals
Development is an intellectual profession where abstraction plays a major role; therefore, theoretical knowledge is essential.
The first red flag is when a developer tells me, “I’m not strong on theory” but “you can count on me when it’s time to code.” I am convinced that a good developer must be comfortable in both aspects. I have no desire to see the source code of a developer who doesn’t master or cannot explain basic theoretical points, especially as project complexity grows and technical debt becomes almost irrecoverable.
I’ll use an analogy with a doctor: imagine you consult them for a health problem and they tell you: “I can’t explain exactly what you have, but take this medicine, it will cure you.” Personally, I wouldn’t trust that doctor and would seek a second opinion.
The second red flag is when I hear—often from profiles with many years of experience—”I’ve forgotten that point; with my experience, I’ve moved past these types of questions and I’m focused on much more complex subjects today.”
To use the doctor example again: after 15 years of experience, a doctor will always be able to explain the difference between a virus and a bacteria.
To check a developer’s theoretical skills, here are some very basic questions I often ask. From juniors to seniors, I still get vague answers that demonstrate an inability to go to the heart of the matter:
Git
Git is the tool for sharing code between developers; it is also the tool that allows you to track the history of your source code modifications, among other things.
Difference between a commit vs. a push
Commit, local action: it saves your changes in the history of your local repository (on your PC).
Push, remote action: it sends local commits to the remote repository (e.g., GitHub, GitLab).
The goal: share your work with others or back it up on a server.
Even on such a simple question, I often get confused answers, even today! For more details on Git.
Object-Oriented Programming (OOP)
Most developers studied OOP during their degrees or master at least one object-oriented language: Java, C#, Python, PHP…
Object-oriented programming is a model where the basic entity is an object. If you want to develop a car rental application, we would need to create “Car” and “Customer” objects, for example.
What is a static variable?
I’ll take an object everyone knows: a Human. A Human has attributes specific to each instance (to each person) like height, weight, skin color…
A static attribute is an attribute common to all humans—the “species” attribute with the value “homo sapiens,” for example. This value can change (e.g., evolution into another species or scientific reclassification).
Many developers answer that static means the value doesn’t change; they think if we designated “weight” as static, it wouldn’t change. They miss the essential point: a static attribute can change, but if it does, it changes for every instance of Human (basically, for everyone).
In short, it is a class attribute (Human type) and not an instance attribute (linked to a specific human: John, Alex…).
JavaScript
JavaScript is the most used language today. It is used for backend with Node or Nest JS, frontend with React, Angular, or Vue.JS, and also for mobile iOS and Android with React Native.
What is a callback?
A callback is simply a function passed as an argument to another function, which will be called later, often when a task is completed or an event occurs. It is a function defined in one place and called elsewhere; it makes the code more flexible and decouples processes.
The concept of a callback is widely used in asynchronous programming (JavaScript, Python, etc.) to handle time-consuming operations (reading a file, network call, user click…).
If it’s not explained this clearly, it’s a warning sign because this concept is a fundamental.
Asynchronous vs. Synchronous
Synchronous: Instructions execute one by one, in order. As long as one operation isn’t finished, the next one waits. It’s like queuing at the bakery: the next customer waits until the previous one is done.
Asynchronous: Some instructions can be put on hold and execute later while the program continues. This is very useful for slow operations: network requests, disk access, timers… It’s like ordering a pizza: you order (request sent), you do something else, and when it’s ready, they call you (the callback/promise we explained earlier).
== vs ===
In JavaScript, it’s simple: 1 == “1” will return TRUE, even though the first is a number and the second is text, because the values are the same.
It only compares the value and not the type (here, integer vs. string).
1 === “1”, however, will return FALSE because, even if the values are okay, the types are not the same. Therefore, === compares both value + type.
What is a closure?
Many will struggle here and won’t be able to explain this concept.
A closure is a function that “remembers” the environment in which it was created, even when used outside of that environment.
More specifically, a closure is formed when an inner function accesses variables from the outer function that created it. These variables stay in memory as long as the closure exists. It is very useful for encapsulating data, creating custom functions, or simulating private variables.
Design patterns
Design patterns are common to all programming languages; a good programmer must know what they are and be familiar with a few.
What is a design pattern and name a few?
A design pattern exists to provide the best solution to a recurring problem. It is not ready-to-use code, but a structure or approach that helps solve a design problem encountered in software development in an elegant and proven way. Many cannot provide this definition of “the best solution to a recurring problem.”
When a developer cannot name any, they are simply not ready. Design patterns reveal a developer’s appetite for the necessary abstractions that will ensure they produce quality code later.
Among the best known, I would mention Observer, Strategy, Singleton…
The exhaustive list categorized correctly can be found at this link.
A good developer is someone with mandatory soft skills
We often hear about soft skills; I will cite concrete examples of developers I’ve met or recruited where the lack of soft skills makes the collaboration experience very difficult.
Soft skills are important because to project myself and say: “OK, I can see myself working smoothly with this person,” I need to see a certain number of qualities:
Active Listening
In an era where remote work has become widespread, a person who knows how to listen and remains fully present makes all the difference compared to someone who gives the impression of not being there or not understanding, even when they say everything is clear. Good collaboration between colleagues depends heavily on this.
Reassuring and signaling reliability
The ability to reassure, to step outside oneself and focus on the needs of the person in front of you, is undeniably a very important quality.
High Standards
A developer who needs to be told everything will quickly exhaust the team. Being able to identify what is truly important and having high standards will relieve the team when solving problems encountered during recruitment.
Self-Awareness
No developer is perfect. A sign of intelligence is knowing where one stands. The worst-case scenario is having someone give wrong answers to technical questions while believing they are good. I see this frequently.
Energy
The energy a developer radiates is an essential criterion. It is with this energy that they reassure others about their productivity, communicate when they encounter a blocker, put in the effort to resolve a difficult bug, or provide extra information on a complex technical subject. In short, this energy ensures they find their place and that no one else has to compensate for them.
Understanding the Business
This ability is reserved for the best and those with some seniority. A person who takes an interest in the real needs of users and the problem the application must solve will be able to challenge requirements and propose the best solutions by considering the right parameters—rather than diving in head-first and wasting time on issues that ultimately have no importance.
Conclusion
You now have examples of questions to use when speaking with a developer to evaluate their level.
Ultimately, if you are not equipped to manage a developer, collaborating with a web agency or a mobile agency can be relevant, especially if you have specifications ready. See how to write mobile app specifications.
The model of outsourcing recruitment to access skills based on your needs (full-time or part-time) is also a very good option depending on your requirements.
Additionally, for your recruitment needs, here is some useful information on developer costs (ADR).
