Sourcers and Recruiters are not very technical in general to have the ability to do a deep dive of the prospective candidate’s technical abilities. Technologies keep changing rapidly, and we are moving from one technical role to another as per client requirements (internal or external).
The least we can do is read up on it, utilize our previous experience, and make the candidates talk about their abilities, their implementation, and their pet peeves in a way that we can understand and make sense of it.
How can we expect to develop such a capability?
Picture this; You are a new sourcer or recruiter on the block, and your supervisor asks you to work on some development roles (C#, Python, etc.).
Action 1: You have no idea what those technologies are and how they are utilized. You utilize search engines, but the information is just way over your head.
Action 2: You ask your colleagues to explain in layman’s terms what those are. Sometimes you may get a satisfactory response or sometimes not so much.
Action 3: Now, the task of finding relevant profiles stares at you in the mirror. If it’s a structured organization, they may have available search strings in the database that you can execute and pull up the profiles that do look like meeting at least 80 – 90% of the job requirements.
Some sample queries they may end up utilizing for a C# developer in London, UK, for example, are:
site:uk.linkedin.com/in C# (developer OR engineer OR specialist OR expert) London
site:uk.linkedin.com/in (“software engineer” OR developer) C# London
If they went ahead a step further from a competitive analysis angle, the following URL would be another avenue to look at:
https://topsoftwarecompanies.co/united-kingdom/c-sharp/web-development/agencies/london
A deeper search would probably entail searching local meet-up groups in London or visiting the Microsoft Partner Network and choosing “Application development” via “Find a Partner” link.
One would get a list of partners who have C# development skills with added granularity in terms of the partners being the best match or most responsive or nearest in terms of geography and then go about cross-referencing the companies in Linkedin to source C# developer profiles.
The challenge is to understand and decipher the actual experience the technical folks claim to have.
Action 4: Google is your friend. You would sheepishly type “How to assess software engineers” OR “Interview questions for Python developer” OR “Assessment questions for C# developer” etc.
It turns out the questions are too technical in nature, and even if you were to attempt asking those questions to the prospects, you would probably not be able to understand what they are saying is true.
Fret no more! Here are the things you could do to obtain a better understanding of the individual’s background:
Any development project is either brand new or an enhancement of an existing solution or a legacy code migration. You could ask the prospect that if it’s not clear from the resume.
Every project has an objective. Find that out.
Then you can go about the following:
Structured code development utilizes modular structure so that it is easy to rip and replace in the future or for better code maintenance and readability. You can ask the developer, “Which modules did they work on?
Compared to the previous era, the programming has become easier than before with a lot of tools, frameworks that a developer can readily use to code quicker. To stoke, a developer’s ego, ask which tools/framework they love the most and why? Which ones they absolutely dislike? Why?
Listen very carefully to the disliked ones (If your client or your firm has similar tools or frameworks, the prospect is going to dislike working in that environment)
Development projects are rarely single personnel based. Ask about the size of the project team for the last 2-3 projects.
Good Developers develop a re-usable set of code for specific activities. Ask which programs they have developed that they re-use regularly.
The development team grows bigger as more feature requests come in or new product planning is initiated. For a senior developer, ask how they have hired people junior to them, which should give a good understanding of their insecurities or look forward to hiring great people for the team.
Developers are usually asked to provide time estimates for the coding effort for certain tasks. Ask them how do they arrive at it? Also, ask for an instance where their estimates turned out to be very inaccurate, and what was the reason for it?
Quite a few developers work on open source projects as part of their self-interest or to make themselves more attractive to a desirable employer. Do ask if they have worked recently on any open source projects? Which one among them gave the maximum satisfaction? What tools/ libraries did they use for it? Just because a developer does not have any open source projects as part of their portfolio, it does not mean they are not good or less desirable.
Developers may have their own tales to tell about good and not so good situations they may have experienced with their managers. Ask for examples of such situations and how they managed situations.
Developers are given specific tasks, and they start working on them. After a few days, suddenly, there may be a scope creep. Ask how they handled such a situation.
Code reviews are an integral part of a great product or solution. Ask what techniques they adopted to do code reviews. What issues do they generally find? Any memorable examples of an issue that they can remember? (For Senior developers)
Developers list several skills in their profile/resume. The key is to know the latest usage of these skills in their projects. If it is anywhere more than 2 years, expect rustiness in their ability to use it to the optimum level, but they can always pick it up soon.
Once you get comfortable talking to developers over a period of time, here are the TOP 10 developer questions you could potentially use regardless of the technology:
In conclusion, developers are like us. They make mistakes, implement lessons learned, experiment where it’s feasible (not on production code, obviously) and automate certain things.
Even if we do not know what it is that they are doing or using, the ease with which a developer can convey their knowledge or experience to you tells you everything about them. We are a facilitator to make them come out of their shell and have a reasonable conversation, and this guide shall assist you in getting a better understanding.
