So you want to be a software engineer

Probably the most frustrating part of my job is recruitment. It always used to fill me with a sense of possibility and expectation; we'd find a developer by scouring the talent pool, convince them that we were the right place for them to grow and flourish, and let them loose in an environment that allows them to do so. Over the past 10 years or so, it's become apparent that it's not that simple, at all. Far from being overwhelmed with tens or hundreds of applications for a reasonably well paid job in a rock-solid industry with good benefits, a recent advert we put out led to a grand total of 2 applicants, neither of whom met some basic requirements for the role.

We've changed tack significantly over that period of time. We used to advertise for the finished article, looking for someone who could hit the ground running, but that's just not very realistic in practice. We're lucky in that in the education industry, there's no shortage of recent graduates, but you have to create the right environment to allow them to adapt to the industry; it's not simple to translate theory from a University course into usable software.

The most successful recruitment we've been able to do over the past 5 years has almost exclusively been people taking their first software engineering role. Of these, a couple of people have come from a sister team in the department and either self-taught themselves software development or undertaken a University course to transition; a couple have had some relationship with my team (either formally or informally) during their studies and have then accepted a full time role following a paid internship or similar; a couple have completed undergraduate or postgraduate degrees at the University and wanted to continue to contribute in an education environment so found the role ideal.

The first three months of a developer's time in my team looks completely the same whether they're an experienced software engineer or a self-taught first-timer - the existing experience of the architecture, software eco-system or design isn't there. We put mentoring in place and an open environment to bring people up to speed, but it's tough for absolutely everyone - nobody would be able to come in and independently be able to contribute code to our CMS or other applications on their first day or in their first week. An experienced developer would probably be a little more confident, have experience of what it's like to have code reviews, stand-ups, etc. but their first few steps look remarkably similar whether you have 15 years' experience or 15 days.

Sure, at a senior level, things look slightly different - having a well-practiced discipline for designing and redesigning systems collaboratively is something that you only really pick up with experience; but we'd primarily look to promote talent internally for senior roles anyway.

So you want to be a software engineer? We recently had a 16-year old work experience student in our team for a week, and he asked me this question at the end of the week. What I told him could be broken down into a bulleted list as so:

• If you want to do a University degree, do something you actually enjoy. It's useful to have some theoretical Computer Science knowledge as you're bound to run into complexity problems or design where knowing about how computers work is going to be key, but don't run yourself into the ground doing a Computer Science and Maths joint hours degree if that's not your cup of tea.
• Learn a few different programming languages or frameworks, at least to the point where you can identify different patterns in code or different approaches to framework design. Try some Ruby on Rails, Python, node.js. We do a lot with Scala and Play! Framework, there are some excellent resources out there if you want to learn more about that.
• Understand how the web works. When you load a web page, what's happening from a plain-text point of view? Can you load a web page with just telnet? If not, you should learn how to and why each piece of the puzzle works like it does. HTTP is a wonderfully simple protocol, and it's frustrating to meet prospective developers who haven't a clue how it works.
• Build a pet project that you actually care about. This is a biggie. You might think you've gained enough experience through building software as part of a University module, or as a favour for a family member, but do you care about it? It's important to have something that you curate and grow yourself, that you're invested in improving all the time, not just to get marks or make someone else happy - if you've got a page that loads slowly on something you care about, you're going to read around it and try and work out why it's slow - and it's much easier to learn about database indexes and optimising asset loads when you're getting actual value out of what you've learnt.

When I'm interviewing for a role, I'm asking competency-based questions to see whether the candidate is appropriate, but I'm mostly looking at their attitude to learn and how well they're able to work with others.