A couple of years ago I was asked to give a talk to programming undergraduates at Kings College, London. I wrote up the session as a blog post and added it to my personal website, where it has received thousands of hits since (one or two hits).
Reading it back this week I was pleasantly surprised how relevant and useful it still is, and as we are currently hiring engineers at the start of their career it is worth resharing here.
Getting that first job
Whilst I can still remember the interview for my first job, I have greater insight these days from interviewing developers, and I have personally recruited, managed and mentored a number of junior engineers at the beginning of their careers. The next sections talk about our hiring process at OpenTable and within this framework here’s how you’d get us to give you a job.
The CV
The CV is not as crucial as you might think. Get the basics right – no typos and a neat layout – but don’t cram it full of everything you’ve ever done, just enough to whet our appetite. A single page is usually best (no more than two).
The most important thing for a job as a developer is to show that you love writing code. Nothing conveys this passion better than sites/plugins/projects/online courses that you have worked on, particularly outside of your employment. Even better, provide links to repositories, websites, blogs or Q&A sites to show your work and genuine interest.
Dare I say it, but your exams results do not really matter to us. Passion, backed up with examples of work will grab our attention, with that hard-earned first or 2:1 counting only as a tie-breaker.
The code test
If we like your CV we’ll ring you for a quick chat, and then ask you to complete a test - either at our office or in your own time. The coding test will vary from role-to-role but will need skills that will be required in the job. If you can’t do the test at all then this isn’t the right role for you, but if you can do part of it then give it a go as it will give us things to talk about in the next stage of the interview.
The face-to-face interview
If there’s enough potential in your test we’ll invite you for an interview. It is daunting, but we like to talk with you for two to three hours to make sure you’re right for the role and that the role is right for you.
The first half hour will be a code review of your test in which we’ll get you to explain how you completed the exercise and we’ll pair with you to refactor or modify the test’s functionality. We’ll be impressed at this stage if you’ve looked again at your code before the interview and can confidently justify your programming decisions. Even if you couldn’t do half the things required in the test, you stand a good chance if you’re knowledgeable about the sections you did complete.
For the next 30-60 minutes we’ll conduct a technical interview. You’ll be interviewed by people whose skills overlap with yours and we’re looking for both a general programming understanding and a couple of subjects in which you can speak more deeply. If you don’t think you’re going to be asked about your favourite subjects try and drop them into the conversation. “Do you work with xxx because I’m really interested in that?” will grab our attention and prompt us to ask more.
The next 40-60 minutes will be a "cultural" interview in which we want to get to know you as a person, how you like to develop code and your understanding of the software development lifecycle. Even if you’ve never written code professionally try and convey passion and a genuine interest and you’ll impress us. A sense of humour is always welcome.
Finally we’ll ask you to spend some time with the head of engineering in London. This is hopefully the most relaxed time in the process. If you’re good enough to make us want to meet you you’ll definitely have other companies knocking on your door so we’ll try and convince you that OpenTable is a great place to work and assess whether it is the right place for you. We encourage candidate questions throughout the day but this is the best time to have a genuine chat.
The first year or two in the job
Congratulations, you’ve got your first job. What now? Now, you simply carry on learning (and get paid for it).
You won’t know a fraction of what the job involves, but in software development no one can know everything. Not even search engines know it all and this is where you will spend a lot of your time. Vastly experienced developers still have to google the answers to things, but when you start out you’ll be doing this a great deal – and that’s absolutely fine.
If you have the drive to solve problems and know how to look up answers then you’re in the right career. Never be embarrassed to teach yourself as you go. Trial and error will be your default technique and you’ll probably repeat the same mistakes more than once. Software development is constantly changing but if you’re always learning then you’ll be successful.
If you want to try something new in your job don’t ask permission, just give it a go. Unless it could affect the company’s bottom line, most mistakes are forgivable and you’ll learn your lessons. Just don’t be reckless.
Get active in the developer community. There are hundreds of free and inexpensive meet-ups and conferences. Be talkative with the people you meet – you’ll learn from them and get to hear about projects or jobs that could be perfect for you. Don’t be self-conscious, and ask as many questions as you can. You’ll find this much easier earlier in your career before you’re too embarrassed because you feel you should already know.
Things to consider as you progress
You’ll hopefully love the company you work for, but only stay with them if you’re genuinely still learning. Job hunting is hard and it’s easy to pretend your current job is just fine – especially if you like your colleagues – but be honest with yourself about your situation to keep progressing.
Don’t feel like you have to go into management. I'm a manager now and describe my job as "talking to people" – but if this isn’t for you then find a company that nurtures individual contributors. You can still become very senior in the industry as a Principal Engineer or Architect, with little or no people management required.
Finally do your best to build a good relationship with your manager. This starts with being reliable and prepared, but take it to the next level by understanding what are your manager’s biggest problems and frustrations, and do what you can to solve them. If you struggle to communicate with your manager then identify someone with whom they have a good relationship, analyse why and emulate this. Try to understand the business strategy and identify opportunities and threats.
A proactive, reliable employee who understands their manager will get the interesting projects and rapid career progression.
In summary
- Start building things straightaway
- Be passionate in your interview
- Embrace trial and error, don’t be afraid to make mistakes
- Get involved in the developer community
- Don’t stay too long in a job in which you’re not learning
- Get on the same wavelength as your manager for good, long-term prospects