DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Are You Really a Good Full-Stack Developer?

Are You Really a Good Full-Stack Developer?

An industry exec and Agile team lead discusses four skills engineers are not taught in school that separate the okay from the good full-stack devs.

Nicolas Chabanoles user avatar by
Nicolas Chabanoles
·
Feb. 26, 19 · Opinion
Like (7)
Save
Tweet
Share
6.41K Views

Join the DZone community and get the full member experience.

Join For Free

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.

What follows can be applied to any technology the team may be using in a project.

The four technical skills I am always looking for in a full stack developer candidate are:

  • Being proficient with a debugger.

  • Having the reflex to write relevant automated tests.

  • Considering possible error use cases to help users to recover.

  • Providing useful log information to users (not to developers).

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!

Books suggested by Nicolas Chabanoles:

Clean CodeClean Code

CSS SecretsCSS Secrets

dev agile application

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Express Hibernate Queries as Type-Safe Java Streams
  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • API Design Patterns Review
  • Bye-Bye, Regular Dev [Comic]

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: