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 and, 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.

7 Bad Signs not to Work for a Software Company or Startup

Photo by mundo resink

There is a job offer, you’re on a job hunt or a headhunter calls you. With the ending recession this scenario becomes more likely again. What are signs that you should not sign up with a company?

As someone who did a lot of recruiting and talked to many developers, I’ve prepared a list of signs that would tell me not to sign up with a company.

  1. No Source Control:
    Source control systems (SCM) are essential to software development. Be it Subversion, Perforce, Git, Mercurial or any other. Without source control integrating the work from different developers and projects is a nightmare. As Joel says in the legendary Joel Test:

    But if you don’t have source control, you’re going to stress out trying to get programmers to work together.

    There are still companies without SCMs, don’t sign up there.

  2. No top tools or only home brewed ones (IDE, Build System, …):
    Without the right tools, you can’t work. Depending on the programming language and enviroment, the company should use an IDE, debuggers, build systems that allow one-stop builds and professional deployments. Without the right tools, software development is a pain. If you’re a professional, insist on professional tools.
  3. No business model or not enough money:
    If you interview with a startup, ask them how much money they have and how long it lasts. Do not hire with a company that has less than 6 months of money – they most likely won’t make it. The same goes for a company without a business model. No income is high risk. If you’re young and like to take risks, it can be a worthwhile journey though (see the y-combinator financing model). It might be fun, and it might be valuable for you, but you have been warned.

    Some further reading, especially when joining a startup, is the excellent article Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup:

    How much money do you have in the bank? This is a simple question. You just want a number. If you’re told that “investors are ready to put in more” or “we have a line of credit,” beware because a promise of money isn’t the same as money.

  4. They don’t let you talk to or see developers:
    During many years of recruitment, I’ve always been astonished how few developers wanted to see their working space and talk to developers. Talking to other developers will enable you too get to know a prospective company. If they do not let you talk to developers, don’t go for the job.
  5. High turnover:
    A bad sign is high turnover. There is always a reason for it. Ask people in the industry about the prospective company. Ask during the interview, if the job is new or if you are a replacement. Casually ask developers how long they have been with the company. As Kate Lorenz writes in Six Signs to Run — Not Walk — From Your Job:

    After two weeks on the job, you are already halfway to becoming the employee with the most seniority. One of the biggest issues for human resources professionals today is employee retention. You will notice that most of the country’s top companies have employees who have been around for years.

    Do not get a job at a company with a high turnover rate. Period.

  6. Hiring is mainly done by HR, not by developers/technical staff:
    If hiring is mainly done by a HR person, there will be lots of developers recruited only by HR. Most of the time, they have no clue about what a good developer looks like. If you want to work with good people – and you should, because it’s the best way to learn – do not work for a company that doesn’t do recruiting with technical staff. Bonus points for a company that also lets developers interview applicants.
  7. No decent hardware:
    A company should respect their developers. As with good tools, decent hardware helps developers to turn more requirements into working code. Developers therefor should have a decent PC (e.g. dual core 3Ghz, 4/8gb memory) and 2 22/24″ screens. Bonus points for Macs. As shown in several studies, the easiest way to gain lots of productivity is two screens. A company that is not interested in the basics of productivity, is not worth working for. They will not respect you.

So – what about you? What are your signs that steer you towards a “No thanks” when interviewing with companies? I’d like to hear.

Thanks to @andreaskaiser @Tungano @mwessendorf @AgileArtem @Devgru @benjaminm @gjmilne for their input.

Update: Great post on 10 Startup Red Flags by Adam MacBeth