Recruiting: The market waits for no one

Can you recall an example where you needed a software engineer (aka a developer) for one of your projects, products, or services? If you had some project work or an ongoing full-time position, did you have any challenges getting enough candidates to screen? And what did your screening process look like? Do you use external frameworks in your process, or have you devised one independently? Rather than posing filler questions, I am genuinely curious about how you approach the knowledge worker market – IT or Legal. I’d be delighted to hear some of your insights, so feel free to reach out to me if you’d like to share a story or two.

In our case, every time we had a hiring campaign (for software developer positions), we noticed the following:

Asymmetric demand dynamic

As digitalization becomes mainstream, demand for developers is generally on the rise. However, not all software engineers fare the same; some are showered with offers weekly (so I am told), while others face some friction.

Historically, senior software developers were in high demand; the trend will likely continue in 2023, barring some hiccups. On the other hand, juniors are continually facing rising bars at entry-level positions.

An influx of new talent in IT

The IT industry was famous for its employee benefits and remuneration packages (relative to other sectors), attracting people to join at various life stages. Universities are continually expanding their programs, private schools are opening shops, and online courses for virtually any tech are abundant. The supply of staff in entry-level positions is seemingly on a steady rise. It remains to be seen how, if at all, the advancement of AI tools will influence the demand for junior developers (there are arguments in both directions, but that is outside the scope of this article).

Erosion of seniority titles

To my knowledge, no uniform criteria delineate junior from senior developers. The tech advances quickly, the argument goes, and any standard set today would likely be obsolete by lunchtime. Years of experience used to be a factor, but in a changing market, years spent in a position is a number that doesn’t say much.

Without a standard, seniority too is bound to be subjective. Every organization has its understanding of what makes someone a senior developer. Discrepancies are not uncommon. It is not hard to imagine situations where candidates believe they are senior (and thus expect to be treated accordingly) while recruiters beg to differ.

Cutting through the noise

Lately, we have noticed an ever-increasing number of candidates on the market that claim (close to) senior titles.

As a result, one of our process objectives is to check whether candidates’ view of seniority matches ours. It requires no explanation, but this is necessary to determine candidates’ value proposition to our company. In other words, we must find common ground concerning the value we could bring and exchange.

Naturally, there are many ways to reach that goal; what we apply and what works in our case is detailed below:

Slice and set clear goals

Organizations find different ways to structure their recruiting activities. Usually, processes involve a combination of introductory meetings, technical discussions, (algorithmic) tasks, presentations, etc.

In our case, we opted for the following structure:

Introductory meeting

This is, of course, the first opportunity for a candidate to learn more about the organization and related details (outside their research). Our objectives at this stage are to get to know one another; we dedicate a considerable chunk of this meeting to answering any of the candidates’ questions about the position, opportunity, organization, our values, etc.

Likewise, we are curious to learn about them too. Consequently, we ask a set of carefully crafted situational questions to get a better feeling of what they could be bringing to the table and their own value perception.

Finally, we elaborate on the next steps and process ETAs.

Technical discussion

At this stage, we speak with the candidate about their technical background and probe into their hard skills. Usually, we apply a combination of on-the-spot questions, tasks, or requests to read portions of code and translate it into plain words.

Depending on the tasks’ complexity, we might give them some timeframe for returning results or ask them to resolve the problem during the call (both approaches have pros and cons).

The goal at this stage is to determine how candidates’ relevant experience translates into their technical mastery.

Final presentation to stakeholders

More often than not, people from different teams and levels would likely have to work weekly or even daily with people that join our team. For this reason, we always involve them, as their feedback (and subsequent engagement) is instrumental to candidates’ success.

This stage involves a combination of technical and interpersonal discussion. If we have assigned a task, this is likely where the candidate would present and defend their implementation.

The goal at this stage is a bit more nuanced. We want to observe and understand the interaction between candidates and our colleagues; hard skills are critical, but the “chemistry” should also be right.

Different people at different stages

You might already find this intuitive. Just in case, I want to stress why having different people lead different stages of the process is paramount.

In addition to ensuring buy-in from all stakeholders, it is even more important to cover potential blind sides. What is critical to me might be utterly irrelevant to you, and vice versa.

Likewise, I make sure not to share notes between interviewers, at least not until we have reached the final stage. This is especially helpful in achieving a “consensus” on candidates. In other words, we are aiming to get more or less a similar impression about the candidate from various angles and by using different methodologies.

We feel we are driving this process in the right direction if we achieve as much. Conversely, if something doesn’t add up, it’s a sign for us to reconsider and recalibrate some of our practices.

A framework to steer the evaluation

If you use a framework in your recruitment, you will already recognize the benefits of having one.

In the initial stage, a framework will enable you to pinpoint topics of interest that you or your colleagues would want to touch upon, craft questions that will help you reach the insights you are after and steer the discussion by asking follow-up questions, if initial answers do not get you exactly what you needed.

After the introductory meeting, the framework will help you collect your conclusions and map out how you view your first impression of a candidate. Visualizing your findings makes it relatively easy to share your impressions with other colleagues in the process and benchmark against other candidates.

In later stages, the framework will help you understand value, its perception, and how it broadly matches your company’s values. Discussions with successful candidates concerning remuneration and other issues can be supported by arguments you derive from applying a clear set of rules and standards. Negotiations are substantiated, meaning your proposals are pretty easy to explain as a result.

Finally, candidates feel you genuinely value them, because you can give clear feedback and explain how and why they matched certain expectations during the process.

It is up to your organization to choose what framework to use, as this will depend on your strategic goals. We use “Engineering Ladders” as a baseline and adjust our activities to our needs. This approach has many benefits, which I may address in a follow-up article.

Be as fast as possible

The market waits for no one. Consequently, you must design the process to deliver both insights and speed. There will always be trade-offs, of course. However, make sure to cut out the deadweight from the process, because otherwise this might jeopardize your recruiting efforts.