Seconds & pixels

Getting your first “real” job: 3 – Live interview

Part of a series. Also see: Part 0, Part 1, Part 2.

The CV was great, your application was successfully processed and read and you are now being contacted for an interview. You may expect some or all of the following. (Note: I’m using my own terminology to categorize interviews, don’t expect them to be called this way)

1. HR interview

For some companies this is just a routine check to make sure that you meet the absolute minimum criteria needed for someone else to bother with interviewing you (your CV/resume is up to date and you have some idea about what’s in it, you can express ideas coherently etc.).They also usually try to determine that you understand the job opening (or to clarify what position you’d be interested in). The rest is just around arranging the procedures for the following interviews.

On the other hand, some HR interviews are actually very important; whether it is or not depends on the company and you probably won’t know in advance, so you have to be prepared regardless. Tech people don’t seem to like asking the “soft questions” (soft as in soft skills, not soft as in “easy”) so sometimes you will get these thrown at you during the HR interview.

Examples:

- What are your strength/weaknesses?

- Describe an occasion in which you demonstrated leadership (or some other quality you say you have); or describe a setback, a mistake and how you reacted to it.

- Why are you a good fit for this position or company?

- Where do you see yourself in 5 years? etc.

You need to be aware of these questions and be prepared to respond. These may be difficult questions to answer under pressure, so you should think about them before and know what you want to say. Avoid trying to run away from the questions (e.g. Weaknesses? WHAT weaknesses?!) because they are important and the way you answer can say a lot about you.

Also, here’s a very good concise post from Seth Godin about what interview questions are actually trying to discover.

2. Technical phone interview

This is something that many people find very difficult and it really shouldn’t be. The purpose of the phone interview is just to screen candidates and reject obviously bad candidates early on. On-site interviews cost quite a bit of money for the company and so before you drag away some of your lead developers to be unproductive for some number of hours to interview a candidate extensively, you want to try and screen candidates as much as possible and only give them the best of the pool to evaluate, so you waste as little of their time as possible. Because of that, phone interviews SHOULD NOT be hard. They should seek to have you demonstrate the basic skills and knowledge for that job.

They will usually be 30-60 minutes long and in some cases (e.g. Google) will require you to actually write code during the interview; in general though that won’t be the case and they will just focus on you describing your way of thinking about a problem without actually having to type anything out.

Expect questions of the type:

- FizzBuzz

- (OOP): How would you design your classes for [some simple problem]?

- Explaining how a classic simple algorithm works (binary search, sorting etc.) or why you’d pick one over another

- Basic concepts of OOP (or another paradigm you said you knew) or of a programming language (again, that you said you knew)

- Tech details regarding anything on your CV. If it’s there, it’s fair game. So what’s project X about, why did you do it this way and not this way etc.

You may get “soft” questions here as well, especially if you didn’t have an HR interview. But you’re already prepared for those, right?

3. On-site interviews

This is the real deal, the make or break stuff. Some companies will have one or two, some will have several in the same day, some will actually call you in over multiple days. For most places, this will be the most intensive tech interview you will get. Expect to have to write code, to explain your previous work in detail and to have to give it everything you got.

Especially expect to FAIL some questions. I know this is difficult to accept, but try to understand that it will happen and just because you blew a question or even an entire interview, it doesn’t mean you automatically lost the job. There are companies which will give you increasingly harder questions to make you fail and see how you react. So keep a positive attitude, stay focused and answer to the best of your ability. Also keep in mind that these are rarely formal checklist interviews… What’s more important than solving the problem you are given is to show how you think, how you go about solving etc. No one really cares about your solution to that problem (because 90% of the time, they don’t care about the problem), as much as they  care about how you got to that solution, how would you perform if they were to hire you. The questions and problems are just props. Use them to your advantage and if you can’t, try to show off your skills around the questions as well.

That’s usually what you’re going to see and though I’ve encountered numerous variants, I think I could fit either variant into one of these boxes. I’ll talk about one more thing, which I haven’t encountered as much unfortunately, but it sometimes part of the interviewing plan and that is…

Project “interview”

This is the scenario in which at some point between the first phone call and before the on-site interview, you are given some sort of a project to work on, in your own time. I personally love this type of setup, though I’ve only done it two or three times.

The reason I like it is because it really gives you a platform to showcase your skills and eliminates so much of the subjectivity and guesswork in interviews. You write your code at home, on your own comfortable setup, with your own favorite mug of a hot beverage ready at hand. Whatever code you write then is probably a very fair indicator of what you will be able to produce on the job in a good day.

Not too much to say here in terms of advice… The projects can vary from the fairly simple (e.g. write some manner of a date picker) to the slightly more complex ones (e.g. for some interview I had to implement a virtual simple processor in Java and then write a program in that “assembly language” to run on that proc and solve some problem), but I’ve never found it to be too mind-boggling.

What’s important is that you don’t just write code that works, but try to write good code, well documented, tested, etc. You know, the best of the best!

You also should be prepared to talk about it later in the interview. Normally this isn’t a problem unless you tried to show off using some language, pattern or architecture you are not familiar with (so, don’t!). You will be questioned on your design and coding decisions, on alternatives to your approach, advantages, disadvantages etc. Pretty much everything that you’d expect in order to guarantee that you actually wrote that code and to observe how you came to make the decisions you did.

Do you have any questions?

Finally, I’d just want to add one more bit on the mirror-side of the interview and that’s what you should be asking. For some companies, the “do you have any questions” part is just that… a chance for you to ask any questions you want, no hidden things about it. On the other hand, for some companies this is a critical part of the interview.

Think about it this way… put yourself in the position of a firm which is going to invest lots of money into the training of a new hire (as some of the big ones do) and decide what do you care about more: how long that person will stay with you, aka how much you’ll be able to reap from your initial investment or what technical skills that person has coming in, which you’ll improve to a standard baseline with the initial training anyway. And what’s the best way to try and “guesstimate” how long you’ll keep that person, other than trying to see if they’re interested in the company and what you do? That’s why they care about your questions.

Regardless of that, you *should* care about the job more than just what it’s going to pay you and whether or not you get free bagels on Wednesdays. You’ll be spending more than half of your waking hours there if you start, you should care a lot about what you’re doing during that time. Since you do care, you will be doing some research and have some questions that your research won’t answer and you should ask those at the end.

You should probably be asking questions around aspects of the work that are not clear, around what a regular work day looks like, development procedures etc.You may also want to ask the questions of the Joel Test or similar things that are important to you.

The bottom line is: don’t be afraid to ask those questions, this is the best time to find out more about what you’re job would be like if you get hired. You won’t get much of a chance to do it after you get an offer and this will be very useful, especially if you have to compare several offers and pick one.

Resources:

Despite its length, this is actually pretty brief for a post about this topic, so I’ll give you a few more resources to read on later.

Have a look at Joel Spolsky’s posts on interviewing to get a bit more of the interviewer’s perspective. Here’s the one on the topic of the live interview, but you will find links for previous stages also.

If you’re looking for a book on programming interviews, this is a very good read:

It’s not too long, I went through it in just a few days when I was preparing for a Google interview, but it may take you a bit longer depending on how familiar you already are with programming exercises.

That being said, if I missed any important points, please ask questions in the comments so that I can edit and clarify. Good luck!

Share/Bookmark