I actually like to give a problem that we just recently solved as a takehome test. It's by definition representative of what I need them to know, and since I know "an answer" it helps to see if they come up with a far more elegant or more kludgy way of doing it. As for timed on-site coding tests, if that's representative of how the company's devs work, then why the heck would anyone want to work there? If it's not representative of how the company's dev's work, then why the heck would anyone want to work for a company that tested applicants using something that was completely non-representative of how their dev's actually work? If you're self-taught and trying to break in it might be a necessary evil. Otherwise it says a lot about what your future work conditions will be like, and not much of it good.
I've been asked a lot of questions in programming interviews, but by far the most interesting one was the "two eggs" question. You have two eggs -- both are exactly identical in every way. You are in a building with 100 floors. Your job is to find which floor of the building is the highest you can go before the eggs would bust when hitting the ground. Remember, you only have two eggs, so if you go to floor 50 first and drop the first one and it breaks, you have to start at floor one with the second egg and keep moving up a floor until you find the floor where it breaks. So the worst case scenario in this situation would be having to test every floor until you get to floor 49. The absolute worst case scenario would be starting on floor 100 with the first egg. The goal is to find the most efficient method of testing from various floors to find the solution with the hypothetical least amount of tries necessary to find the exact floor where the eggs will break. I found this puzzle to be really enjoyable because the optimal solution isn't intuitive at first but once you work the problem, it's a lot of fun to discover the answer yourself. Also, the purpose of giving someone this type of problem isn't necessarily a pass/fail to see if they discover the optimal solution, but to work through it with them a bit and learn how they approach problems and how they would work as a team to solve them.
As a tester, having to test all floors in sequence sounds like fun fun fun! And you get to keep one egg!
SPOILER ALERT - DO NOT READ IF STILL PLAYING WITH THE PROBLEM I must be missing something, it seems obvious to start on the 2nd floor, drop an egg, if no break go to the 4th floor, repeat every 2nd floor until a break and then drop down one floor as the final test. Just under twice the speed of testing every floor from ground. Since I am old, and this seemed obvious, I presume I am missing a more elegant modern solution. EDIT: Stupid me ..... go to every 3rd floor yields a faster result. Now I feel better that there was in fact a less obvious solution that needed more thought. Edit #2: Duh .... break the building into fifths and attack each section of 20; top floor of the section eliminates or includes that section then floor by floor from the bottom of that section .... better ... there must be an optimum height for each section, but good enough for me for tonight. It does remind me of the story of a physics exam where the question was to explain how to calculate the height of a building using a barometer. A young wag answered; "throw the barometer off the top of the building, time the fall until the f#$@#%g thing hits the pavement, apply the formula d = 1/2 gT2 (can't do a superscript 2).
Worst case scenario here is that the egg actually breaks on the 100th floor and this method would have taken ~ 49 attempts. The optimum solution to this puzzle is around 30 less than that. (But I see where you're coming from and it's a good start!)
That's what I was thinking. Go to every other floor. FWIW, I work with a guy who specializes in these sorts of word puzzles. Apparently he is very active on a site that poses these sorts of puzzles. Google stalked him there and wanted to fly him out for an interview. He declined.
I'm in charge of development for a small company (< 100 employees). Last year some time I was given the OK to hire some additional devs for my team. It can be difficult to know if someone is just a good interviewer or actually knows how to write code. I also understand the problem with asking for specific algorithms like bubble sort because who really remembers? I mean I understand different sorting concepts and could write algs for different style of sorts, but without looking it up, I don't remember what exactly bubble sort is. If you tell me what it is, I could write the alg of course, so I didn't want to have a quiz that would fail people for something that could easily be looked up. I just wanted to know they can understand basic logic and can write simple code. So I decided to make a short quiz. Just a few 1 sentence answers required. Some were multiple choice. Some were read these 3-5 lines of code and tell me what gets printed (really simple, straight forward lines -- if you could read the language you should be able to answer them in about 10 seconds each). Nobody was passing my quiz, the CEO told me to simplify it. This happened a few times. Eventually I only asked people to write code to print the first 100 digits of the Fibbonacci sequence. I wrote out a description of how to calculate it (in english) as well as gave the first 10 numbers as an example. I had about a 10% pass rate and was told I was doing a poor job interviewing because my tests were too difficult and I had to use a 3rd party testing service instead of my quiz. I Just wasn't getting very good candidates. From this thread it sounds like perhaps that's the norm, but I basically got the decision of who to hire taken from me. Fast forward to now, those devs that were hired aren't working out. I'm tired of dealing with the fallout of having incompetent devs that I'm responsible for, but aren't allowed to replace (and didn't want to hire in the first place). As such, I'm considering looking for a new job, but what's holding me back is these dev quizzes. I understand why quizzes exist from the perspective of an interviewer, but I dread the thought of having to do them as an interviewee. I definitely understand the OPs concerns. I've not had to interview for 12 years (when I graduated), and back then I knew algorithms by name. I don't know very many by name anymore. I would definitely prefer an interview with questions like the 2 egg problem posed in this thread.
Start at floor 1. If egg busts, game over. If not, go to floor 2. If egg busts, game over. If not, go to floor 3. .... but maybe every other floor would be more efficient. But you definitely want to start on the lower floors, ones less likely to bust.
For people looking for a good explanation on how to get the solution: http://datagenetics.com/blog/july22012/index.html
The truth is that finding a "good" programmer is REALLY hard. A good programmer to me is someone who: 1) Is willing to follow established company guidelines on source control and code structure even if it doesn't agree with what they've done in the past (although I'm happy to discuss changing them if the logic is sound). 2) Someone who is an abstract problem solver. Stackoverflow is a great resource to how to do things, but not necessarily the why or when you would use them. A good programmer would know when to use certain in-memory data structures as opposed to writing to disk -- when to write it to disk, etc. More importantly, when to optimize code and when not to (and where to optimize -- low hanging fruit). Personally, I don't care if you don't remember the syntax of writing a bubble sort, but I'll be extremely impressed if you can tell me when a bubble sort might not be as good as insertion sort or quick sort, etc. 3) Dependable -- can pull the hours when a big project needs them, etc. Frankly, I don't care if they work from home or from a strip club as long as they can excel in whatever environment works for them. 4) Leadership qualities -- the best programmers aren't just programmers, but can understand what a company is trying to do on a high level and accept a lot of that risk/reward themselves in what they do by doing whatever is necessary to give that company the competitive edge. That brings me to what a lot of company's do wrong. Your boss thought your interview was bad, but honestly, if a programmer can't figure out how to write the first 100 digits of the Fibonacci sequence, I'm not going to be really thrilled. It's really hard to find good talent -- and that's why the good talent can demand six figure incomes. If you find someone good, treat them like an adult. Good programmers are a rare breed. I like to work late at night listening to music -- so I'd appreciate some time away from the office to do that. A company would respect good talent and give them a lot of flexibility (Time off, remote options, working at the coffee shop down the street, etc.) Yes, I understand some meetings are mandatory and I'm happy to be there for them, if you're happy to let me do my think if I bring you results. I don't think a lot of company's understand this about programmers. Honestly, if you are trying to find a "good programmer," you might have to phone screen 100+ people. Think about that for a moment -- that's a huge time commitment just for phone screens if each runs 10 minutes. That's over 15 hours and no one has even walked into the door for the bigger interview. My phone interview test consisted of "categories" of questions with each category having two questions. If you could at least get one question right, I'd move to the next harder category. Most of the candidates failed at the first category with questions like (I shit you not), "Tell me ONE difference between Linux and Windows." The *hardest* category would have questions like, "Which data structure would you use to retrieve a value in O(1) time -- a hash or an array?" If they made it to that level, they were probably coming in for an in-person interview at that point.