Getting Hired As A Developer – Part 1

I’ve done technical hiring for some years, hundreds of CVs and interviews. There is no magic in getting hired. There are techniques, some preperation and then hiring is a number game – given that your skills are in any demand. But some people – especially fresh from university, do not know some very basic things. I try to clear some of those up.

1. Where to Work

It is of utmost importance that you know what you want.

IT is a very big field. You need to know what you want. Otherwise you will not look determined during interviews and will become unhappy later. Perhaps you need to experiment. Working as a developer, system administrator, devops? Choosing a management or a technical career? Working in a startup, small company or in the enterprise. Additionally there are three main kinds of work in the IT industry:

• Consultancy
• Products
• Projects

There are pros and cons for each of those and there are mixed work modes. As a consultant you will earn a lot of cash, get around a lot, learn many things, see many projects and technologies. But you’re on the road a lot, living in hotels, always being the outsider and nowhere near sane working hours. Projects are between consultant work and products. You will see new technologies, it won’t become boring and there is a lot of excitement. The downside? A lot of pressure, deadlines and customers who seem never to be satisfied. Products offer different things. Steady work. Sane working hours. Sometimes deadlines but often not as pressing as in projects or consultant work. You will see the result of your work used by customers which is very satisfying. You see your work evolve over time which is a nice feeling. You can learn more about software processes in product development hatn in projects and consultant work. But technology change will be slow and payment usually is lower too.

What company to work for? Startups, small companies, large ones, Fortune 100 companies, international mega conglomerates? There are trade offs. Most often the larger the company the more money you can earn. The more secure is your job. Access to larger projects, more influental products, big brands and bigger resources. But often the larger the company, the larger the bureaucracy. Change won’t happen fast. Things are the way they are.

Smaller companies offer more freedom, change can and will happen. You will get more responsibilty faster, perhaps job descriptions are written especially for you. There is energy everywhere. But your job may be at risk in a startup, your pay is lower. What’s the right thing for you is for you to decide.

2. Job Applications

In many companies there is a candidate filter which is human resources. This HR filter will filter candiates for various reasons. The right for existence being the promise to reduce the workload on the hiring technical manager. Additionally if your CV goes into HR it lands in a queue.

The fast track is around this HR filter. Find someone who you think could say YES to your application. Where to find those? Listen to tweets on twitter, read blogs from hiring managers like team leads, heads of development, VP of engineering or CTOs. Directly contact those on networks like LinkedIn or XING. Ask if it does make sense if you send her your resume and if they are interested in good – or excellent – developers. After you get a yes, send your resume. Even if you need to go through HR, add the name of the manager you’ve got the yes from. This will pull your CV through the filter.

3. Survive the HR Filter

If not jumping over the HR filter, you need to get through it. Important here: Keywords and Buzzwords. They most often just filter for buzzwords. I always suggest to adapt your CV to the company you apply for (see next point). This is especially important with skills.

• Read the job postings of the company, what skills do they want?
• Look at the company and their projects, what skils do they need?
• Talk to HR what they are looking for

Go through your professional life – or university life – and see what skills match. Put those skills up in your skill list and also provide them in the cover letter. But do not overdo your skill section. John Fuex writes in Your resume. It’s the little things that hurt:

One of the most effective ways to portray yourself as a novice or one-trick-pony is to pile on the trivial details when describing past jobs or projects. [...] but remember that a resume is a brochure, not a biography. The prime objective of a resume is to get you booked for an interview, not to close the sale.

What skills are similar to the skills the company wants? Put them up too. If it is a Java job, do not put your PHP skills to the top. Think about what Java frameworks you have and put them into your CV. This will probably get you through the HR filter. Think hard about what skill to put on the top. Put the disruptive ones on top, not the ‘me-too’ ones. Whitney Johnson says:

Translating this to our careers, when we proffer to the marketplace a disruptive skill set, focusing on our distinctive innate talents rather than ‘me-too’ skills, we are more likely to achieve success and increase what we earn.

And I do wholehearly agree. But do not lie, this will surface during an interview, or worse later during the job when you are supposed to do things you have no clue and they fly in your face. As Lee Miller writes in Lying on your resume today may hinder your career in the future:

Career coaches advise the individuals they work with to market themselves in the most positive way they can. That should never, however, include lying or exaggerating one’s accomplishments, skills or experience.

4. Is your CV ok?

If your CV lands into my inbox – please use one PDF, no zip, no word, not 20 files, although all applications will be processed – it should not contain the obvious problems. If your resume looks like a fit, you will get a call, irrespective how bad your CV is formatted. That said, typos are annoying, let someone proof-read your resume. Gaps which are too big are suspicious, but I do admit those are not very important to me. The same goes if you’re too long out of jobs.

More convincing are your skills. But I do look where they come from. If your resume doesn’t explain in experience where all those impressive skills come from, it looks fishy to me. Large skill lists and no experience (job, open source, …) are a warning sign.

Are your past engagements too short? Unless you are a consultant or have specific skill for a special company phase, lower than 2 years looks also fishy, once is ok, twice looks dubious, more than twice: Are you a job hopper? How long will the recruiter be able to hold you? This might not be an issue if you’re hired for a specific project, change or transformation like mergers.

5. Code samples

If someone requests code samples, send them. If noone requests code samples, send them. They give the best impression of your work and if they are good, put you at the top of the other candidates. Even better if you supply a link to one of your projects on Github (or similar service). As Matt Biddulph writes in Algorithmic recruitment with GitHub:

When I’m hiring, one of the things I always want to see is evidence of personal projects. Over the last two years, GitHub has become an amazing treasure trove of code, with the best social infrastructure I’ve ever seen on a developer site. GitHub profiles let the user set their location, so I started with a few web searches for Berlin developers.

Slate writes:

In a hiring climate in which companies find talented workers by seeing how they already perform, the RethinkDB founders turned to sites like Github.com and stackoverflow.com, where programmers collaborate and work on special projects. “You can see the code being written and how technically accurate they are,” said Glukhovsky, who inhabits a world where 95 percent of coders can’t complete basic computer-science tasks.

I often hear candidates complain about the work they need to do to supply requested code samples. I’d assume everything up to 4 hours of work for a job you really want is ok. If you do not want to invest that amount of time into your dream job, why should the person hiring you think you will commit yourself to the company? The submitted code should be bug free, be well documented (The why, a little bit of how but never the what) and have unit tests attached (or BDD). Reread the code, make it the best you’ve ever written.

That’s it for the first part. The next part will include process, what to ask a startup, what to ask a company and some tips. What tips would you give for getting hired? I appreciate all comments.

You can leave a Reply here. Of course, you should follow me on twitter here.