Hello random reader that’s browsing this content, if this is the first time you’re here, then you probably reached this site by google searching or you’re probably a technical recruiter or someone that clicked on my website’s link, any kind of reader you’re, THANK YOU VERY MUCH FOR BEING HERE, please get comfortable.

Today I’d like to write some thoughts that I’ve been having around the technical recruiting processes and of course specifically around IT roles, if you’ve read my previous posts, you migh be thinking that this is only salt, but if you read carefully you’d realize that I like to point things that are normalized of that have become the rule for no reason, so let’s go ahead and deep dive.

The Players

First I’d like to describe the main entities that usually get involved when a technical position gets opened:

• The manager or stakeholder: The one that requests a new position or role to be filled during the process
• The technical advisor: The one that describes/writes the technical description of the role
• The technical interviewer(s)/reviewer(s): The one that actually performs a technical interview or reviws the technical test if any
• The HR Manager: The person who supervises te actions to perform in order to get filled the position with the help of his/her team.
• The recruiter: The person usually on HR that’s activelly searching for the right candidate and is usually the first filtering point
• The company: That big or small monster that’s looking for more people to join and the culture around it
• The candidate: The person that might or might not be a good fit for the position

There are other entities that might play also a role in the process of hiring a programmer or engineer, like a code testing platform, a staffing comitee, but those are not always present so I’ll not get into details of those.

The Process

On the other hand let’s describe in general terms how a typical recruiting process happens in this industry, this can be a little bit different depending on your company or the company you’re applying to:

• The manager or stakeholder requests for a new position: There’s a lot of motivations behind opening a new position, like filling the place of someone that left, or growing the current team or simply by the need for new skills in a team or newly created area. At this level I think the most benefitial actions for this role is to get involved in the definition of the role with the help of the Technical Advisor, specifically the tasks that will perform, the skills that are a must those those that are desirable. Why? Because you’re the requester, like a product owner that is pursuing the success of a product, make the shift from project view to product view. Here’s where things can be set for success or failure if there’s a lack of definition and expected outcome. If you lack from definition, then you’ll probably get something way to far from what you expected. The output of this stage should be a sketch of how the role should look like, what’s expected from the new guy, the tasks that should be executed, the level of seniority and a salary range.

• The technical advisor creates or writes a job description. This is another super important part in the process, in this stage, the tech advisor usually goes deeper than just definitions made in the previous stage, since he’s the one that somtimes currently performs the role to be filled or at least knows what’s missing in terms of skills or knowledge or what the stakeholder is looking for. The technical advisor must be meticulous and make informed decisions, because he’s going to write a blueprint of the ideal candidate, this definition is usually made as a wish list, but it also needs to be realistic or the role will never be filled. If you define a Chuck Norris, you’ll never get someone or you’re probably not going to meet his monetary needs. The output from this stage should be a technically validated[1] blueprint of the ideal candidate, that can be later validated as well by the manager/stakeholder and that will be passed along to HR.

• The HR manager reviews the requirement and writes the “final” requirement that should be the public version of the role and I’m using quotation marks because I strongly belive that the final version is the one that everybody agrees on. Also, the HR manager or the recruiter should check with the technical advisor or technical interviewer, the technical tests that are required for the position, although this is sometimes more tied to a default which shouldn’t be the case, I’ll go deeper on this later on this article. The HR manager should also analyze against some data or empirical knowledge, how big is the offer out there for this set of skills, also match the budget with the offer and demand to make the role atractive and competitive for potential candidates. The output of this stage should be a curated version of the technical blueprint for the role, including soft or social skills needed for the position, the salary range and seniority that make sense for the position, and the validated process that the candidate should follow, including legal and political constraints.

• Once the blueprint gets validated by all parties The recruiter, publishes the output from the previous stage in some professional and job recruiting platforms like LinkedIn and others, and also starts searching using tools their tools, gets a list of potential fits for the position, and start scheduling some second interviews. Sometimes the second interview is also performed by the recuiter to validate that there’s match with the desired vs. the candidate’s profile, the recruiter also validates that the salary range meets the required by the candidate, that the kind of job and role is what the candidate is expecting to be and that the candidate also matches the company’s culture. The output of this stage should be once filtered, a set of summaries of the candidate’s experience, expectations, actual and expected salary range, the candidate’s CV, and why this is a good fit for the position, and also some scheduled technical interviews if applies and or next interview.

• The candidate performs one or a set of technical tests or technical challenges. This challenges should be a direct reflect of what the candidate work should look like in real life[2], also some key skills that the candidate should posess and some other things that might challenge him, depending on the role, this could include coding, predefined code tests, code fixing or completion, technical questionaries, or any creative solution that will challenges the candidate’s knowledge and skills, and that can filter out those undesired candidates[3]. It’s also good to mention that there are roles that don’t require this kind of tests and also there are companies that don’t require this kind of tests for some positions, and also this stage the others can vary in the order that happen. The output for this stage should be a report on how the candidate performs on a defined environment and also which skills probably lacks, and also this test helps recruiters identify outliers and how a particular candidate compares to others in this particular test or set of tests.

• The technical interviewe/reviewer performs a technical interview or reviews the test/asessment performed by the candidate or both. In a technical interview the interviewer usually asks for things that might be skipped or hard to measure through technical test, also the interviewer should be looking for skills like problem solving or critical thinking if needed for the role, the candidate should be showing social skills like communicating complex ideas, and how he performed on previous jobs or projects that make sense for this positionand on the other hand, the interviewer should make the right questions based on all the information that he already knows in advance and also based on what he has read about the candidate. The output from this stage should be a technical report to describe the technical skills that the candidate shines on, also sometimes the interviewer/reviewer provides a suggested level/band/category depending on your organization, to provide a map of the seniority or experience of the candidate, it’s also important to mention that sometimes there are several technical tests mainly when someone thinks the candidate might be a good fit but it still needs to get more practice or show more skills around some particular topic.

• The manager or stakeholder interviews the candidate, this stage can also happen at any point of the contact with the candidate, but almost always the candidate knows his manager through a videoconference or meeting where he’s asked and interviewed to show her or his non-technical skills and or soft skills. The output from this stage should be a report on the candidate’s soft skills and non-technical skills, and also the manager/stakeholder should be able to validate that the candidate is a good fit for the position and the culture of the organization.

My Two Cents

For the initial contact please include:

• The Job description
• Sallary range
• Seniority
• The process that the candidate should follow

This will make sense a lot for the candidate, since he’ll know if that matches his or her experience and also if the money, job, description and or seniority is right for him, and will reduce the amount of manual work to be done.

I’ve participated in lots of hiring processes, and also worked closeley in processes for other members of my team and on different teams.

If I had to design a process for hiring a new candidate for ANY role it would be like this:

• Someone requests the position and gets accepted and opened.

• The technical advisor creates a blueprint of the ideal candidate.

• The technical advisor writes a job description.

• The recruiter sources for potential candidates.

• Those candidates get matched in conjunction with technical staff and HR.

• An initial informal interview is scheduled and performed with HR and technical staff. And here’s where my proposal comes from, this very first interview should be to align the candidate’s career goals with the position and see if there’s a match, sometimes companies focus on hiring the best qualified guy or the most impresive CV and this people gets borred by the actual BAU tasks, if you perform an informal interview to see what are his or her motivations, you’ll probably see if he’s looking for a long career inside the company, and also what are his or her expectations for the position.

• Then move forward with the technical process. BUT without a screening test, I think it adds a lot of preasure to check for someone’s creative and problem solving process when coding or executing a technical task, and also rude IMHO. I think you can validate tehcnical knowledge by asking scenario based questions and see the actual candidate’s reasoning or process around the task. Instead of making him or her code a quick sort (which actually somebody already did before), which makes no sense since that’s not gonna be real life working. You should probably ask instead which framework would you use for task A or B and see if it has the real reasons to justify the choice or choices, and if needed, go deeper and ellaborate on the response, instead of making them write code that will not help anyone but the script. If you need to really validate something like code quality and or proficciency around a task that can be self-paced, that gives the candidate:

  • Trust, since they will let you accomplish the task however you wish, even if that implies asking to someone else, which we all do all the time in our work.
  • Independency, you can manage your own time and let the recruiter know what will be the expected time to accomplish (or the company can define a deathline, which is good also, but flexible is better).
  • Creativity, if you let space for creativity the person will certainly do that if you encourage those conditions and also will drive to better results
  • A safe space, if you know your environment, time and everything, you’ll be performing awesome since that’s how you work, and not in uncertain conditions stablished by someone and that are not tied to reallity.

• If the candidate meets technical criteria and professional criteria then add anything else you need but you at least have a validation of the person around two significant pieces for the role.

• If the candidate doesn’t meet the required criteria, then the company MUST be forced to share feedback for the candidate, it’s really annoying and rude to just don’t get a response and be noticed that the process has finished in the best case. Please be aware that even if the company doesn’t decide to make an offer, this was a potential candidate to be part of the company’s culture and what kind of message are we sending if we just say nope?

Well those are my two cents around this, as you can see, this post should have been published around october 2021, but just now I’ve managed to finish the write of this post.