Are You Really a Good Full-Stack Developer?

As the manager of several Agile teams for the last 7 years, I have had the opportunity to hire more than 20 people for our development team. To do this, I had to conduct 100+ interviews to find the best candidates. And I sorted through thousands of CVs.

Here’s what I learned, and here’s what you need to know about what a hiring manager is looking for to grow the team.

First, my thoughts on the process of hiring good full-stack developers. When hiring, I always publish job descriptions with the list of technologies the team is using and that the candidate must be proficient with. For example:

• Backend: Java
• Front-end: AngularJS, ES6, Bootstrap

So here when I am talking about a full stack developer, I am looking for a developer who is able to work on the Java backend to improve the business logic, as well as adding new web pages in the front-end. But honestly, the name of the technologies is not what is important.

As you can see from this list, these skills are not tied to any particular language but are around software craftsmanship. That is what I want to see in a good full-stack developer profile: the application of these skills to both front-end and backend development.

Of course, there is a problem — these skills are often not taught at school! It is then your responsibility as a developer to learn them on your own. If you are lucky enough, you will find a job where the team has already mastered these skills and will teach them to you. I believe that only developers who have learned and are good at those skills will achieve really great work and be respected by their peers.

In order to identify whether the candidate is a good full-stack developer, I challenge their skills by asking them to implement a small application. Code is the truth! It is a lot easier to understand the habits of a candidate by going through a technical challenge. Let me give you examples of what triggers my internal alert system in regards to the four previous criteria:

• Debugger: During the code review challenge, I add a small live coding session. If the candidate adds a bunch of temporary logs and then starts the application to find out what happens at runtime, then adds more logs to get the value of a particular variable and restarts the application, and so on… Deal breaker! What a waste of time. Using a debugger will give you a more efficient way to understand what is going on, and will not mess with your production code. This debugger test is generally applied to front-end developments where I have had far too many bad surprises with candidates’ debugging techniques.


• Automated tests: If the code presented by the candidate has no automated tests attached, I ask why. In the worst case scenario (inspired by true stories), the candidate tells me that in his/her past team he/she did not add automated tests (for any “good” reasons) and that it is not part of their best practices. I just stop listening and lose interest in the candidate. Deal breaker!


• Error management: I like to challenge candidates with error management. How does the application behave in case of error? If the answer sounds like: “I just display the technical error message to the screen.” What!? The purpose of any application is to help users automate their tasks. It must help the users to accomplish their objectives. It is especially important in case of error to provide users with useful, actionable information:
  • Describe the problem and the system state.
  • Announce the cause, and suggest how to fix the problem.


• Logs: I like to ask the candidates when they log information and to what purpose. If the answer sounds like: “I mainly log information to help me debug my code when an error occurs, to understand what happened.” Oh no! While debug logs are useful, this is not the sole purpose of logging. Having good log information is invaluable to administrators. They can use logs to monitor the application health or detect security breaches, for instance. Good developers should never forget that the applications they develop are not only for them but mainly for end-users who will rely on well-formed and well-presented information.

If you do not feel proficient with the four skills my team and I are looking for in full stack developers, I strongly suggest you spend a bit of time in acquiring those skills. It will only improve your expertise and give you more chances when looking for a new position.

If you already have — or when you acquire — these skills in your toolkit, then I am pretty confident you are/will be a valuable team mate that your team feels lucky to have around!

This article was originally published on DZone