Can We Make The Software Engineer Hiring Process Better?

Candidates complain about broken interview processes, companies complain about not being able to find talent...

First, this is not going to be another post on how technical interviews and whiteboard questions are awful. That topics been discussed plenty of times by everyone, including me. The primary reason it's still used is a combination of fear and not having a proven model for something better.

Second, even if you have an interview process that is reliable, it likely is still too time consuming to perform for every applicant. I often have received 100+ applications for a single engineering position in the past. That was before the tech layoff trend took off. Even if you can get the interview process down to an hour, that's 100 hours plus overhead (e.g. resume review, scheduling, etc). Assuming you have a solid phone screen that's 20 minutes, that's still 33 hours. 33 hours for a single position is untenable for a small team.

Sourcing and filtering applicants is a much larger problem than conducting the technical interviews. At the point that an interview is being conducted, several things have been established: background experience of the candidate, the candidate is interested in the job, candidate skillset vs needs, etc. At the point of sourcing, nothing has really been established.

Job descriptions tend to do a poor job of describing what a position actually entails. They are both littered with keywords to get listed under more search results AND vague in descriptions so as not to discourage anyone from applying. Unless mandated by a state government, "competitive salary" is also completely meaningless. No one is going to say they underpay their staff, even if they do.

Resumes are also completely unreliable. This is not because everyone lies, but because a large enough number of people do and it is hard to tell the difference between a resume from someone who exaggerated their skills versus one where someone was honest. I've lost count of how many times I've asked candidates questions about a specific technology listed in their resume and the response was along the lines of "oh that was another team actually doing the work for that." I once even saw a candidate get angry and say we couldn't ask them about something even though they stated they worked on it explicitly on their resume. The only reliable filter I have is the red flag of anyone listing "on time and on budget" on their resume, but there aren't too many people who do that.

There is a solution that matches candidates to positions fairly well, but is incredibly difficult to scale.

There have been a few times where I was in a position to build a team from scratch. It's usually a time consuming process with 2-3 months spent per position. Once, I managed to hire 3 engineers for a new team in the span of a single month. All of them were the best you could ask for. It just so happened that I had worked with each of them before. I already knew what kind of work they produced and they knew that they could trust me to be honest about the role.

There was another time that I was laid off and received a job offer within 4 days (and that's only because I didn't tell anyone until the 4th day). No amount of engineering or leadership talent can get you a job in 4 days. That can only happen if you've previously worked with the people hiring.

The solution to hiring problems is networking. Unfortunately, that solution has a significant number of caveats.

The first is that there is a big difference between "networking" that typically means business networking and building type of trust engineers have with each other after working on the same project (e.g. dealing with the other's code). The former can happen at a variety of events or conferences. People think the latter can also happen at events, but it rarely does.

That leads to the second problem: if an engineer's professional network is built by working with others, then those who work at smaller companies are going to be disadvantaged compared to those working at larger companies. I've always enjoyed working at companies with 10-20 people, but my network was mostly built at companies with 100-300 people.

Third, just because engineers have worked with someone does not mean they actually liked working with them or would recommend them. Even if they did like working with someone, that person may not be interested in switching jobs. Or a job seeker may know plenty of engineers who enjoyed working with them, but none of the companies those engineers are at have open positions. The pool of jobs and candidates in your average engineer's professional network is very limited.

There are professional social network platforms like LinkedIn where you would think they would aid in helping people expand on their network. The problem is that these platforms tend to optimize for engagement, not actual results. One is easy to measure since you just need to look at the analytics collected automatically. The latter is only possible by having a real discussion (or several) with everyone on the platform, which would be an untenable cost.

An example of this problem is LinkedIn endorsements. I've connected with people and without even a single real time conversation, they've endorsed me for over a dozen skills. People who aren't software engineers have endorsed me for things like Java at points in my career where it had been years since I even touched Java. It is a feature designed to increase engagement through recprocity without actually providing any credibility.

This is the part where I'd love to say "I figured it out! Here's the magic solution." Unfortunately, I can't say that with a straight face.

I did attempt an experiment to solve this problem. The idea was to create small groups (<10 people) where one engineer would present a project they were working on and the problems they were encountering. The rest of the group would then brainstorm possible solutions, much like the type of meeting engineering teams would have internally. It creates an event that has more interaction than going to a talk and facilitates a more technical conversation than a networking event. The idea was that if people were in a group with the same people multiple times, they would build the type of trust engineers build when working together.

Trying to facilitate these groups for about a year made me realize all the problems with the idea. The first is that most engineers can not really talk about the proprietary work they are doing in a public forum with people they've never met (even if that forum is small). That creates a reliance on engineers working on something on the side. Given how many engineers are overworked by poor management, most don't have the time or energy to work on anything outside of work. On top of the social anxiety from presenting your work, I had to struggle quite a bit to get presenters.

Building a professional network is also like saving for retirement. You may "know" that it is beneficial for you long term, but short term needs often take precedence. This isn't a criticism of people mind you. Overworked engineers are going to want to spend their free time relaxing. Mental health is an important short term need that also benefits a person long term (just like paying rent is more important than saving for retirement). This made it difficult to get folks to attend on a regular basis, which is required if they were going to build the same level of trust with each other as engineers on the same team do.

I think the idea still has merit. The issue is likely my implementation. The activity needs to actually be fun and relaxing. I've had fun technical discussions before, but they've all been spontaneous rather than organized. I tried numerous formats, but could never really make the group discussions fun events to look forward to rather than chores. If you have any ideas on this, I'd love to talk about them!