Typical programming interview questions.

Github (and similar evidence of actual abilities) are already making questions like these extinct, thank god. Reading through a single project an applicant has written themselves is <i>immensely</i> more informative than these silly CS brain teasers: actual solutions to actual problems, style &#38; documentation habits, testing practices, evidence of being able to code &#38; ship, being a self starter, etc... Classic example of actions speak louder than words. Thankfully the technology is now in place so that resumes can be replaced with coding community profiles, and interviews can focus on filling in the blanks and assessing the compatibility of the applicant as a person.

<i>You may be asked about using Unicode strings. What the interviewer is usually looking for is:<p><pre><code> - each character will be two bytes (so, for example, char lookup table you may have allocated needs to be expanded from 256 to 256 x 256 = 65536 elements) - that you would need to use wide char types (wchar_t instead of char) - that you would need to use wide string functions (like wprintf instead of printf)</code></pre> </i><p>Unicode support involves more than just the minimum number of bits used per character.<p>Say you're writing a method to truncate a string to a certain length. What if your text contains a code point outside the basic multilingual plane, and each character can't be represented in just 16 bits? If you truncate in the middle of a character, the result will be an invalid string. What about combining characters? If you truncate in the middle of a combining character sequence, you'll end up with half-formed output (e.g., letters missing a diacritic). If you work with text, you should know this stuff!

I think a lot of these questions don't really reflect what someone will be doing in their real job. It's more of a "how much do you remember from your CS degree" test that has little relevance to your job duties of maintaining some monolithic Java based enterprise platform.<p>I mean come on, Binary Trees? I know what a Binary tree is but I'd have to look up the definitions of all the traversal types because there's no way I'd be able to remember what Post/Pre/In Order traversals actually entail.<p>And this question is an absolute abomination: -<p><i>What is the next line in the following sequence:</i> <i>1</i> <i>11</i> <i>21</i> <i>Answer: it's 1211 and the next is 111221</i><p>That's a joke right? I'd personally answer 31 to this question.

<i>"You have 2 supposedly unbreakable light bulbs and a 100-floor building. Using fewest possible drops, determine how much of an impact this type of light bulb can withstand. (i.e. it can withstand a drop from 17th floor, but breaks from the 18th). Note that the ever-popular binary search will give you a worst case of 50 drops. You should be able to do it with under 20."</i><p>Maybe there's something I don't understand, because my reaction to that question was "lolwut?"<p>In that scenario, with a binary search you drop from the 50th, 25th, 13th, 19th, 16th, 17th and 18th floors.<p>By my back of the postage stamp calculations you need to do (log N) + 1 drops...<p>My question: how did they get a number of 50 for binary search??? Is it because you're limited to 2 failures? And by 'binary search' they mean something like start at floor 2 and drop, if it is still intact go to floor 4 and then drop it, if it breaks you don't know about floor 3, so you have to use the remaining one to check that. That's not <i>binary</i> search, that's <i>linear</i>.<p>To do it in 20 or less drops you could drop it from the 20th floor, and if it smashes, go to floor 1 and start going up in increments of 1. Otherwise go to floor 39 and drop it (etc). But that makes me think it is not the best for that starting number, we can do better. Just pull out the good old (n^2 + n)/2 formula again and the first one in that progression that ticks over the 100 threshold is 14. So we drop it at floor 14 first, if it breaks then start from floor 1 and go up. Otherwise go up 13 floors and repeat...<p>Our major floor increments are 14, 27, 39, 50, 60, 69, 77, 84, 90, 95, 99.<p>I'm not sure if there is a better solution, if you have one, feel free to chip in. :D

I HATE interview questions that ask the candidate to write some trivial piece of code. Particularly the ones that need to be written in C to give an optimal answer "if you just do pointer math, this would be trivial..."<p>Not to say that some good candidates won't be excellent at C coding, but these problems often test for specific knowledge, when they should be screening for critical thinking skills. I've seen candidates who were "good" at this sort of problem (probably because it was on a CS homework in College), but didn't have much in the way of critical reasoning skills.<p>I prefer asking questions that require them to devise some sort of algorithm to solve a problem (typically by walking through the situation methodically), and then implement that algorithm in the language of their choice. No real ahas or tricks, and I don't care if you write it in Python or Assembler...

These questions remind me of the time when I took AP Computer Science AB, many years ago (10 years ago to be exact Freshman year). To be honest, many of these concepts are good to know, but I find a much more useful test is to test them on something that they probably haven't used before, especially a technology that you use in your project.<p>For instance, our project uses a good deal of Jabber, so we test our applicants if they can write a program to act as a bot responding to the Jabber message "ping" with "pong." It tests their ability to develop rapidly and to justify their choice of a library and how fast they can pickup our technology. It's been a great filter as well as a useful test to see if they can assemble a solution on their own. Even non-working solutions work well for us because we can examine their thought process.<p>Asking them to develop a sort solution isn't useful for us as much as seeing if they can develop code relevant to the components we use--because, let's face it; you aren't going to be writing your own string class from scratch, but it is good to know how one works. And in our case, they'll learn about XMPP/Jabber if successful--and it will test to see if they are willing to learn. Seeing which library they use is also interesting, because it tests their system design skills, and in some cases, will indicate if they can make good design decisions. But if we do have doubts about them being able to assemble a program, we will test them <i>computer science</i> questions, but in the meantime, we want to see if they can <i>engineer</i> a solution.<p>But if you are looking for a low-level programmer to develop you a compiler from scratch, maybe these are the right questions to ask. But we don't expect our applicants to build a hammer; we want them to know how it works, but we don't expect them to build us one. I guess if we need a hammer maker, we will find one, but if we need an applications programmer, we will have them use the hammer. Just like your engineer knows how a spectrum analyzer works, but won't be expected to build one. Unless you are hiring them to do that.

From the link:<p>What is the next line in the following sequence: 1 11 21 Answer: it's 1211 and the next is 111221<p>Why would 31 and 41 be illogical answers? I understand where 1211 comes from, but 31 and 41 are totally logical IMO. It's a linear function that goes up by 10.

I'm surprised that these are commonly asked and I'm guessing these aren't for a position building web apps.<p>Most of these are distant memories from a CS degree and rarely used concepts in the word of y-combinator startups where Ruby and Python are common.<p>I think people building web apps look more for developers who write maintainable code, design good user interfaces, write good tests, make cross browser solutions, etc.<p>These would be nice to have but too low level for everyday use at most startups.

At top-tier software companies, expect all of the (applicable) questions to be accompanied by the "and what is the runtime complexity of your solution" followup question. Depending on your abilities, the interviewer will try to lead you towards an optimal solution.

What sort of programming positions?<p>I've done a fair amount of web development in PHP &#38; Python (as well as introductory C++ &#38; Java). I had to look up "linked list" on Google just to get some understanding of what that is.

"You are given an array with integers between 1 and 1,000,000. One integer is in the array twice. How can you determine which one?"<p>Sum(Array) - 1000000<i>(1000000 + 1)/2 = X<p>For the other part it's just<p>1000000</i>(1000000 + 1)/2 - Sum(Array) = Y<p>EDIT: n*(n+1)/2 is the formula for the sum of the numbers from 1 to n

&#62; The interviews were pretty evenly split between very large, large, and startup-sized tech companies.<p>Really? One person is looking for a job in a big company or a startup?? One of the most common programmer interview questions is <i>What type of job are you looking for?</i> I suspect that "Oh, I don't know, maybe cubicle dweller in BigCo, but then again a startup might be fun" is not the best answer, and describing each company as being your ideal destination is dishonest.<p>Then again, another possibility is that he looked for a startup job, and when he couldn't find the right spot he tried some medium sized companies, and so on. That might make sense in an interview: "I was really interested in exploring a startup, but when I actually looked into it I realized it was far more romantic in theory than it was practical. I like the idea of writing great software, but it turns out that the companies I met with aren't very committed to some of the best practices that interest me."<p>So I won't jump to conclusions about the OP, but certainly I am interested in hearing what chain of events led to what appears to be a wide spread of environments.

This is a great resource but lists like these without the accompanying answers are always frustrating to me.<p>I would like a way to be able to check that I am right.

If I were given questions like these, I would politely refuse to answer them explaining they have nothing to do with the important things a typical software developer does.<p>Having a solid portfolio of past successful projects to demonstrate your abilities (including participation in a open source development) is way safer than being able to solve artificial problems.

There is a lesser known variation of "find a cycle in a linked list". Given a function<p><pre><code> int f(int arg); </code></pre> that returns a value computed solely from <i>arg</i>, find the length of the repeating sequence in<p><pre><code> f(x), f(f(x)), f(f(f(x))), ... </code></pre> The primary use is determining the period of a state-less PRNG such as a linear congruential one.

The bottom line here is that though today's interviewers' repertoire is a little bit different, it only takes a small practice to excel in the questions they ask. Author seem to make the same point.<p>Usual comments from "ninjas" in this thread are very amusing though.

These sequence questions drive me up the wall. It's so unbelievably stupid that out of the near infinite functions that can produce a given list you should come up with the one the interviewer thought was the "obviously correct" one. The sequence in the example: 1, 11, 21, x ... with the information given then the X=31 is just as valid as anything that the interviewer came up with.

All this is still useful. I have to fix code all the time where the original developer paid no attention to complexity and a algorithm that was fast with the 10 items they tested with is dog slow once it makes it to production and there are 10,000 items.

I also recommend the book "Programming Interviews Exposed", it contains the absolute minimum every software developer must know about...

Well, I feel pretty stupid now.