Getting Hired – Part 2

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.

This is the second part of the series, the first part can be found here and contains:

1. Where to Work
2. Job Applications
3. Survive the HR Filter
4. Is your CV ok?
5. Code samples

6. Do I really want to work there?

Do you really want to work at that company? Many people see this as a given. But you need to check out the company especially during an interview. The company does present itself to you as an employer, not only are you presenting yourself as a potential new employee. Ask questions (see below) which will help you decide if the company is right for you. Money is not as strong a motivator – especially long term – as you might think at first. See what I wrote in Developer Motivation and Satisfaction and what might get you demotivated:

Technical reasons like no recent hardware, inadequate tools and a frustrating enviroment. [...] Micro-Management and drowning creativity

I’ve been doing hiring for quite some time now and I’m still astonished how few candidates want to see their work space and colleagues. You will spend more time there and with them than at home. Are there windows? Is lighting nice? Two 24″ flat panels? Decent computers?

It’s also not fair starting to work at a company and then walk away if the environment doesn’t fit you. The hiring manager probably took quite some time to recruit you and has sent off other excellent candidates. Decide before you sign the contract if the company is the right thing for you.

7. Things to know about software development processes

One of the biggest impacts on your job, your satisfaction, your day-to-day work is the software process the company has installed. There basically are two process models to follow: Waterfall or Agile (this is an over-simplification). Waterfall has larger time spans and iterations, there is a focus on up-front planning, writing project plans and execute those plans. Agile is about smaller iterations, usually two weeks and getting things done in micro steps.

From my experience Agile works more often than Waterfall works and is easier to do. Most Waterfall environments I’ve worked in failed in a spectacular way, meaing no deadlines were held, long working hours, unsatisfied customers, product mangers and developers, the second half of a project being very often in firefighting mode. Agile I’ve seen more often working. There are many Waterfall and Agile processes, the most important to know for Agile is Scrum. Scrum is easy to learn and easy to implent (at least to get 90% right).

As said before, the chosen process will have a very large impact on your work, so you need to decide if the process the company has implemented is right for you. To give you a small insight into Agile I wrote in “What Developers Need to Know About Agile” what Agile means for a developer:

1. Much less crunch time
2. More working on features
3. Less meetings
4. Pull not push
5. Be a critic
6. Agile makes you happy
7. Responsibility as a team
8. Agile is about working, high quality code

Agile does expect something from you though: As stated above it demands being a critic and taking responsibility. This often means teamwork and a high level of communication. Agile teams communicate a lot, many of those communications outside of the team. So if you want to get your work items and write some code and don’t be bothered, then agile is not the right thing for you. You will be more happy in a waterfall environment. Agile is not for every developer I’ve learned.

8. Interviews

There is one thing not to forget about interviews: The company needs to hire someone. It’s not only that you want a job. So the company presents itself the best way possible. This is not a one-sided beauty contest for developers. The company needs to sell itself to you. And you as a developer need to decide if you buy.

The second thing not to forget: Interviews are a number game. Even if you’re very good, the company probably has more comparable candidates. As they often need to decide on one candidate, and you’re out, this does not mean you did not make a good impression. So even if you’re good you need to take several interviews. This is a number game.

If you have several interviews, go to the dream company first or last? There are points for each, when experience with interviews I would go to the dream company first. If unexperienced I would go last. Last means you can gain interview experience but it also means you need to keep some companies at it until you get hired by your dream company. And if they do not hire you and the others lost interest, then all options have vanished.

What to expect in an interview? Many HR types will ask questions about your teamwork ability, how you solve problems, how you interact, what you expect from your job. Technical managers or developers will mostly ask three kind of questions: Algorithm questions (Google style of interviews), manhole cover questions (Microsoft style of interviews) and practical programming and technical knowledge questions. You can find them all over the net, I’ve wrote about Java questions here, here and here as I prefer the third type of interviews.

There is a simple test called FizzBuzz. It goes like this:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

I also use this test or some form of it during interviews. The astonishing thing is this: Many candidates are not able to write this simple program. If you do not understand what happens there or are not able to write a similar simple program, please don’t apply for a developer position.

What also to expect? During my interviews candidates need to read code on their own, around 20 classes, understand and document the code with simple UML. Then we go through this code and the candidate explains what happens there. What bugs are in the code? It also delivers many starting points for discussions on code design, code quality, design patterns, Java APIs and many more. Why do I do this? Because reading foreign code and understanding what happens there is a crucial skill for developers – even more the older the company is and the larger the code base.

9. What to ask a startup

There is only one question: How long will the money last you currently have? If they do not answer you, dance around are say something along the lines of less than 6 months, don’t join. Beside that there is Guy Kawasaki’s 10 Questions to Ask Before You Join a Startup which is a must read if you plan to work for a startup. Don’t be shy to ask this hard questions!

10. Money

Money. Obviously an important topic, most of us wouldn’t go to work if they would get no money for their work. During an interview the hiring manager will probably ask how much you want to earn at the job. Should you answer? There are different theories if it’s better if you give a number first or the company gives a number first. There are benefits and problems to both outcomes.

Most hiring managers – especially in smaller companies – will press you to produce a number. This means you need to know what you want. And you need to know what you’re worth. You should ask around, look on the web for comparable pay etc. Then should you take some risks to demand more? It’s up to you but getting a raise later is much more difficult. As I wrote in Top 10 Tips (+1) to Get a Pay Raise there are more rules which apply to a pay raise later on that do not exist during an interview:

There are some general rules when asking for a pay raise, like companies giving out raises only once a year. [...] My general rule: If you did not change in any way in the last year, it’s not very probable you get a pay raise and more money.

Simply the easiest way to get more money is when starting a job. If you start too low, you will always stay too low because many companies have a upper limit on the percentage a pay raise can be. There is a book I suggest you read, it’s called “How to Make $1000 a Minute” and deals with the issue of money during interviews.

Hope you enjoyed this second part for it’s the last. As always I’m interested in opinions and additions, please leave a comment.

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