New dates: Luxembourg (9-10 June), Brussels (16-17 June), Online (23-24 June)









Book a seat

Webinar summary

5 ways to (quickly) identify a good technical candidate for Technical Recruiters

Apr 28, 2021

In this webinar Hackages founder Davy shared five strategies to help you identify good technical candidates. These strategies were mined from his own experience hiring developers at Hackages, combing through their past experiences with smart questions and technology.

Here is a short recap of what was discussed.

What makes a good developer?

That depends on who you ask!

Each company has different requirements. It all depends on the types of projects and engineering culture a company has. A good developer at Facebook might not be a good developer at Google, for example.

However, there is a set of basic criteria that all developers should satisfy.

A good developer must have the following skills in his or her pocket:

  •  Algo (algorithmic knowledge)
  • Framework usage
  • Agile/Scrum: knowing how to work
  • TDD: test-driven development

The first criteria to identifying a good developer involves examining the strength of these skills:

1. Can they write and test code?

Writing code goes without saying, but testing is also extremely important for writing efficient software. You can evaluate their skills in this department by looking at their past experiences. Consider the following aspects:

Look at the technical stack he or she uses.

This gives an idea of what kind of technology that person is willing to use, as well as how complex you can take that person in terms of code.

For example, an app has multiple layers: the frontend and the backend, replete with databases and Ops. If someone is JavaScript all the way, they can work with each of the layers in the app in JavaScript. This means this person understands the complexity of frontend, backend, and databases, and is a signal that you can test them further.

Or, if a developer uses TypeScript, a framework like Angular and a framework like React Native, this tells you that they know how to write apps for both web and mobile. If they add that they have written a bit of Swift or Java code, this gives you more nuance about the engineering culture that they come from.


Test assessment: send them a test

You can send candidates an assessment to test their coding and problem-solving abilities.

Tests are usually very subjective to the company and to the recruiter.

You can use code quality tests or a technical test that contains criteria for the position they applied for (test them against the criteria of the job)

For JavaScript developers you can use, Hackages’ own testing tool. allows you to see in real-time how candidates are solving the problems, and the code and all performance information is available at the end. To be onboarded, request a demo or give Hackages a call and they will set you up.

2. Any OSS contributions?

Examining developers’ OSS (open-source software) project really removes the hurdles from getting to know them, such as obtaining permission from their current company to share samples of code with you, or the candidates themselves selectively presenting what they think you want to see.

By viewing someone’s OSS project, you can gauge how confident they are. Developers are artists. When an artist starts sharing their work, they are announcing three possible things: they don’t care; they want feedback; or they are sharing their expertise with the world. Hopefully, their reasons for sharing include the third reason, which reflects their confidence in their abilities.

Davy recommends asking developers the following questions:

  • Did you contribute to OSS projects? If so, which ones?
  • Are you currently working on an OSS project?
  • What motivated you to contribute to your project(s)?

You can even ask a candidate to send you an OSS project.

It is also a good idea to check someone’s activity on GitHub, where you can see the full range of OSS projects he or she has contributed to.


Insights from GitHub

We will use the case study of a candidate Davy came across to illustrate what GitHub activity reveals about potential developers.

Angular is an OSS project launched by Google employees. There are 30 core employees working on it.

But on GitHub, there are over a thousand contributors. Angular is accessible for contributions because it is open source. It is owned and managed by Google, but anyone can take it, hone a piece of it, and use it without impacting the original version maintained by Google. There are more than 1.8 million users (that could be tracked), and GitHub remains a place for developing experts to continually refine the framework.

From a candidate point of view, why did someone choose to contribute to Angular?

A developer told Davy that she encountered a problem that was coming from Angular and not from the code she had written. So, she sent a request to the Angular team on GitHub to amend their framework. The solution was accepted, and she had her fix.

This revealed much about this candidate: She had a problem with Angular, and instead of complaining to the Angular team, she wrote an ‘Issue’ (a request for a fix) and wrote the code to solve the problem. The Angular team accepted her code to be merged into the main version. This revealed a candidate who is 100% confident in her coding ability, and who is assertive in going after a problem.

GitHub activity thus reveals much about a person’s disposition and level of expertise.

3. Can he or she communicate effectively about the code they wrote?

The ability to effectively explain code reflects on how knowledgeable and capable a candidate is. For this, there are three types of experiences to keep a lookout for:

Experience with writing documentation

If someone contributes to docs on an OSS project on GitHub for example, you can see how well they understand their material.


By reading someone’s blogs you can see if that person knows that they are talking about and are able to express that in a graspable way. For example, one student studying computer sciences started a blog to express what he was learning and finally ended up working on the core Angular team at Google. Writing a blog means that someone can accurately define and express the problem.

Involvement in educational activities

When Davy had to teach people something that he knew well, he had to dig much deeper. That level of research allowed him to know the technology to the point that he could rewrite it from scratch. That depth of knowledge in a candidate is what you are looking for!

4. Engineering Culture: Open Source vs. Closed Source

Whether a candidate’s previous company is open or closed source tells you a lot about their individual engineering culture.

You can find this out by researching a candidate’s previous company on GitHub to see if it has open or closed source projects. For example, PayPal has a mixture of open and closed source, with closed source being more dominant. You can then go to the repository and see what code is used for each project and who is working on each project. With this you can also understand how Agile their former company is. Find your candidate’s profile and see what kind of code they wrote and how recently to get a sense of how they fit into that engineering culture.

Additionally you can do a simple Google search for the company’s engineering culture.

Davy recommends not to evaluate further than that, because there is no guarantee that person was involved in all the projects displayed on GitHub.

5. Their current stack vs. their preferred stack

There is a difference between technical stack developers use at work and their preferred stack. The stack used at work tells you a lot about their engineering culture, while their preferred stack tells you about their overall capacity.

Ask your candidate: is the stack you use for side projects the same one you use for work? Usually this is the case, because it is the one he or she feels the most confident in. If this is not the case, then this bodes well: side projects in non-work-dominant code shows versatility and flexibility.

Are they working on any side projects? For individual side projects, start evaluating by asking “what problem are you trying to solve?” Lots of people do side projects for fun. But you can use them to further understand your candidate.

It is also important to see if someone is working alone or in a team on their side projects. You can see this on their GitHub projects.


What’s next?

Here we summarized Davy’s top five tips to quickly identify a good technical candidate, and all of the questions and tools involved in getting to know someone.

The next thing to add to your toolkit as a recruiter: Java is way more than just the programming language. In next month’s webinar we will dive deep into the entire Java ecosystem, which will help you to better communicate with developers and hiring managers. Sign up here.

TechJargon also offers trainings to up your recruitment game. Come for a day to master all the technical terms you need, dive deep with a three-day masterclass, or let us design a custom training just for you and your team.

See you soon!

Check out the visual notes of this webinar:

< All blogs

You might like this too

The Java Ecosystem explained to Tech Recruiters

You may have recruited Java developers before, This array of positions already gives you an idea of why it goes beyond the mere programming language.

Read More

Dec 02, 2020

5 min read

Webinar summary

How to build a great engineering culture - Live talk with

Engineering managers Peter Paul van de Beek and Peter Brouwers joined us to share some wisdom: how they create a great engineering culture.

Read More

Dec 02, 2020

5 min read