Getting a job is one of the hardest things when becoming a developer. Sometimes, you get hit with a Catch 22 of not having enough of the right experience but not being able to get the experience without having the experience.
While there is consistent demand in the industry, résumés seem to go into a deep dark hole known as the submission inbox.
I know because I’ve been on both sides of this mysterious inbox — both as a developer asking for the job and the person making the hiring decision.
These two experiences were during two very distinctive periods in my career. Here is some insider knowledge of what happens inside the hive mind of tech recruitment.
Don’t Bother With Lists
Once upon a time, I was tasked with shifting through 100+ applications in an hour — not because I was being mean but because that was all the time I could spare in addition to all my other work.
A common feature I saw was that applicants always made a list of tech stacks they knew or thought would be relevant in some way for the application. These lists meant nothing to me — nor did they prove anything.
At one point, I began to wonder if applicants were putting them down to bypass some bot shifting through the résumé pile — trying to target the right keywords and densities, a sort of early 2000s black-hat attempt at SEO but with job applications.
The list often starts with the things they do know. Then it proceeds to things they’ve encountered but don’t actually know how to use. Finally, it turns into a massive brainstorm of all the acronyms they can think of in order to fill in the blankness of their real résumé.
The person shifting through rrésumés at lighting speed is not a bot. They’re still very human and are probably looking for someone that’s equally human, too. Lists don’t mean anything in general. They don’t tell us the depth of knowledge or the degree of actual usage or exposure to a technology stack.
What to Do Instead — How Relevant is the Experience?
When recruiters and HR shift through rrésumés, what they’re looking for is relevance. Sometimes that relevance comes in the form of past or side projects. These projects are much more concrete than a giant list of potentially relevant experience that may or may not be real.
The point of looking at relevancy is to see if you have the ability to do the things you say you can do. I’ve sat down with multiple potential candidates only to discover five minutes into the interview that their entire résumé was a lie.
There’s only so much you can lie about when it comes to a tech job. You either know what you’re talking about or you don’t. It’s very hard to fake knowing how to do a bubble sort or tell the difference between OOP and functional programming.
Be real with what you know, and be sure to show it in your résumé with real experiences.
What Kind of Potential Has This Candidate Got?
Not everyone fits into the internal requirements 100% of the time. We know this. We understand this. And we’re also lenient about this.
When we look at the hundreds of developers that come through into the inbox, we quickly make a judgment call on a thing called potential.
Potential is a hard one to define but sits on the soft-skills spectrum. They answer the split-second quick-fire questions we have when looking at a candidate:
- How self-sufficient is this person?
- What kind of learner are they?
- Are they a learner at all?
- What ancillary knowledge do they have?
- What kind of scope does their current workplace have? Are they able to adapt to a scope change?
- How good are their communication skills?
It sounds like a lot to fit onto two pages — but if done correctly, it is possible. The trick is not to make the font-size smaller but to be selective in what you end up putting on your résumé.
A lot of templates have a hobbies section — but if your hobbies don’t actually add value to your overall application, there’s no point putting it in. I once had a candidate spend a quarter of a page talking about their horse riding extracurricular. It was unnecessary. It would have made sense if we were in the business of selling equestrian products, but we weren’t.
What’s the Candidate’s Value Against Cost?
Let’s be honest — the difference between revenue and cost results in the final profit before taxes. An employee is a value-generating cost. Not all developers generate the same level of output and value. Not all developers cost the same. Some generate more for less and vice versa.
Recruiters and HR do their best to gauge what this value against cost is for everyone that makes it through to the next stage of the application process. Sometimes it starts with a technical test; sometimes this value gauge is assessed through a phone or a face-to-face interview. Sometimes the human factor is taken out of the initial assessment process and psychometric tests are used.
The last of this list often occurs when there are too many applications that make it through or for larger organizations that contain many layers of management.
We have only two pages and a cover letter to make this initial value-vs.-cost decision, so make it worth it.
Final Thoughts
There is often a lot of money on the line when it comes to tech recruitment, sometimes up to six-figures kind of levels. Sure, there is the dilemma of requiring experience but not having any, but there’s always a side-stepping solution to every issue.
What we’re looking for is how you go about solving this.
There are those who will sit around and complain about the issue and not do anything in particular about it, and then there are certain candidates who will get creative about how to overcome their roadblocks. They’re the ones that get hired first.
There are a lot of developers in the market. The issue for many recruiters and HR is finding the good ones — so present yourself as one of the good ones and give the reasons to hire you.
