This blog post helps you when choosing a developer. It presents the criteria for a good software engineer, especially if you don’t have experience with application development. It should help you prepare for an interview and give you some clues about which questions to ask and the details to which you should pay attention.
Photo credit: https://www.flazingo.com/
The first step is to know what you need:
- You’d like to build our own team of developers.
- You already have a development team. You are looking for engineers to join this team.
- You are looking for a complete development company.
This blog post deals with points 1. and 2.:
It is important for you to know the extent of our project and consequently, what tasks you need the developers to accomplish. What is the nature of your project: a mobile application, a web application, or both? What are the platforms, what are the languages involved?
Here, I will lay out the criteria for good software engineers. It is essential to be able to write proper code and that s/he is aware of modern development methods, but there is definitely more to a good developer.
On the ideal candidate:
- Must have ability to learn continuously and improve autonomously.
- Is creative, flexible, persistent and systematic.
- Has good problem solving skills.
- Can communicate with developers and also with business partners.
- Works well in teams. No matter how good s/he is if s/he can’t work with others. Nobody develops applications alone these days: even if s/he codes alone (which is rare), s/he has to cooperate with at least a tester and a designer.
- Takes responsibility for the work produced.
- Knows his/her abilities; time estimation is a challenge even for experienced engineers.
- Is precise; attends meetings and meets deadlines in a timely manner.
On preparing for the interview:
There are various software development terms that can come up during the interview. If you aren’t familiar with the basics, you have 2 options:
1. Have someone from your development team help you out. Let them ask questions regarding software engineering, trust me, it’s extremely time-efficient. Of course, this only works if you have a development team.
If you need to do it all yourself, here’s the more time-consuming method:
2. Prepare yourself! Use the internet to look for the basic terms and development methods (this might be a good start). Researching for yourself is less time-efficient, but in turn you get knowledge and that could pay off on the long run. This way you won’t need an engineer help you conduct the interview. Don’t forget though, just because you’ve done your homework, you are an expert. You can make yourself ridiculous easily, so ask questions first and don’t lecture an interviewee.
You have to look through your candidates’ previous works and choose the ones about which you’d like to know more.
Check out the references s/he has given you! Call some people up to ask for opinions about the given developer! And then you can ask about the references during the interview as well.
On giving out tests:
At Wanari, we don’t believe in giving tests. And here are our reasons:
- A test doesn’t tell you about the kind of person s/he is and whether this personality fits into your current or future team.
- During the personal interview, you should watch out
- for the 8 principles of the ideal candidate I mentioned above,
- for the way your candidate talks about his/her previous jobs, tasks, teams, superiors.
- Even if the candidate fools you during the interview, turning out to be a useless employee, you can say goodbye to him/her during the trial period. I have to say, this has barely happened at Wanari.
If you still want to have the candidate fill out a test:
- Specs must be clear.
- It is not too professional for you to give tasks taken from ongoing projects. It might hurt the company’s and your reputation. So if you think a test is necessary, make sure it’s not taken from a current project of yours.
- The size of the task should depend on your company’s reputation. Are you Google (or a company with a similar rep in your industry)? Then chances are, your candidate will be willing to spend quite a few hours on completing an assignment. If you aren’t too well-known, you might not want to risk it, so don’t give out anything that lasts more than 2 hours.
- There are all kinds of tests you can use – here are a few examples:
- Source-code analysis. Give a written piece of code to the applicant. Ask him/her to analyze it and find mistakes. (Mistakes that have been hidden in it.)
- Theoretical test writing. It is on paper as well, but we don’t recommend it. A candidate can learn definitions easily, but this will not make him/her a good software engineer.
- A complex word problem. You present the candidate with a hypothetical situation and give them a PC to solve it with code. You can check whether the code is running. What’s more, written on a PC, the applicant’s code shows (to trained eyes) whether it’s transparent and concise.
On conducting the actual interview:
During the interview you can observe some things:
- The personal questions are very important, they show the real traits of the applicant. Especially at small companies, team spirit is very important. Therefore, if the applicant doesn’t fit in the team, it might not be a good idea to hire him/her, even if s/he is a good engineer. An unfortunate choice of personality can generates conflicts, and those can negatively influence the efficiency of the team.
- Ask questions based on the CV and previous projects stated. You should let your candidate talk about their experiences and projects. If you come up with some questions mid-interview, ask them. Pay attention to their body language, too!
- Ask about his/her earlier employers. You must pay attention to what s/he says about them. Being a fair critic is not problem, though listing only negatives might be a warning sign. Even the worst places have some positives to offer and if your candidate can’t see or recognize them, he might be blaming his surroundings for his/her previous mistakes. If s/he doesn’t state any positives, the next question should be why they stayed there as long as they did.
- If s/he reveals private information about his previous work or previous employer, you must forget him/her – quite unprofessional and not too trustworthy.
Some ideas for questions:
- Is s/he intrested in new technologies? What are those new technologies? (If s/he isn’t interested, it might not be a good idea to hire them. If s/he is interested in new tech, you should find out what exactly.) Does it fit into tech profile of your company or project?
- Has s/he ever made a mistake? How did s/he handle it? How did his/her team react? (If s/he never made mistake his project, this is a problem too.)
- When it comes to senior developers: Which were his/her best and worst decisions on a give project? Why?
- Has s/he ever missed project deadlines or completion dates?
- Ask for an example: describe a huge problem you faced in a project. How did you solve it?
- Has s/he ever wanted to give up solving a problem? If not, how was it fixed? If yes, what were the consequences?
- Personality related: how do you react when somebody asks you to do something that’s beyond your abilities?
- Name a task or project through which s/he greatly increased his/her knowledge.
- Name a skill that s/he thinks differentiates him/her from the rest of the applicants.
On giving feedback:
If you know who you want to employ, you must inform the rejected applicants as well. Give candid and reasonable feedback to the rejected engineers, too. They will appreciate it and appreciate your business. You must know that the community of software engineers is pretty tight; your reputation might help you find just the right candidates by referral. So, taking your applicants seriously is key to your success when hiring developers.
All in all:
If you are hiring a developer, I hope I managed to give some directions you may take, some details to which you have to pay attention, and some actual tips you can take right away. In my opinion the personal features (team spirit, communication skills and the like) are just as important as the ability to code well. If your applicant has both skill sets, s/he might be the ideal employee for you and generally an excellent developer. These are the general principles by which we, at Wanari, screen our applicants.
The proof of the pudding is in the eating. It will be obvious whether your candidate can pick up the pace of a project or find his/her place in a team during the trial period.