A couple of weeks ago, I decided to quit my job and take a few (most probably 3) months of sabbatical time — I'm about to become the dad of my firstborn soon enough, and I want to make the most of it, so I talked with my wife, and we both felt it was a great idea.

Still, since I know how long some recruitment processes can take, I casually looked for the next challenge once I'm back in the game.

I've sent some applications and had some interviews already, which essentially led me to write this post to share my perspective (and experience) about the current state of the developer job market.

First and foremost, the response rate

Between August and September, I applied to about 40 senior developer positions (most of them Fullstack and Frontend Developer opportunities). I was pretty selective, only applying to opportunities where I felt quite confident on a technical level — meaning where I had significant professional experience with the desired/used tech stack (Vue.js and Laravel/Ruby on Rails/Node.js).

Out of those 40 applications, I got three screening interviews (7.5%), and about ten didn't say/reply anything (25%). From the rest (67.5%), I got standard and automatic responses with no feedback at all, with some generic text like "Unfortunately, we've decided to move forward with another candidate. Please keep following our careers page, yada yada." (yet, lots of them still have the role available today).

These are all rough and rounded numbers but trust me, they're pretty close to reality.

Out of those three screening interviews, from the first one, I was immediately rejected once I told the recruiter that I was about to become a dad (and what I valued the most was work-life balance); the other two invited me to take a small code challenge before the technical interview.

Which takes me to my next section.

Code challenges: one-line problem statements with exhaustive reviews and quite demanding code expectations for "small" exercises

So, I was invited to do a quick code challenge before the technical interview for both of these recruitment processes. I received a really short problem statement (one or two lines of text) for each one.

Despite being different problems, the outcome was the same: I solved the problem (as I understood it, given the lack of depth of the problem statement) and was confident enough that, together with a proper conversation, I would be able to not only explain some of the decisions I made, but also share my perspective on what could be improved in a real context, and finally talk about other types of contributions the company can expect from my side (which in my case go way beyond the code that I write)

Yet, I was confronted with an exhaustive review and pretty high code expectations for something that should have taken me 30 minutes (for the first one) and about 2 hours (for the second one). I was also told that, unfortunately, they would no longer schedule the technical interview nor give me the chance to talk about my exercise — this is where I started to feel quite triggered.

The unfairness of the game

I'm well aware that the market is overly saturated, and some positions can quickly get 1000 applications in a matter of days. I understand that companies cannot interview 1000 people for one position; thus, there is a need to select only a slice of the candidates for the screening interview, and so on.

What I don't understand is the unfairness and discrepancy of effort from both sides in these recruitment processes. Candidates need to be on their A-game in everything they do every step of the way:

• They have to carefully write their resumes and cover letters and highlight their skills and specific keywords to have a slight chance against the AI-based tools that companies use to filter out applications.
  • Yet if candidates use AI tools to generate these artifacts, they're perceived as lazy for not making the effort to customize their application based on the company/role manually.
• They have to precisely match all the years of experience in all the languages/frameworks/tools requested on the job offer to have a slight chance of being selected for a 15-minute conversation with a recruiter.
  • Yet it doesn't matter if they have solved similar (or even more complex) problems with other languages/frameworks/tools — meaning, they could easily pick up the desired language/framework/tool in one or two weeks of reading through the documentation if needed.
• They have to expand the poorly described problem statements companies provide for their code challenges and imagine what is not stated but is expected for a "small" exercise (that can take 30 minutes, 2 hours, 4 hours, 8 hours, or whatever).
  • Yet if they fail to deliver what the company is expecting (which often goes way beyond what is requested), they don't even have a chance to talk to fellow engineers about things like past engineering challenges they've solved and are proud of how they usually prioritize their work negotiate things with other stakeholders, etc.

Essentially, they have to be perfect.
There is no room for flaws or uniqueness — it feels impossible for companies nowadays to hire a great human with excellent interpersonal skills and a fantastic player. Someone who, with a bit of help and guidance, could become the best developer and teammate the company could ever have.

Yet, companies are far from being perfect.

The best recruitment processes (from my perspective/experience)

I understand why FAANG and Fortune 500 companies must be selective and have 7 or 8 steps for each recruitment process. However, I challenge the assumption that this needs to happen for every single tech company that is hiring.

Most companies don't need that 1% of the very best talent available. Most companies can build incredible products and businesses with amazing human beings and great professionals — just that.

Since I don't want this post to be just me ranting about companies and their recruitment processes, allow me to share what I believe is the best recruitment process I've experienced and used (both from a candidate perspective and to hire folks for my team as well):

• 1st interview with a recruiter/HR representative
  • Here, the goal is to have the company and the candidate get to know each other. Each one talks about their path and trajectory, as well as their ambitions and values, to assess if there's a potential fit for both sides
• 2nd interview (technical) with the Lead Developer/Engineer (or someone who can assess the technical expertise of the candidate for the desired position).
  • On this one, I usually like to give the candidate a chance to talk about a project they're proud of and maybe ask them to do a code walkthrough, explaining some of the challenges they had to overcome and how they did it.
  • If they don't have such projects, I always have a prepared list of questions (usually language/framework/tool agnostic) to help me understand how the candidate thinks and operates, what kind of challenges the candidate has tackled so far, what kind of learnings the candidate got from them, etc.
  • My goal as the interviewer is always to assess whether the candidate has the traits I'm looking for from a soft-skills perspective. Because I find it fairly easy to figure out if someone is smart/experienced enough (and I know that smart and experienced people can pick up any language/framework-specific knowledge with the proper time and guidance), I usually try to invest more time in evaluating the candidate's soft skills and personality traits.
• 3rd and final interview with the decision-maker (can the founder, the CTO, the team lead, etc.)
  • This is where the offer is usually negotiated, and it also allows the decision-maker to get to know the candidate (and the other way around).
  • This is also where more in-depth questions about the team/company can and should be asked (and discussed), such as how much runway there is, what the goals for the quarter/year are, what contributions are expected from the candidate and how they impact the overall goals, etc.

And that's essentially it!
If you combine a lean process like this with a probation period that is clearly communicated and well-aligned for everyone involved, hiring doesn't have to be that big of a deal — mostly because everyone involved knows that the first few weeks are to assess (and not through an unfair and quite limited-in-time recruitment process) whether the company, the role, and the person are all happy with the agreement, the expectations, and the contributions.