What should I review for software engineering technical interviews?

July 7, 2009 6:42 PM

I've decided to start searching for a new job, and I'm incredibly nervous about the technical interviews that software engineering jobs often require. How hard are technical interviews? What are some things I should review before going to one?

A little background: I've been at my current job for 5 years. I work for a large well-known computer company, on a product written in Java, and get excellent job reviews. My current job did not require a technical interview. I am not somebody who writes perfect code off the top of their head or has an encyclopedic knowledge of computers - but I research well, am a fast learner, and have good software engineering design skills. I am in a leadership position on my team, although not the top dog or anything (it's a huge product).

I've decided it's time to start looking for another job (great timing, huh), and I am incredibly nervous about the technical interviews that most software positions require. It seems like forever since college, and my current job requires so much product-specific knowledge that I don't really deal with many core technical CS concepts anymore.

I am overwhelmed by the idea of reviewing all the material that could pop up in technical interviews, I'm scared that I will get some simple piece of lower-level CS knowledge wrong at this point, and I don't know where to even start reviewing anything anyway. The fact that I know there will be strong competition out there for any software positions doesn't help.

What should I brush up on before I start interviewing? Can you tell me about a technical interview you had recently? Are there any good books or websites that take you through a high-level quick review of CS topics I could use? How worried should I actually be?

Any thoughts are very much appreciated.

Anon because I don't want anybody to know I'm starting a job search yet.

posted by anonymous to work & money (16 answers total)

Look, it's all about attitude. I'm always willing to say "I don't know" when I don't know. and then I steer the interview to something I do know.

The most important thing is not to get ratted, not to look scared. Just smile, admit what you don't know, emphasize what you do know, and give examples of how you solve problems.
posted by orthogonality at 6:45 PM on July 7, 2009

If a company doesn't hire you because you don't know the big O time for traversing a red blue tree, do you really want to work there?

Be candid about your knowledge, control the discussion, and if something you dont know comes up, explain it the best you know how, but be honest that your work at XYZ corp focused around B, and you havent worked with that much.

As orthogonality says -- don't get flustered you forgot something simple. The worst thing you could do is beat yourself up over something silly. Most interviews are based around finding the limits of knowledge while simultaneously evaluating how the candidate deals with it.

I wouldn't hire someone who was an absolute perfect knowledge fit for a job -- whats going to keep them around? Wheres the desire to learn, and space to grow?
posted by SirStan at 6:59 PM on July 7, 2009

I would suggest if you haven't already, get your SCJP and SCJD (and if you're feeling particularly saucy, the SCEA). If you have these two most of the time people will get that you know the basics and won't bother with a programming test (depends a lot on where you're interviewing, naturally).

Otherwise… it's always the same bullshit: linked lists, sorting algorithms, give an example of a programming pattern besides the singleton, how-would-you-go-about questions, that sort of thing. If you're not given an IDE to write in, you can be reasonably assured you won't be penalized for fudging a few package or method names.
posted by Civil_Disobedient at 7:10 PM on July 7, 2009

What should I brush up on before I start interviewing? Are there any good books or websites that take you through a high-level quick review of CS topics I could use?

That depends on where you're interviewing and for what kind of position. If you're interviewing with Google, Yahoo, HP, Microsoft, or companies like them, you should be prepared for a technical interview. You should expect to be asked to solve algorithm and implementation problems and to be conversant with big-O.

However, if you're interviewing with smaller companies, for positions whose requirements match your own position, you probably won't be considered by the standards of a technical generalist or a CS final exam.

No one will ask you about red-black trees even in the context of a hard interview, but questions about much simpler, unbalanced trees can be hard to solve on a whiteboard, and you should be prepared for them. Learn at least one sorting algorithm (Quicksort? Heapsort?) well enough to implement it in multiple languages. A hard interview will test your knowledge to and past its limits no matter how much you study; the goal is to make the interviewer go as far as possible before that happens.

Books I strongly recommend for brushing up before interviews:

• The Algorithm Design Manual by Steve Skiena
• Programming Interviews Exposed
• Programming Pearls

Can you tell me about a technical interview you had recently?

Here are three questions I was asked in one of my last challenging phone screenings:

1. Write a function which, given two inputs: a list of integers, and an integer called the target, determines if there is a pair of integers in the list which adds up to the target; describe all data structures used. What are worst, best, and average running times of this function?
2. Given a list of strings, not necessarily alphanumeric, find all the sets of strings which are "anagrams" of each other. Again, describe data structures and note running times.
3. Design a collection class that implements insert() and a getMedian() methods. Describe the methods, associated data structures, and note running times.

How worried should I actually be?

Don't be worried. Do study your ass off, but don't be worried. Be confident and have fun with the process. The day of an interview can suck a lot, but the months preceding and after can be great for personal and professional development. Plan to interview around with all the companies that interest or intrigue you. Interviewers can have a lot to teach; your interview with one company counts as studying for interviews in following months.
posted by doteatop at 7:23 PM on July 7, 2009

I concur with ortho, and would elaborate : if those are your strengths, make sure you're targeting positions where those strengths make sense. If you're getting questions that are so completely biased away from where your competencies are then it's possible you're really misjudged that position.

But be confident in what you DO know! If your strength is in research and problem solving - and presumably design and management - then show that and sell that. If they ask you a question you don't know the answer to then say so and indicate how you'd approach finding the answer if this came up in your workday.

If that's not enough for them then perhaps that's not the job for you. If you're leaving a currently stable job then obviously you think finding the Right job is more important than landing A job. Trust that.
posted by phearlez at 7:36 PM on July 7, 2009

I would suggest if you haven't already, get your SCJP and SCJD (and if you're feeling particularly saucy, the SCEA). If you have these two most of the time people will get that you know the basics and won't bother with a programming test (depends a lot on where you're interviewing, naturally).


I could not disagree more. I would NEVER wave someone through a technical interview because they had some bullshit certifications on their resume. NEVER. If you want to get those to improve your knowledge or whatever hey great, but do not get them to hope to get waved through interviews. I will add that I would not want to work for a place that waved anyone through their interview process no matter what their certs or past experience.

To the OP, it really depends on where you are interviewing as to the kinds of questions you will get. I personally always give a pretty hard techy interview but others at the same company I work might not expect so much. If you're going to interview at a place like Google or MS, you are absolutely going to be expected to write some code, but you can find out a decent amount about their interview process on the internet. That's actually not a bad place to start. Read some of those "sample interview questions" and try to do them. If you choke on writing simple Java on the whiteboard, practice doing that. Write a simple implementation of some of the methods of HashMap. Refresh your knowledge of basic data structures. That won't get you through all interviews but it will help you feel more comfortable with the process.

Here's some more concrete suggestions: do not put ANYTHING on your resume you are not prepared to explain to me. If you put shit about SOA, REST, Postgres, Ant, Maven, Ruby on Rails, what the fuck ever thing, I am going to ask you about it and I can tell if you are bullshitting me even when I don't know that much about the product or technology, so don't try. I don't care if you are perfect in your implementation of the code I ask you to write, but if you have been working in Java for the last 5 years you will look bad if you don't remember the basic syntax of a simple class. Talk me through your algorithm, I will give you hints if you are going far astray. And never underestimate the power of unbridled dorky enthusiasm about technology.

Good luck!
posted by ch1x0r at 7:38 PM on July 7, 2009

Relax, treat it as a meeting with co-workers, as if you've already got the job.

Take some ginger gravol beforehand if you have nausea when stressed.

I'm a developer, but I've also been on the other side of the table.

Don't over dress. Developers are usually in jeans and t-shirt, so wear some nice pants and a shirt with tie. One step up dress-wise, casual so that you don't give an uptight impression, yet somewhat formal that you respect that it's an interview.

2nd'ing a refresh of the basic things you may have forgotten.

Bring a favored reference book or two. If they do want to test you, they usually allow you to look up things. Nobody is perfect. Knowing how to find needed information is more important.
posted by hungrysquirrels at 8:16 PM on July 7, 2009

SirStan writes "If a company doesn't hire you because you don't know the big O time for traversing a red blue tree, do you really want to work there?"

That's red black tree, SirStan. No job for you!
posted by orthogonality at 8:41 PM on July 7, 2009

Here's a long, very well though-out insider's look at the thought processes of someone who interviews coders: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

It is just one opinion, but it's a very good and informed one.
posted by dualityofmind at 9:10 PM on July 7, 2009

Technical interviews are just as difficult for the interviewer as for the interviewee, and in my experience (most recently on the hiring end, and watching my colleagues conduct interviews), most developers are not particularly good at it, and they're likely as nervous as you are about the prospect.

Be friendly and personable, and participate in the small talk at the start to the fullest extent possible. When they decide to launch into the first (detailed) technical question, respond with a sketch of the question, then work with them to verify what is wanted. Too many technical questions go awry on simple misunderstandings, and getting the question right is just as important as getting the answer right. As an interviewer, I am looking for the ability to work with a person to solve problems with me WAY more than the ability of the person to rattle off answers to my questions. If you see an opportunity to demonstrate some skill or knowledge that you possess above and beyond what was asked, do take it, but only if you're confident that you can hold up against more questions along that line.

An interviewer will take cues from two things: what is on your resume, and things you mention in the course of the interview. If you don't think you can handle sustained questions about a technology mentioned on your resume, remove it.

When the "so, do you have any questions?" moment arrives with a tech person, don't ask about the culture or benefits or process, ask about the funnest/toughest technical challenge that person was confronted with in their work there, and what technologies/techniques he/she brought to bear. The best possible interview ends with mutual geeking out and, optimally some Star Wars, Office Space, or Lebowski reference.
posted by jimfl at 9:14 PM on July 7, 2009

I concur with ortho, and would elaborate : if those are your strengths, make sure you're targeting positions where those strengths make sense.

I think this bears repeating. Given your background, maybe you really don't want to be looking for the positions that the killer technical interviews — like the ones Joel on Software is talking about here — are designed to act as filters for. Because a big part of those interviews seems to be, basically, they're looking for people who know programming so cold, they dream in it.

It sounds like you know that it would take a fair bit of remedial skill to get you back to a level where you're going to be competitive with people looking for those positions (people who are going to be able to solve basic programming questions as fast as they can write on a whiteboard). So maybe instead of spending a lot of time studying your old CompSci assignments, you can think about what you've done over the past few years that differentiates you from the crowd, and specifically look for jobs that play to your strengths.

I was kind of in the same boat that you're in, the last time I went on a job hunt. I had some development experience but no formal training, and all my recent experience was on one very esoteric software platform in an all-but-dead language. I was upfront with potential employers that although I did have some development experience, I wasn't looking for work as a developer and I didn't really think of my self as a professional developer. Getting that out of the way early tended to either end the interview (in a couple of cases), which I considered acceptable — no sense sweating through a technical interview when it's just going to be a waste of time for everybody — or steer it towards a conversation about my previous experience and how I might fit in and be an asset to them.

This was in a bit of a different job market from what you're looking at now, and I'll be honest I really wouldn't want to do it again today, but I think if you're willing and able to be patient (i.e. do your job search from your current job, not after you quit), you can find something that fits your background. You just need to decide exactly how you want to market yourself, and what you really think you bring to a potential employer's table.
posted by Kadin2048 at 9:50 PM on July 7, 2009

I could not disagree more. I would NEVER wave someone through a technical interview because they had some bullshit certifications on their resume. NEVER.

That's great. I said programming test. Now please go tell your IT admin about his "bullshit" CCNP.
posted by Civil_Disobedient at 10:24 PM on July 7, 2009

I could go on about this but in short:

1) review basic algorithms stuff
2) review big O notation
3) review graph theory

these kinds of questions are almost always about graph theory. Unless the company has a specific niche in which case study that. Do they use ASP, will you do a lot of SQL work, etc.

4) google all these topics plus "interview". you will find plenty of war stories and compilations of question from both interviewers and interviewees

5) read "How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle" which a fun book by itself. and google up a lot of brain teaser questions.

These kinds of questions are pretty useless as hiring indicators but people ask them anyway. I think their only purpose is to try to see how you react to being asked to do something asinine.

6) read up on how to handle a case-study interview e.g. Boston consulting group's guide to case study interviews. You won't be doing one exactly but the basic principle of keeping your mouth going even if you have nothing to say yet applies to technical interviews as well.

I got a job at a company that's well-known for asking tough technical and puzzle questions. After 4 puzzle questions where I already knew the answer from research the interviewer gave up asking them. After having flopped graph theory questions in other interviews I did pretty well on his graph question. Interviews are surprisingly formulaic.

This is no different from any test you ever took in university and it is in many ways easier because it's almost impossible to get a wrong answer as long as you try really hard. On the downside you don't know exactly what they'll ask you but these types of interviews are a lot less original than the interviewers think. My employer has a long list of banned questions because they got used so often that they're useless - everyone knew the answer before they got through the door and it was only a question of whether they were honest enough to say so or if they faked figuring it out on the spot.

I'm always willing to say "I don't know" when I don't know. and then I steer the interview to something I do know.

Also, this. You're just as likely to get an interviewer who has no clue what the hell to ask you so be prepared to take the reins.
posted by GuyZero at 11:46 PM on July 7, 2009

Also, re: the Mt Fuji book - don't just memorize the answers. Actually practice trying to solve the puzzles. Logic puzzles have their own tricks and techniques and learning those is the key not just memorizing about ants moving around the perimeter of a triangle clockwise or counter-clockwise. If nothing else, it's a workout for your brain.
posted by GuyZero at 11:51 PM on July 7, 2009

It's totally attitude. I think I interview well (though who knows, really) and I've said "I'd Google it", "I don't know", or "I'd look at the man page" more times than I can count. No good* company interviewing for a non-entry-level position will focus all that much on stupid technicality/syntax/nuanced-theory type questions.

Treat questions you don't know the answer to in the same vein as "How many hamburgers are consumed in McDonald's each day across the country?" type guesstimation/reasoning questions. Say "I don't know, let's think..." and start talking out your thought process. There probably aren't that many questions you could be asked that you know absolutely nothing about, whatsoever.

A good programmer is a good reasoner, not an encyclopedic reference.

Thought studying can't hurt either, I guess :D

* = worth working for, in my rough, overreaching simplification of employment
posted by wrok at 11:15 AM on July 8, 2009

That's great. I said programming test.
So you think it is worth the time and money to get a certification merely to get out of having to take a basic programming test? Fascinating.

Now please go tell your IT admin about his "bullshit" CCNP.
When did we start talking about interviewing IT admins exactly?
posted by ch1x0r at 4:58 PM on July 8, 2009