As part of our expansion I recently spent time again meeting and interviewing potential new recruits, which re-struck the question I’ve been asking myself for a long time: what are the key factors that differentiate a truly brilliant developer from the rest of the pack?
A long time ago I stopped crediting candidates based on their CVs, diplomas, titles or previous projects they were involved in, and devised my own type of tests which proved to predict pretty darn well how good a developer the person really is.
My Special Screening Test
What does that have to do with being a good developer you ask? well a hack of a lot! and surprisingly enough, I don’t even need the candidates to correctly or fully answer many of my questions; I sometimes pass candidates who did not know how to answer more than 50% questions. How come? Well, every question is an leads to a short discussion in which I give the candidate an opportunity to re-evaluate his answer, and more importantly allows me to get answers to the underlying key questions I’m looking to answer.
So what are the these key questions that predict a good developer? Without further adieu…
Good Developer Predicting Questions
Are They Curious?
Curiosity is key characteristic of a good developer, one who constantly seeks to expand horizons and learn new technologies, always tries to do things better and more efficiently, write less code by using frameworks and existing libraries and streamline his/her development by making use of automation, macros and scaffolding tools.
This developer is one who, while reading one technical article would spawn up 10 other browser tabs just to understand technical terms they stumbled upon in the original article, and maintain a “To Read” list of subjects they want to read more about in their free time.
Why is this good? Because in today’s world a good developer cannot be a one trick pony; gone are the days where you’d have “the X Expert” who knew one and only thing best. Today systems are written in several languages and use various frameworks, packages and tools, and that requires a new breed of “Swiss army knife” developers.
Are They Well Organized?
This one is one of my favorites, as you can pretty quickly pick up even from small code snippets the candidate writes if he/she’s well organized or not. And trust me; there is nothing more dangerous than a disorganized developer.
Organized developers write neat code, break applications into small, maintainable modules, while implementing the “separation of concerns” concept on every level. Their code is concise, clear, well indented and sparingly sprinkled with comments. They easily adhere to the project’s coding standards and happily and consistently follow them, their file structure and file name conventions are uniform, predictable and above all – manageable. And manageable code is good.
Do They Understand Software?
What kind of a question is that? All developers surely understand software you say! Wrong. I came across developers who previously worked on numerous projects and in multiple workplaces who did not understand the concept of modularization or did not know what a logger is, what a configuration is, candidates who thought HTML-5 is a protocol and Angular.js is a package.
For me, understanding software means “to call each thing by its right name” (Chris McCandless). In our context that means knowing what the “thing” (concept, technology, tool, library, framework etc.) is, what its purpose is and where is it located in the software world.
Typical questions I ask in this are the difference (if any) between HTML and HTTP, is TCP below or above UDP, what is Grunt, Gulp and Maven, what is django, what is CoC (convention over configuration), is language X a pass by reference or pass by value? Are asynchronous calls better than synchronous calls? What is a Façade design pattern? etc.
Needless to say most of these questions are tricky and their intention is to see if the candidate understands basic concepts of software development. I’m looking for answers like “this is a framework” (and not “this is a software / package”), “these are automation tools”, “that is a concept”, “HTML is a standard and language while HTTP is a communication protocol” etc.
Developers, who do not know these basic differences and cannot call each thing by its right name, imho cannot really be good developers.
Do They Moonlight?
This one is one of my favorites and I usually casually pop it up at the end of the interview, sort of as unrelated to the interview (however totally related of course). Here is the lowdown: good developers love software, and developers who love software always have some sort of side project they’re working on at home at evening or on their weekend.
Whether it is a real project they’re working on or just kicking the tires on some new technology they stumbled upon, the conclusion is similar: this is a developer who loves software and is most likely very likely a good developer.
Yes, I know…
There are other aspects that need to be looked with priority changing according to the project at hand (e.g. communication skills, teamwork ability, ability to stick to a job, sufficient experience with specific technologies/languages where applicable and so forth), however the tests I conduct give me a basic and very important indication of the potential the candidate packs, which personally for me is in most cases more important than anything else.
In my next blog I plan to finally put pen to paper on a subject I’ve been meaning to write for a long time, titled “Seven Habits of Highly Effective Developers”. That should be interesting, so be sure to stay tuned 🙂