Help me prepare for my programming interview!

October 28, 2010 12:04 PM

I'm a computer programmer, and have an exciting job interview lined up. Yaaay! Help me prepare by suggesting some difficult (but reasonable) programming interview questions to practice on. Also, I would appreciate any general advice you have for succeeding at programming interviews.

Feel free to post any sort of algorithm/design/general knowledge questions here, or link me to other sites that are good for such things.

One requirement -- any questions must be posted with the solutions -- how else will I know if I'm right? ;)

As for general advice -- I'm pretty much a nervous wreck in these interviews and suffer from severe performance anxiety. So I would appreciate any sort of helpful tips/tricks for being prepared and confident in this situation.

My background : Java, OOP, server-side web development, SQL/data design

I have lots of experience and have completed some great projects, but I'm really bad at these kinds of interviews. Help me improve!

posted by coelacanth! to computers & internet (12 answers total)

Try the code-golf and interview-questions tags on Stack Overflow.
posted by mkb at 12:32 PM on October 28, 2010 [1 favorite]

My goto question for testing someone's SQL knowledge is to ask them to explain the difference between a NULL and an empty string. It's a question most people don't know the answer to, especially if they haven't studied the theory side of relational databases.

The primary reason I ask it to see if they candidate can admit to not knowing something, or will try to BS through it. It looks like the practical answer has recently changed though. The theoretical answer remains the same (NULL == "I don't know/care what value goes here", empty == "I know there's nothing here")

My advice to be ready and willing to admit to not knowing something stands though. Being caught out trying to overstate your qualifications will end up worse for you than admitting to weaknesses. So long as you can demonstrate the capacity for learning and growth, and a general fit for the personality of the group.
posted by nomisxid at 12:47 PM on October 28, 2010 [2 favorites]

Typically, for coding interview problems, it's not the final solution that you get to, but HOW you get to those solutions. They want to know how you think. Talk through the problems, asking questions for clarification, explain your thought process. Think of it as showing your work.
posted by cgg at 12:48 PM on October 28, 2010

Work through some of the problems in Project Euler
posted by anelsewhere at 1:00 PM on October 28, 2010 [1 favorite]

Despite its questionable usefulness in actually interviewing candidates, you should read or know the concepts underlying How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle. Not specifically programming related, but more big-picture than code.
posted by meowzilla at 1:05 PM on October 28, 2010

Google and Microsoft no longer use brain-teasers.
posted by jchaw at 1:42 PM on October 28, 2010

When I interview people (I'm chief architect), candidates have already been screened for a certain amount of programming ability. So when someone is put in front of me, I know that they have some basic skills.

I have two levels of interviews, novice and advanced, but they're both similar.

In either case, I'm trying to determine:

• Critical thought
• Communication
• Motivation
• Skill
• Passion

I ask questions that have nothing to do with these things but in answering will demonstrate the presence or lack of one or more of these items.

You'll note that none of those things are tied to a particular technology or programming language. If you give me someone who is solid on all those fronts, I know that s/he can learn any programming language/problem domain.

When you're answering questions, talk a lot. Talk through your solution and each step. Draw pictures. Ask questions.

I tend to be wary of puzzle questions. The reason being is that some puzzle questions are based on knowing a trick and that type of question either tests your ability to remember tricks, be brilliant, or be lucky (probably a couple other things too). I'm in the first category, so what would stop me from pretending to be in the second?

When I was entry level, I remember being asked to write the Towers of Hanoi. I felt a certain amount of disdain for the question (it's really not that hard), so I asked "recursive or non-recursive?" I seem to recall that I didn't have to actually write it at that point. If I were asking that question now and I had someone ask me how to solve it, I would ask what the difference was and why would you choose one over the other.

Now let's turn the process around. You are not the only one being interviewed. You are interviewing the company. You should have with you a list of questions that you want answered.

If I were interviewing I'd want to know about the business model, revenue streams, growth curves, development tools, build automation, QA practices, benefits, corporate culture, growth potential, IP (patents, papers, etc), competitors, and so on. See also the Joel test.

Find out who you would be reporting to. Try to figure out their personality, their motivation and so on. Could you work with that person?
posted by plinth at 1:53 PM on October 28, 2010 [3 favorites]

Anecdotally, the toughest programming interview I ever had was for a J2EE developer position with a large bank. My resume/portfolio web site got me as far as a face-to-face meeting, but it was a "Level II" position and what the interviewer was clearly trying to establish was whether I had a decent grasp of application architecture... both in the abstract and specific to J2EE. He asked me to draw a 10,000 foot overview of a web application I had worked on in the past, and describe its components.

I like to think that I do have a pretty good grasp of architectural concepts and patterns, but being largely self-trained I had a hard time putting some of them into words... I could tell that I was not making a very strong impression and I ultimately didn't get the job. If I had a do-over I would probably spend a couple of days browsing through the O'Reilly JSP book and a good design patterns resource so that I could at least have the vocabulary fresh in my mind, even if only to say that I'm not very familiar with XYZ. (In interview situations I have found that just knowing what XYZ is and why it's significant or relevant is often sufficient to purpose.)

Good luck!
posted by usonian at 2:24 PM on October 28, 2010 [1 favorite]

We like to ask "basic" questions quite often which can easily be expanded.
"Do you know what the unix tool wc is?" leads to "write wc in python/perl/whatever" (you'd be suprised how many people claim years of experience in a language and get stuck on opening a file for read in that language) which leads to "now implement the -l flag" and so forth.

Be precise when writing code on the whiteboard. I hate interviewees who go "and here we would create data structure X and sort it and do Y" and carry onwards with the hope that I won't make them go back and write the bit they glossed over.

Good luck!
posted by lyra4 at 3:48 PM on October 28, 2010

I interview programmers, though I work on the operations side. The questions that I ask tend to be about efficiency, robustness, and how well a coder understands some of the bigger picture.

1. On a whiteboard, can you write pseudocode (or code) that implements a bubble sort? Why is it universally considered to be a bad algorithm?

This is a softball question to see if they know one the fundamentals of CS (if they've got a background in CS, they've definitely written this algorithm before)... but there's a lot more to it than that. You'd be surprised how many candidates don't know (or remember) what a bubble sort is -- and only about 1/3 of them will ask, before struggling through an entirely incorrect answer.

They do not really lose points for asking "What's a bubble sort, again?", though we don't tell them that. Once we tell them, we still expect to get a decent implementation in pseudocode.

I work in a highly collaborative environment, where if you don't know something, you always ask. If a candidate doesn't know what a bubble sort is, but tries to fake it because they're afraid to ask the interviewer, that's almost always a no-hire.

2. Draw a flowchart showing the process of making a pot of coffee. We're especially interested in your error checking and handling.

There's nothing sneaky about this. We're interested in error handling (Is there a used filter in place? Yes: discard it, No: move on... etc. etc.), and your ability to break a seemingly monolithic task into its component parts. We especially like it when someone starts, then realizes they've forgotten a possible error condition, and goes back and puts it in.

Too many coders sit down and write code that has to be immediately refactored. If they spent just a little bit of time up front thinking about the whole problem, they'd write better code the first time. This exercise shows us how they approach code design -- even if they never draw another flowchart, it shows us quite a bit about how they go about thinking before coding.

3. You've got a browser window in front of you. In the Location: bar, you type a URL and hit return. Eventually, a completed page appears in your browser. What happens under the hood and across the wire between those events?

This is intentionally open-ended -- a lot goes on there, and the parts of it that people focus on (and especially where they start in the process -- the first relevant thing after hitting return is ______) are very revealing wrt how they think (and again, how they break down a big task into a lot of smaller ones). Do they start with "the URL is broken into host and URI, and the browser calls gethostbyname()..." or do they start with "The browser makes a TCP connection to the server designated, issues a GET request with the following headers, and..." or "The browser initiates a connection to port 80, starting with a three-way-handshake, and..." (The three examples show a browser-centric, application protocol-centric, and network-centric way of approaching this)

It's also a good place to evaluate a candidate's ability to explain technical things in plain English, and to show whether they have the innate need to know what's going on inside of the products that they use.

4. What are some differences between writing a web application that serves 15,000 paid customers daily or 15,000,000 ad-supported ones? Which would you rather work on?

The biggest difference is that paid users have a much lower tolerance for bugs and downtime.

This is all about "how do you work in a n-tier multiserver environment". Every developer is comfortable in their own, single-box environment. Not all of them understand the nuances of things like session tracking, when sequential stateless web requests may not go to the same server (or even the same data center).
posted by toxic at 4:11 PM on October 28, 2010 [3 favorites]

I was actually asked to write an algorithm to calculate the prime numbers between a min and a max value.
posted by Ultrahuman at 4:41 PM on October 28, 2010

Many of the questions we ask have many reasonable answers and some totally wrong ones (as an example... What is your favorite langauge: Visual Basic). Show that you have multiple tools available. Ask questions. Wait a second before diving in. If unsure, ask for clarification on what is important: dev time, computer time, clarity, only using free tools, etc. Sometimes the right answer is "code the 80% solution, pay interns to correct the mistakes".

On sql side (assuming you know Postgres, season to taste), know: the impacts of partitioning, limitations of sql (how do you do trees, for example), how to use EXPLAIN or equivalent to understand performance. What is normalization and when should you use it? When should you *not* use it?

Also this recent mefi has links to all kinds of rants about tech interviews.

some links:

two yegge
one yegge



P.s. Renesys' challenge site which I wrote. Basically, do you know the basic unix tools? Can you write a streaming (linewise) algorithm? Also, we are hiring if this doesn't work out, but we tend to like Python/scripting/Unix folk :)
posted by gregglind at 7:46 PM on October 28, 2010