My post on recruitment mistakes was intended for managers trying to find software developers. This post is for those on the other side of the table: you, the developer, trying to land a job. Here’s how to make your job application stand out, and how to impress me in the subsequent interview.
This is written purely from my personal perspective. If you want me to hire you, this is the perfect guide for that. For other managers, your mileage will vary. Wildly.
Your application
The application is usually my first point of contact with you. Make it count. Here are the most important questions I want your application to answer:
Do you have the required skills?
It’s all about the skills. You need to have them, and your application must make it clear what your skills are. I’m looking for real experience in any and all areas of producing software: programming, testing, design, specifications, version control, build systems, tech support, maintenance, optimizing, documentation, algorithms, project management, debugging, IDEs, tools. The more you know the better.
Do you get things done?
While talking about software is fun, we need to actually build some every now and then. I need to know that you are someone who gets things done. So be specific about what you’ve done in the past. I don’t want to hear how “you played an important role in the development of the Fnorb Buzz product suite”. I want to know what you did exactly, in plain engineer speak. Did you write code? Specs? Run tests? Manage projects? What tools did you use? What did you learn?
Are you passionate?
I’m looking for signs of passion. Passion for developing software, of course – while passion for martial arts or cultivating Spanish snails are nice, it’s not what I’m primarily looking for in a software developer. If you spend time with software and computers on your free time, please don’t keep it a secret. It’s always cool to read about how you set up off-site backups for your mom with some cron jobs, rsync, and shell scripts, or about that data center you built in your closet.
Are you a good communicator?
I don’t want to read a 15-page account on every single computer related thing you’ve ever done. Keep it short, sweet, and relevant. Try to put yourself in my shoes – what is it about yourself that I would find interesting? I need to know about your skills and what you can do. What compelling evidence do you have to showcase your awesomeness?
That’s all, really. If it seems that you’re not lacking in any of these departments, I’m not going to throw your application in the trashcan. Yet.
The phone screen
If your application looks interesting, I’m going to schedule a short phone interview with you. My main goal is to find out more about your communication skills, but now verbally instead of in written form. I don’t have a particular method for doing the call. I’ll just ask about things I’ve jotted down on the margin of your application while reading it.
The interview
If the phone interview went well, then we’ll finally get to meet face-to-face. In addition to you and me, there will be one or two other people present in the interview as well.
Talking about code
I’m going to make you do a coding exercise or two on paper or a whiteboard, or possibly a laptop.
If I already know for a fact that you can code, I may skip the coding exercise. In lack of other evidence, I’ll have to rely on the coding exercise. I’ll find out if you can program your way out of a wet paper bag. Then I’ll find out if you can work with code for real.
We talk about code, you write some, and I’ll find out what you know. I’ll see how you react when you run into problems, what you do when you get incomplete instructions, and in general how you go about solving problems.
Other questions
We won’t just talk about code, of course. We’ll try to find out what kind of a person you are, so we can determine if you would fit into our team or not. Also, we’ll need to find out some basics about why you’re looking for a job, what kind of a salary are you hoping for, and so on. You should want the job for the right reasons.
My advice for these questions is simply to be honest. Tell me the truth. Don’t tell me what you think I want to hear, because that’s probably not what I really want to hear.
Towards the end of the interview I’ll ask if you have any questions about anything. If you have no questions, I’m bound to think that you’re not very enthusiastic about getting the job. On the other hand, if your questions indicate that you’re already thinking about what it would be like to work for us, it’s a good sign. I wouldn’t like to hire you if you just need a job, any job.
So, now you know how I will deal with your application. To make me hire you, all you need is the skills, the right kind of motivation, and a suitable personality. Easy, right?
Related posts:
- Do You Make These Mistakes When Recruiting Software Developers?
- 6 Tips for Small Software Vendors to Understand Enterprise Customers
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
Comments on this entry are closed.
{ 3 comments }
Inside Tips for Making Me Hire You | Hashed Bits http://bit.ly/8MlyO
This comment was originally posted on Twitter
Inside Tips for Making Me Hire You: http://bit.ly/12vSO5
This comment was originally posted on Twitter
One piece of information that sometimes hiring managers may overlook is to see if the person is open minded about technologies and languages other than what he or she likes.
Someone may be a perfect candidate and absolutely and totally meet your needs, but if the person is not open minded about other technologies it could be a problem in the future. Whether it is a merger or some program that you need to use in the organization, if the person is not flexible towards other technology enough to at least tolerate the thought of working with other technology then the hiring manager needs to consider the candidate may not be willing to change as the business needs do.
Simple example: An organization uses python and everyone in the company uses python and loves it. Nobody in the company uses or even likes perl. A new employee is interviewed and there is no consideration of how flexible the candidate is towards other technology besides what you are hiring him for. The candidate happens to hate perl with every fiber in his body. The candidate is hired and he becomes one of your best developers. A year or two later there is a new business need and the business finds a perl package that does almost exactly what the company needs. The only resource available at the time is that one employee that you forgot to see how flexible he was with other technologies; the company is now faced with waiting for another resource to become available, giving this developer a task that he is telling you he very much does not want to do or creating a new package in python.