I also try to be active in the local (and not-so-local) development circles and the theme keeps cropping up again; many new and first-time developers are looking to land their first job and kick-off their careers.
Occasionally, more seasoned developers also want to move on and find new jobs or take the next step on their ladder — perhaps to senior positions or development managers.
So, I wanted to help my fellow developers and developers to be on their way and share some things that have helped me on my journey so far:
- Tips and tricks — getting organised and using a process to hunt that job.
- Advice and anecdotes from my own journey.
- Guidance on tech tests — a frustrating, but common part of the development interview process.
- Some developer job hunting myths and trying to dispel them.
This is a bumper blog post, so here's a handy table of contents to help you cut to the chase:
- Step 1: developing a game plan
- Step 2: applying for developer jobs
- Step 3: handling the interview process
- Step 4: dealing with rejection
- Resources and links
Why should you listen to me?
I am not the best developer in the world: I still make mistakes, I still learn and grow and adapt, just like anyone else in our industry. However, I have over 15 years in the industry and I've had a fair few jobs. I interview very well and I've seen my share of great interview processes and horror stories so I can share my experiences and give you some practical advice and opinions on how you can improve your own job hunting game.
I also have a shorter, hot-take article on job hunting in the tech insudtry if you'd like even more info.
Step 1: developing a game plan
Before you start hitting the apply button and throwing CV's at employers like Gambit from X-men, I think it's helpful to take a step back and think about a few things that will absolutely help you when you're in the midst of a handful of interview processes.
Prepare yourself mentally and frame job hunting as a process
Job hunting can be a gruelling, thankless process. Think about it, the odds are not always tipped in your favour. Not only have you got to find a job you like, at a company you like, with people you like doing it with, you have to submit a CV along with other people who all want the job as much as you.
Then, you have to wait for feedback, do interviews (yes, plural), maybe technical tests and hope that you've done enough to get that valuable offer...
This shouldn't be read or thought of as doom and gloom but it's just practical to know this upfront: you are more likely to apply to more jobs than you get offers.
By framing your job hunting journey as a bit of a sales process, it helps to stop those bothersome thoughts about 'not being good enough' or 'being rejected again'. Think of it as a sale: you're selling yourself to the company and, if they're not buying, it's not because you're not good enough. It's about a lot of factors: timing, personalities, culture, technical skills, and so on.
If you can shift your mental approach and thinking around how you tackle job hunting, you'll be able to deal with feedback and rejection much more smoothly and move on to the next opportunity.
Get a process that works for you
People approach job hunting in very different ways. For example, I have a friend who likes to take his time, applying for maybe one or two roles at a time, seeing how they pan out and being careful not to overwhelm himself.
I, on the other hand, I prefer to attack it and apply for multiple roles that pique my interest, handling and tracking everything using Trello. I play the numbers game and treat the job hunting process as a large project, which can be broken down and tackled in small parts — a little like a Sprint board, but for jobs.
How you tackle your own job hunting process is up to you. However, I recommend using a project management tool to track your applications. I use Trello but Asana or Evernote will work. Basically, anything that allows you to mark a job as being at a particular point in the application process.
I've found this hugely valuable because you rarely apply for one job at a time and job applications are very asynchronous things, and information such as people, dates, and tasks can become easily lost in the overwhelming deluge of emails, phone calls, etc.
Approaching your application process in this way helps in a number of ways:
- Track where you are in any one company's journey — initial CV sent, phone interview, tech test, etc.
- Keep a list of key people's names and their roles in the process — recruiters, CTO's, hiring managers, and so on
- Manage interview dates and keep a calendar of what's next
- Add reminders for key dates or feedbacks/responses being due, or jobs you have to complete
- Add in conversation highlights.
An example using Trello
Here's my typical job hunting board on Trello:
I start off with a few columns for the states of applications I've made. Something like this:
- Initial conversation or application submitted
- Phone interview scheduled
- Tech test scheduled
- In person interview scheduled
- Blackholed applications (e.g. roles that have not replied or responded after 7, 14, 20 days)
- Application unsuccessful
- Application successful
Within here, I'll add cards for each role, each containing some important information about who the role is with, people I've spoken to, my feelings about the job, and any key dates of note.
As I complete a step, I'll move the card along to the next logical column, depending on how the company in question handles the application.
Step 2: applying for developer jobs
You've done the prep, you're as ready as you'll ever be, let's get applying for jobs!
Research some companies you'd like to work for
It might sound like a obvious move, but the best place to start is to research some of the companies you would love to work for. This might be local agencies or development houses, it might be huge, global corporations. Whatever your reasons or motivations, be sure to note down the why of why you'd like to work there.
Is it the culture, the people, the work you'll be doing, something else?
By getting a good handle on the qualities of places you'd like to work, it'll help you narrow down where exactly to spend your time applying for roles and which roles to pass on.
A scatter gun approach to job applications is not a good idea. Keep your job search wide and your job applications narrow!
Build a network
One thing that has absolutely, 100% helped me when I've been looking for roles is my network. Your contact network might involve a few different facets — I know mine does! — but leverage what you can and be honest about what you need from it.
I find LinkedIn a great resource to connect with a range of different people who can help each other out:
- Recruiters and internal hiring managers
- Colleagues (current and previous)
- Like-minded people in the same industry
This is a slow process that involves getting regularly involved in conversations and sharing helpful content. This helps people to build up a picture of you and your skills, which, in turn, pays dividends when you need to request a shout out or are looking for a job, for example.
But remember to keep things even: don't take take take from your network and never put anything back. Be sure to cultivate good relationships and reciprocate where you can, offering your own advice and support to those who need your help.
Writing a killer CV (resume)
Of course, any job usually starts with a CV being submitted for the role. However, not all CV's are created equal. It's easy to put too much information or not enough in there and get passed over for jobs, just because it didn't capture the reader's attention.
A CV is your sales tool. It needs to highlight you and your skills (both hard and soft) and essentially deliver one thing: it should make the person reading it want to see you in person.
A CV doesn't have to have everything you've done on there, nor do you have to have 100 years of experience at 'XYZ'. Give people something interesting and let them invite you in for more detail
I would recommend using the press release inverted pyramid technique when it comes to writing an interesting CV.
The trick here is to put the important/newsworthy information right up front — think about your accomplishments, achievements, interesting facts and figures.
From there, include key summaries of your previous roles or projects, depending on what you've done so far — for example, those seeking their first junior role will likely have more project experience from their learning journey than they do work experience. Finally, pop in any other relevant information.
Example's are always nice, so here's mine:
There is always room for improvement, and my CV is no exception so it is by no means a silver bullet. However, I've worked hard to iterate on it, using feedback and helpful comments to find a balance and the current version has certainly helped me get to the interview stage more times then not.
Be honest, be genuine, but don't be afraid to shout about your achievements. Make yourself relevant to the company you're applying to.
Portfolio or not?
A common topic I get asked about is portfolios: should you have one, what should it look like, what should be in there, etc.?
My advice is always this...
Anything that helps you get an edge over the competition is never a bad thing!
You don't have to have an all-singing, all-dancing shiny beacon of development portfolio, but increasingly, people doing the hiring are turning to examples to back up applicants' discussions and to gauge skill levels and coding approaches.
In my experience, the best companies tend to lean towards person-fit rather than out and out level of skill, so having a massive portfolio of work that you've been involved in isn't the be-all-and-end-all (or, entirely required).
However, it's never been easier to build a digital footprint to highlight your work and anything that can give you a little extra when it comes to interviewing for a role can only help.
There are lots of ways to build up a portfolio as you go, without having to panic and build one as a large, single-effort project:
- Contributing to open source projects
- Building examples of an aspect of code (e.g. arrays) in a platform such as CodePen
- Creating GitHub repos for projects you've built during your learning
- Building your own website using something like GatsbyJS with a blog for people to follow your progress and mental approach to coding
Getting a foot in the door (bonus round!)
If you're struggling to get responses back from companies you've applied to or feel that you don't have enough experience then fear not, there are some other ways to get noticed.
From people I've spoken to about their successes with this, there are some great approaches to getting your foot in the door with development jobs:
- Reach out to hiring managers and decision makers in the company. Be honest about your intentions and experience. See if there are any work-experience options available, or if they know when they're hiring. Build a relationship and help them remember you when they're next taking on staff.
- Look at internships. In the UK, it's illegal for these to be unpaid, so they are a good way to get experience and learn, whilst getting paid.
- Explore voluntary options. My first IT role was in a school where I volunteered as a helpdesk agent, dealing with support queries. I volunteered about 4 hours a week to gain some valuable real-world experience. It paid off in the end as my next job was won off the back of this similar role (and the willingness I showed in giving up my time for free!).
- Talk to recruiters Recruiters can be a necessary evil, but I've been hired for most of my roles through them. Good, experienced recruiters are great sales people that work in both directions: selling the job on offer to you, whilst selling you to their clients as a good fit for the role. You can have honest conversations with them and they will sure as hell work their hardest on your behalf if they think you're a good fit for the role.
Step 3: handling the interview process
You've got a game plan, you've pruned and preened the CV, and you've applied and got an interview, awesome! Now, what?
Don't panic, there's more advice coming!
In person interviews
Ahh the traditional person to person interview, a classic! You'll get nervous, but that's OK — believe it or not, so are the interviewers.
The best thing to do is actually relax. I know, I know, easier said than done, but by devoting some time to leisure activities or spending time with family and friends, anything to get your mind off the actual interview, will help you focus and not over-think or stress out about it.
During the interview, there are a few things that might help you out:
- Breathe...seriously, you'll feel better after a few deep breaths.
- Show interest and ask questions! Contrary to popular belief, you don't have to memorise the company's history and names of all the staff, but by taking an interest in what they tell you and asking questions about what you'll be doing, aspects of the company, who you'll be working with, can really help you stand out in the interviewers' minds.
- Be honest. If you don't know something, say so. No one's trying to catch you out or trip you up and, believe it or not, most companies would value an honest 'I don't know' above someone trying to bluff their way out of a question. If they are trying to trip you up then you don't want to work their anyway!
If you're applying for technical, development roles, you're more than likely to have a tech test. I dislike them very much. In fact, I wrote an entire article about the relevance of tech tests in today's hiring landscape.
But you can't just spit your dummy out and not do them...most of the time. I think there is a fair amount of tolerance that can be given, however frustrating. But you have to be realistic with yourself about how much time you have available and are willing to give to an application that sends you a technical test.
For example, I've had smaller tests such as questions and answers, a project brief to write, or even a small project (i.e. <2 hours work) which is OK.
However, where I draw the line is with large project-based tests that are 4+ hours work. Personally, I feel that asking someone to do over half a day of unpaid work just to access the next level of an interview process is unfair. I bet the company doing the hiring wouldn't spend that much on a client's say so, why should you?
From a purely practical point of view, if you've applied for a number of roles, and each of them has a 4-5 hours project, then you'll need far more time than you probably have to complete them and that's not mentally healthy.
Furthermore, the intrinsic value of a technical test is minimal to the hiring company as they almost always end up as contrived examples, detached from the real world where you'll be working in a multi-disciplined team.
That said, if you do take part in them, then don't overthink your solution. Get it working first and foremost. Add the bells and shiny whistles on top (if you have time) and double check your working.
Step 4: dealing with rejection
You're going to face rejection. That's just a fact. You might be having an off day. You might not be feeling it. Hell, you might just not be as good a fit as the other candidates.
But if you take nothing else away from this article, then remember this:
A rejection from a job application is not a measure of your value, your worth. It is nothing more than being the wrong 'fit'. Right now, for whatever reason, you're not a good fit for the role. Frame the rejection like this and move on.
I can't stress how much this helped me.
Ask for advice and feedback from the company on the back of a rejection. If it's something you can improve and work on then that gives you a positive direction. If it's a simple case of 'you were good, but they were better' then there's nothing more you could have done and that's just how life is sometimes.
Focus your energy into the next application and don't look back!
Resources and helpful links
I genuinely hope you found something useful to take away with you from the article. If you'd like some more information and helpful advice, then I have a few resources for you below that you may find useful: