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.
- 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:
- (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…
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.
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.
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!
Your resume is very important (as if you didn’t know that already)
Unless you are referred for a position, this may very well be the single piece of information that will decide whether or not you move on to the next stages of the application process. You need to make sure it represents you well, it’s concise and easy to read and it’s truthful.
Your resume is not all that important (and I like contradictions in my posts)
About one year ago, I spent an exaggerate amount of time (re)designing my resume. I rewrote the entire thing in Latex (and I don’t even know Latex). I had it reviewed by several people multiple times, made lots and lots of modifications, maintained different versions etc. I’m not saying it was the best resume, but it was definitely the best I could do at that time.
All this glorious effort and the vast majority of jobs I applied for never ever got to see it. Why? Because they use these recruiting apps where you have fill in all the data that is in your resume in a web form. This will quite probably be the most frustrating experience in the whole process. You’ll be filling the same information over and over again, in pretty much the same web app (no really… they use the same one! But you still have to write it every time again and again because there’s no information shared from one to the other) and that’s just the way it is. Honestly, if there is a way to write your resume that makes it optimised for the auto-filling function of these apps, I would definitely keep a version written in that way, but I’m not aware of any.
Anyway, that aside and assuming you won’t be filling out too many of these online applications, you should have one resume version that looks good; but just *good* should be enough here. The effort to go from a good resume to a fantastic resume is (in my opinion) not justified by the gain you’re going to get. I think it’s safe to say that by the time human eyes actually read your resume (so that they can be impressed by your awesome design skills), you will generally be already past the first stages of the process where the resume is the most important thing.
Keep it concise and well-organised. Do a good job, put some thought into it to make sure it represents you well (you should be proud of it), but don’t sweat the design/layout too much. There are lots of designs and formats out there, just pick one that you like and go with it.
Also don’t be afraid to maintain and create different versions, targeted for specific jobs or regions. You could have a longer resume which contains everything you would want to say, but don’t have space for* and from that you can create more concise versions targetted for your specific application.
Okay this was utterly unhelpful and boring, what’s next?
I know I didn’t have much to say here, but I had to talk about it at least a bit. Next thing, I’ll tackle how you actually go about applying to jobs and I’ll have some more interesting things to say there.
* I am really just mentioning this for the sake of having it there, because since this series is for getting your first job… I really don’t think that it should be the case that you have so much content to squeeze in. If you are just fresh out of college and feel that you have a lot more to say than you can fit in 1-2 pages, you’re probably not filtering the content right. Get some reviews from more experienced people to help you take out the most important bits and drop the rest.
Having recently finished a job search that has taken waaay too long, I will probably have some advice in the next few months for recent grads which I will want to share while it’s still fresh. So I’ll probably kick off a series on this topic and touch on a few different areas.
(Image source: http://s0.geograph.org.uk/photos/29/83/298363_f4ceabc2.jpg)
I’ll try to not reiterate things that are already out there and probably better presented (such as resume samples), but instead focus on more “high-level” and personal advice.
Also, this will probably be more helpful to computer science (and related) grads than to the rest of the world, but I think some advice may be worth taking away regardless. We can always build up based on questions from the “audience”.
To start you off, if you are or were a CS student, you need to read this article. Now.
Still here? Okay, here’s a few points to get started.
Grades aren’t really that important.
I had two CS degrees, some research experience and a published paper; I was first in my class with the highest GPA that year, best senior design project, magna cum laude, Dean’s List, ACM president and quite a few other academic distinctions, awards and latin words to feel smug about at Christmas parties.
While these are all good and they do say some things about me (things that some – read a few – companies do care about), I must stress that your grades will not get you a job.
There are two take-home messages here.
* First, if you have really good grades, good for you, they will give you a slight boost, but will not be even close to enough to get you a job. I’m sorry, but that’s the truth.
* Second, if you don’t have really good grades, don’t worry about it for one minute, it doesn’t matter (or rather, it doesn’t matter as much as the other things you may have done).
The economy you say? What economy?
If you’re looking for a job now (as in around the time that this post is published), you need to face the fact that the world kind of sucks. I can’t help you with that. Companies don’t have much money to throw around and whatever money they have will rarely be used on hiring entry-level developers, which are always a bit of a gamble (an entry-level dev could be a really good, yet-unknown talent and you get yourself a great deal, but more often than not they are not good at all, and you’re losing money on bringing them up to speed).
You’re also more expensive to your employer than you think. Sure there’s your salary, but they also need to invest in your training, in the time that other people will spend helping you out in the beginning and in the fact that you are probably not as efficient as people with at least one year of experience behind them. So if your salary is disappointing, keep that in mind.
If you don’t think you can take it, go get a PhD if you want and hope that 6 years from now things will be better. Otherwise man-up (or woman-up) and deal with the fact that getting a job will be very difficult and you may not land the opportunity that you were dreaming about in freshmen years.
I just can’t get a job!
Don’t allow yourself to become desperate! At some point an opportunity will come your way and you will be tempted to hug it immediately because it’s the first one to come out of a potentially long period of silence. Don’t rush into it and think about it first!
It may not be what you wanted to do and that’s not necessarily a disaster, as long as it’s in line with how you see your career going in the next few years. If you want to be a developer, will this position involve coding or interacting with code? If you want to be a consultant, will this position let you interact with the businesses? How will this job help you get trained? What’s the possibility for growth? If you’re in the kind of work that needs certifications, will this job help you get them? etc.
Again, yes money is important, but money is short-term and just one part of the picture. You’re just starting out, make sure you’re going in the right direction and in the long-run you’ll get more satisfaction and more money. Don’t sell your future for a few extra thousand.
You can ask these questions during the interview, if anything they will show that you know what you’re looking for and are genuinely interested in understanding the offer. You can also negotiate some of these things.
At the very least, make sure you will like what you’re doing. Otherwise, as stressful as it may be, keep looking.
I bombed that interview!
Keep growing even while you already involved in the job search process. If you get a technical question on an interview that you can’t answer, look up the answer later. If it shows an entire area that you’re not as strong on as you should be, read into it before you schedule your next interview. Be prepared for “soft” questions such as what is your strength/weakness. If you find that you seem to be lacking on an area of experience and have some time to spare, try to get on that (this could be anything from learning about design patterns to getting involved in an open-source project etc.) More on that when we get to the interview part.
Next up, I’ll give you some points about resumes and getting started.