Let’s turn the dev hiring process upside down.

Every now and again I come across articles on Hacker News about how there is something wrong with the recruitment process. Books have been published on how to deal with it, how to iron out the creases on your CV, whether or not to include a photo and if so — what it should look like. One of such articles was the undeniably seminal “F*** You, I Quit — Hiring Is Broken”. It was much talked about back in the day, winning as many advocates as it had opponents. On the one hand there were those tired of the current form of recruitment, sympathising with the author. Then there were ones quick to point out it took recruiter blaming to a whole new dimension, what with their being bound by formal criteria. Still, both sides largely agreed there might have been something wrong with the recruitment process itself. Roughly at the same time I chanced upon some podcasts on what a daunting task negotiating your salary could be. It was then that I also found out there even existed people whose job was to help you with the latter.

This was exactly why I decided to take a closer look at the whole of the recruitment process and the problems lying on both sides — both the developers’ and the recruiters’. I started reading up on the subject and ask both groups questions. The subject matter kept coming back to me at regular intervals and gave me new food for thought as well as allowing me to draw new conclusions every time.

If my observations are right, then the following problems can be defined:

Developers’ side:

• If not looking for a job, they would not like to keep being informed about new possibilities of employment.
• Job adverts are unstructured — form reigns supreme over content, terms and conditions of employment are not presented clearly enough.
• Talking about the salary is the stressful part of every job interview. Candidates fear their demands might scare a potential employer away. On the other hand, they are also concerned they may not be sufficiently appreciated and end up underpaid.
• There are concerns that should they come across as underqualified, they may be tempted to lower their expectations with regard to the pay during the actual interview, compared to their pre-interview estimates.
• Another concern is that by presenting your thorough profile, you may end up being discriminated against or being offered relatively poor terms of employment due to certain characteristics (such as your gender or background).
• Lack of information about the salary bracket in numerous ads, which makes even ballpark estimates as regards a company’s financial capabilities impossible.

Recruiters’ side:

• A lack of a selected target group — knowing who is available would make it possible for them to come up with much more personalised offers.
• Annoyance with no response whatsoever to either social media- or e-mail- based job offers. In other words, recruiters often end up addressing people who may not be interested in changing jobs at that given moment.
• Having a set budget for salaries at certain positions while not being allowed to openly present it in job adverts.
• Candidates’ demands as presented during the interview, which do not tie in with what the company can offer.

As you will certainly have noticed, recruitment-related problems are not solely bound to the interview but start ahead of it. At the risk of overgeneralisation the current proces can be described as follows:

1. Most developers are in employment and not currently looking for new professional challenges. There are also naturally those looking for a job. Then there is a numer of developers who have a job and are not looking for a new one, but are curious about the possibility of finding work that would fulfill all their personal criteria, be it financial, related to particular technologies or being able to work from home only. Some of such programmers might be considering changing their technology stack and would like to find out what kind of impact it would have on their job market position, given their current experience. To sum up, let’s just say there are two groups: those who are not interested in changing their job, and those who, for whatever reason, are.
2. On the other side of the divide there are recruiters who have no way of knowing which of these groups a person they have directed their offers at belongs to. This is why they choose to present their offers to all, bar none. It’s not unusual to see it as a problem. Developers may be annoyed by the number of offers they receive when they are not interested. Also, recruiters themselves would certainly prefer to have fewer of their enquiries remain unanswered.
3. If, however, a recruiter manages to find an interested developer, the next stage tends to be an interview or some form of screening. This is where the next problem arises, namely the difference between the candidate’s expectations and the company’s potential to fulfill them. Presenting your conditions is one of the most stressful and uncertainty-filled moments for job seekers. Misunderstandings and failure to lay down your prerequisites with sufficient clarity often prove to have adverse effects on one’s attempts at being recruited.

This is the way it looks at the moment, from my perspective.

So this is what the current flow roughly looks like. It is not hard to notice that the situation could be vastly improved by being able to isolate only those programmers who are actually on the lookout for new employment — be it out of real need or sheer curiosity.

Another potential way to streamline the situation would be through enabling developers to present their requirements before the actual recruitment process starts. Thanks to this, programmers would only be contacted by businesses that could meet their criteria. Also, recruiters could isolate a far more precise target group at any given moment. Besides, they would know the candidate’s expectations from the word go.

So now that we know what could improve recruitment let’s think about how the goal can possibly be achieved. Maybe it would suffice to let the developers take initiative? Bearing this in mind and being fascinated by the look and feel of various job boards as well as the lucid structure of notices published there, it occurred to me I could do the same — only with a twist. I thought it might be worth starting a developer board, in other words a place that would not list job offers, but developers looking for them instead. A place where a developer could put up an anonymous notice, delineating their own terms and conditions and presenting their technical profile without details such as employment history or educational background.

Let’s think what this new flow might look like:

1. Programmers looking for a job put up their notices for a few days along with their list of demands and a subjective description of the skills possessed. Thanks to it, a group of programmers ready for new challenges is isolated from the whole.

2. While viewing such notices, recruiters can see right away which individuals can be targeted with an offer of employment.

3. When a candidate with a relevant skill set and reasonable demands is found, the recruiter may decide to pass their contact details to them. Thus, the candidate only sees job offers by companies happy with their skill set and potentially ready to meet their expectations.

4. The developer and the recruiter meet at an interview and are on the same page from the onset as regards each other’s expectations, so they can focus on the crucial issue of verifying the candidate’s skills.

And this is the way I would like it to be.

The idea to change the flow into the one presented above inspired me to create devmountjob.com, which will enable such an approach to be implemented. I have been working on it for quite some time and would like to go live soon. The key concepts I will focus on are:

1. Defining the target group.

Isolating the target group, or the developers searching for work, from the total number of developers on the market. Thanks to this, recruiters will only direct their offers at those actually interested in them.

2. Clarity with regard to conditions from the word go — even before the interview.

Regardless of what your reasons for looking for a job are:

- actual necessity

- market research

- checking whether there are any companies ready to meet your expectations and provide you with your dream job.

Thanks to the suggested approach, both sides are on the same page right from the start. This also improves communication between them further on into the process. Additionally, it eliminates cases of developers being tempted to undersell their talent following an interview that did not go according to plan.

3. Developer anonymity.

Apart from the obvious reason which is wanting to keep your current employer in the dark about being on the lookout for some new prospects, there are countless others. An example of these would be equalizing the ground rules for all involved — you present your skill set and requirements thus creating basis for preliminary assessment. It ensures that those offering a job are not taking into consideration things they shouldn’t be. Thanks to this, the interview is solely based on your merits.

4. No needless networking.

A notice with your offer is only displayed for a set period of time. There is no room for standardised profiles or networking here. You choose to use this tool only when you really need to. Also, recruiters are only capable of addressing those who they can truly help at any given moment. Thanks to this, frustration can be avoided on both sides: developers’ — who do not get bombarded with unwanted offers, and recruiters’ — who do not have to face up to their messages, emails and calls remaining ignored.

5. Transparent offer structure.

As I have mentioned before, I am a fan of job boards, where the structure of an offer is always the same and there is no room for redundant elements. Due to this, offers can easily be listed and filtered according to criteria that are relevant to the situation. I like to be given factual data in a straightforward manner. This is why I would like the developer offers to be standardized and stripped down to basics such as financial expectations or location of your employment. It is also crucial that the candidate’s technical profile be presented in a lucid way.

6. Speeding up the recruitment proces.

Through a clear set of candidate’s demands recruiters can see right from the start whether or not these can be met. Then all they need to decide is whether to accept the conditions and make an offer or to keep on searching for the right person.

I am truly convinced that improving the few aforementioned areas would streamline all recruitment. Why don’t we try something new for a change and make people’s lives easier? Is it not what the whole IT sector is meant to be about?

If I have managed to interest you in my concept I would be really obliged if you should decide to help the article gain some kudos — give it some ”Claps” or share it with others. Would you like to find out how the idea is developing and when it is going live? Leave your email address below and I will let you know as soon as I’m ready. With new year approaching and many people taking resolutions to turn their fortune around, you might just want to check if someone can meet your dream expectations.