After leading a relatively high number of developer interviews lately I feel like summarizing my experience – the things I look for in the candidates.
I’ve been always doing a 3-round interview:
- round #1: A 1.5 hour long test along with the other candidates. Some easy factual questions, some minimal coding, some SQL and some requiring logic and deeper thinking.
- round #2: a standalone, logically trickier program to code. I’m giving days to the candidates to solve it at home then send in the code.
- round #3: a personal interview. Developers who reach this point are mostly technically competent and lack big problems. This is the ‘fine-tuning’ phase, I could say.
These are the things I look for:
What makes the candidate ‘click’? Programming or creating?
By ‘programming’ I mean the urge to find out how things work, to control things, to fiddle with details and inner workings of stuff.
‘Creating’ kind of speaks for itself – it’s the warm and fuzzy feeling that gets inside you when you finally release the beast you’ve been designing and coding for weeks.
There should be a healthy balance as both are very important in this field. People who are only into ‘programming’ often lose the ‘big picture’ and don’t pay attention to other factors like priorizing, cost-saving, etc.. Devs who only like to create many times go into the infinite loop of ‘eternal design’ without ever producing any deliverable code.
Does the candidate seem like a person who feels projects his own?
Will he take responsibilty and ‘parent’ his projects? Specifications and needs are many times incomplete and devs who pay extra attention to their projects usually spot these ‘weak points’ or holes, thus they get fixed/covered before the release, not days/weeks after in the forms of bugreports.
School is important but it will never replace experience.
School is great and neccessary for a firm understanding of maths, structured thinking, etc..
Experience is king, things rarely work as specified in 10 years old books in the field of development. It’s even more true for online development.
Do I see the will to improve in the candidate?
Nobody’s perfect. Nobody knows everything. This field is ever-changing, devs need to keep updating their knowledge. Enthusiasm for the field is a must, they need to have that ‘fire in their eyes’ when they talk about their profession. People generally won’t improve only because of the fear of getting fired, they need real motivation – which greatly comes from their own enthusiasm.
I like to surprise the candidates with questions/problems from different fields.
It shows if they’re smart or only experienced in development. Begin smart and analytical is very important, they should be able to quickly analyze and solve problems in general, not only in development. It’s a different mindset which won’t form by simply writing tons of code. Look for the architect, not the coder.
Is the candidate prepared to “unlearn”?
Some methods, knowledge are just simply outdated, not valid anymore. Many people have trouble letting go of old knowledge – and it will mess with new knowledge in that field.
Is he able to focus and simply keep unimportant things out?
Unfortunately like the last point It’s hard or impossible to test. It’s very important when people come bugging him or there’s a ton of things to do and he has to priorize.
Teamwork.
Lone wolfs are fine from time to time, but being the part of a team is neccessary. Decent communication skills are required.. Also here ‘letting go’ can play role as sometimes someone else will take his work over. People get reassigned, etc.
Testing skills.
Lack is a no-go. They should at least have the right mindset.
Polyglot skills.
One language/platform is not enough. We all know this, a language is a tool and we need different tools for different types of work. People who are not able to switch tools are doomed in this field.
Have a whole picture – it’s related to experience vs. education only.
Experienced developers tend to have better overview and won’t get lost in the details. If you spend 2 weeks trying to figure out how to make a query work faster in MySQL, you’re probably wasting time. After a day or to you should have moved on to another solution and went on with the project.
Of course many smaller other things come into account, but these are the major points that came to my mind. Feel free to add your concepts!
After leading a relatively high number of developer interviews lately I feel like summarizing my experience - the things I look for in the candidates.
I've been always doing a 3-round interview:
- round #1: A 1.5 hour long test along with the other candidates. Some easy factual questions, some minimal coding, some SQL and some requiring logic and deeper thinking.
- round #2: a standalone, logically trickier program to code. I'm giving days to the candidates to solve it at home then send in the code.
- round #3: a personal interview. Developers who reach this point are mostly technically competent and lack big problems. This is the 'fine-tuning' phase, I could say.
These are the things I look for:
What makes the candidate 'click'? Programming or creating?
By 'programming' I mean the urge to find out how things work, to control things, to fiddle with details and inner workings of stuff.
'Creating' kind of speaks for itself - it's the warm and fuzzy feeling that gets inside you when you finally release the beast you've been designing and coding for weeks.
There should be a healthy balance as both are very important in this field. People who are only into 'programming' often lose the 'big picture' and don't pay attention to other factors like priorizing, cost-saving, etc.. Devs who only like to create many times go into the infinite loop of 'eternal design' without ever producing any deliverable code.
Does the candidate seem like a person who feels projects his own?
Will he take responsibilty and 'parent' his projects? Specifications and needs are many times incomplete and devs who pay extra attention to their projects usually spot these 'weak points' or holes, thus they get fixed/covered before the release, not days/weeks after in the forms of bugreports.
School is important but it will never replace experience.
School is great and neccessary for a firm understanding of maths, structured thinking, etc..
Experience is king, things rarely work as specified in 10 years old books in the field of development. It's even more true for online development.
Do I see the will to improve in the candidate?
Nobody's perfect. Nobody knows everything. This field is ever-changing, devs need to keep updating their knowledge. Enthusiasm for the field is a must, they need to have that 'fire in their eyes' when they talk about their profession. People generally won't improve only because of the fear of getting fired, they need real motivation - which greatly comes from their own enthusiasm.
I like to surprise the candidates with questions/problems from different fields.
It shows if they're smart or only experienced in development. Begin smart and analytical is very important, they should be able to quickly analyze and solve problems in general, not only in development. It's a different mindset which won't form by simply writing tons of code. Look for the architect, not the coder.
Is the candidate prepared to "unlearn"?
Some methods, knowledge are just simply outdated, not valid anymore. Many people have trouble letting go of old knowledge - and it will mess with new knowledge in that field.
Is he able to focus and simply keep unimportant things out?
Unfortunately like the last point It's hard or impossible to test. It's very important when people come bugging him or there's a ton of things to do and he has to priorize.
Teamwork.
Lone wolfs are fine from time to time, but being the part of a team is neccessary. Decent communication skills are required.. Also here 'letting go' can play role as sometimes someone else will take his work over. People get reassigned, etc.
Testing skills.
Lack is a no-go. They should at least have the right mindset.
Polyglot skills.
One language/platform is not enough. We all know this, a language is a tool and we need different tools for different types of work. People who are not able to switch tools are doomed in this field.
Have a whole picture - it's related to experience vs. education only.
Experienced developers tend to have better overview and won't get lost in the details. If you spend 2 weeks trying to figure out how to make a query work faster in MySQL, you're probably wasting time. After a day or to you should have moved on to another solution and went on with the project.
Of course many smaller other things come into account, but these are the major points that came to my mind. Feel free to add your concepts!
Also check out my post on how to be a better deveoper - you might even pass an interview ;)
Tagged as:
development,
improvement,
recruitment,
theory,
tools
Facebook
Google
LinkedIn
Twitter
RSS
Pingback: Tweets that mention Why I won’t hire you – a recruiter’s (re)view of developer candidates -- Topsy.com
Pingback: Why I won’t hire you – a recruiter’s review of developer candidates « Ballinger’s Professional Blog