What The Recruitment Process Looks Like

From the outside a recruitment process is fairly opaque. As someone applying for their first developer role it can be easy to get lost with who’s who. Let’s go through the high level journey of recruitment for a role.

The job interview is often only one small part of the hiring process. Photo by Christina Morillo on Pexels.com

Remember, the process will always be slightly different for each company and each person but the common building blocks are often there.

  • Company identifies they need an additional person and speaks with a recruitment agency (sometimes done by a specialist team withint the company) to post an advert and job description.
  • The applicant (you) see this advert and decide to apply.
  • You will most likely be asked to provide a CV and potentially a cover letter.
  • The recruiter will then shortlist a number of candidates, filtering out the people who are clearly unsuitable and share them with the hiring manager. They may do this by speaking with the applicants themselves before forwarding them on.
  • The hiring manager will then often select a subset of candidates to hold a telephone interview with, these are usually around 30 minutes long.
  • A small number of people are then invited in for a face to face interview (obviously in the current climate this may be done slightly differently).
  • The hiring manager then assesses each candidate and decides which, if any, would be suitble for the role.

Ok, so let’s assume you’re the selected candidate. What happens next?

  • The recruiter will most likely call you either way to get your impression on how the interview went. They will most likely update you on whether they’ve heard anything on whether the company intends to make an offer. Bear in mind that a hiring manager may have many interviews for a single role and will often wait until finishing all interviews before offering the role.
  • If you are selected then the recruiter will often give you a verbal offer, or let you know that the company intends to make you an offer. Nothing is binding at this stage but it’s often wise to give an honest view of whether you would accept or not. It would be impolite for you to let a company go through the efforts of getting a contract out to you if you have no intention of accepting.
  • The recruiter will most often want to discuss start dates with you. This is great news, however if you are in an existing role you shouldn’t hand in your notice until until you’ve read the contract from the new company. It’s safe to assume you’ll be able to start 2 weeks plus any notice period you currently have, but these can always be adjusted once you’ve agreed your last day.
  • You will be issued with a contract of employment which you will be asked to sign and return.

So there you have it, the entire process! I’m going to break these various steps down over the upcoming weeks but there are a few points I want to highlight now.

It’s a long journey from advert to offer! Photo by fauxels on Pexels.com

Sometimes, especially if a company is hiring multiple people in the same role they may run an Assessment Centre rather than going through the entiring process for each candidate. These are nothing to be afraid of, and can be a lot of fun. But it’s often very daunting to meet (and be expected to work with) people who are competing against you for a small number of roles.

It’s important that you’re assessing the company as much as they are judging you. Hopefully you’re going to be spending several years of your life at this organisation and working with the hiring manager. If you feel uneasy around them or don’t think you would fit in there then there’s nothing wrong with turning down a job offer. It’s disappointing for the hiring manager to lose someone they feel would be a good person for a role but if your aspirations are elsewhere you should listen to that.

Finally, a LOT of candidates apply for roles. Especially during difficult times (like we’re expecting in 2021). Look for ways to stand out. I’m not talking about bringing cake to the interview or wearing bright colours to the interview but think about what differentiates you and makes you unique. Make connections with the recruiter and hiring manager by asking questions and always show your interest.

I intend to cover recruitment in a lot more detail over the next few weeks but hopefully there’s enough here to get you started.

As always if there are any questions please get in touch and don’t forget to subscribe to the blog and follow me on Twitter.

What Makes Me Hire A Developer?

I’m going into a new round of interviewing developers for my team so I’ve been giving a lot of thought to what I look for when I’m interviewing people to work with.

Joel Spolsky says that you need to look for two things, brains and the ability to get things done. His reasoning is that developers who are smart but never finish jobs belong in never ending research projects, developers who get things done but aren’t smart end up causing you more work and if your candidate has neither then you should run a mile!

While I like his logic I have a few other criteria.

Joel doesn’t mention the candidate’s passion, their ability to learn, to form relationships with their team, or to empathise with the customer. In my eyes a developer who doesn’t have these qualities will negatively impact your team’s dynamic and product just as much as someone who produces bugs for a living.

So why an ability to learn? I hope this one fairly obvious. In our fast paced development world a developer’s ability to learn new technologies, absorb ideas and keep up with current trends is (in my opinion) more valuable than whether they have an in depth understanding of bitwise operators or lambda expressions. I’m not saying don’t ask about the technical side, but make sure your candidate can learn your code, your technologies and whatever comes along next!

Relationships? How many times have you worked alongside someone who can’t work in a team? They’re territorial, overly sensitive and horde knowledge with the misguided belief it makes them invulnerable. Look for people who enjoy the camaraderie and take time to teach and learn from their colleagues.

Empathy for the customer? This is, in my view one of the most important. Can your candidate put themselves in the shoes of your clients? Can they envisage how a bad release will impact your reputation? Do they understand the consequences to people’s working day when your code doesn’t work as expected? Find someone who understands the frustrations of bad software and poor customer service and you’ll find someone who will strive to prevent it!

Passion? Simply put I want a developer who wants to develop software! I don’t mean you have to spend every evening and weekend writing code or contributing to open source projects but demonstrate to me that you enjoy what you do. Tell me about what you’re working on, explain that bug fix you’re really proud of but please prove to me that you’re there’s something about the job you actually enjoy (other than just the £££s).

So there you have it, a few of the qualities I want my developer candidates to demonstrate for me. What do you look for when you’re interviewing? What personality traits do you try to show when you’re being interviewed?

Why Technical Tests are both a Wonderful and Terrible Idea

When hiring for a new developer its extremely common to ask them to demonstrate their technical ability. Often this is a practical test to be done at home and then sent into the hiring manager.

It’s a nice idea, you get to see the candidate’s unhurried work, get a feel for their skills and potentially ask about them in a face to face interview later. It’s far harder for a bad developer to write good code than it is for them to learn a few answers about relational databases or solid principles.

However, I believe this approach is flawed!

To explain why I want to describe the recent experience of a friend of mine, an outstanding developer who recently applied for a development role. The technical test was presented to him and he completed it, he’d had a rather manic week and so determined not to miss his deadline so he worked late I tot he night. He confessed to me later that he probably spent somewhere between ten and twelve hours on that piece of work!

What happened?

The company rejected him with a series of bullet points over design choices without ever giving him the chance to explain why he’d made those decisions.

So let me ask you this, do you think friend is ever going to waste his time with one of their roles in the future? Do you think I, knowing his experience would apply for one of their jobs? What about the rest of our friendship group?

My point is this – any hiring manager will tell you how scarce good development resource is. By demanding eight, ten, maybe even twelve hours of our candidates’ time and then throwing it away, that’s (in my view) arrogance.

What’s more it doesn’t actually tell you very much! Sat at home what’s to stop someone googling the question, posting something on Stack Overflow, or asking a friend to complete the test for them? How do you know that the candidate’s work is their own?

So what do I recommend instead?

I’m hoping to start recruiting over the next week months and I intend to send code review tasks out to my candidates. Why?

  • Asking someone to review your code gives them a chance to suggest improvements and identify where you’ve not used best practices
  • Code reviews ask candidates to explain and articulate their views, something a straightforward programming challenge doesn’t
  • You still get the same feel of a candidate’s focus (do they focus on code clarity, performance or UI aspects?)
  • You are demanding far less of a candidate’s time and therefore aren’t putting off people applying for the role

Will my approach work? I don’t know, we’ll find out! What are your experiences with practical coding challenges? Do they work?

The Importance of your Local Development Community

I recently saw a post on LinkedIn, I’m fairly sure it was an advert for in house training but the message rang true. One manager turned to the other and said “If we train our developers they’ll get better and leave!” To which the other manager replied “But worse, if we don’t then they might stay!”

One of the most common reasons I hear from departing team members is boredom, that they want to go somewhere else and learn new things, use new technologies, and learn from other people. I myself have preached to friends on many an occasion that you learn more in your first few months at a new job than all the time afterwards combined.

You want the most eager, hungry, and interested developers on your team. You want to be able to retain them by introducing them to new ideas. It’s also your responsibility to keep your long serving members of staff from stagmenting and falling into a development rut.

The answer is often closer than you may think!

Local groups of developers are not hard to come by. I’m based in Leeds and to my knowledge we have Agile Yorkshire, Leeds Sharp, Leeds Code Dojo, and Leeds DevOps. Groups of people who meet regularly to discuss ideas, listen to speakers who bring new and exciting topics to the table. By visiting these groups I’ve been introduced to AngularJS, Microsoft Cognative Services, F#, .NET Core, and many many more…

By encouraging your developers to attend these events you motivate them to go out and find new ideas and technologies. Far better for them to have a night out, come back full of new knowledge than decide they’re fed up of using the same technologies over and over.

So how can you encourage participation in these events? Why not arrange to go as a group? Encourage someone to speak and bring the team along to support them. Plan a team night meal afterwards or ask someone to bring ideas back to your own internal training. Who knows, you may even bump into your next hire while you’re there!