Maybe it's the dogmatic zealotry, but it seems like 9 out of 10 programmers just repeat what they hear to be common wisdom so that they don't stick out like a sore thumb. Who would want to be one of these mythical programmers that cannot program? Who wants to be called "dead weight" and cast out of the group? Who would ever admit to being one of these fabled creatures?
We programmers need to stop being so nasty and elitist. Programming is hard and I'd be impressed if you could write down a working solution to a toy computer science problem you probably slaved over for months in university on a napkin in 10 minutes. You should go on Jeopardy. You'd make a killing. I can't do that; I don't have a mind for trivia. We need to stop entertaining our egos and thinking of everyone as "dead weight." We can all stand to improve the code we write. We should be encouraging one another and learning together.
We don't "interview" people anymore. We "screen" them. I suspect it has something to do with the elitism in the industry as well as the inherent anxiousness and dread of interviewing people you don't know. It's become a terribly broken process, yet it seems precious few people such as the OP realize this.
We could do something about this. Here are some tips I have from my experiences:
1. Know the person's name before they walk into the room. Don't shake their hand as you look down at their resume to figure out their name. At least make it look like you put thought and care into who you invite into your office for an interview.
2. Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. The tools of the trade are debuggers, compilers/interpreters, and text editors. If you want to see how they approach problems, tell them to come prepared with code samples to share or something. Make sure they're aware that they'll be talking about their solution, the tools they used, etc.
One last thing (and a bit of a shameless plug), I think software can be used to ease some of the pain of the hiring process. I'm working on a project to amalgamate meta-data from repository analysis tools and social networks into a single candidate profile that should give you a pretty clear indication of their skills and abilities. The idea is that you should only invite people you are interested in hiring into the interview. To be able to do that you need to know as much about this person as you can and be comfortable that you have an accurate picture of their abilities and work history. The volume of resumes can make this hard... why not automate it?
Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper.
Every physicist can solve first-year physics problems on the back of a napkin.
Every mathematician can solve first-year math problems on the back of a napkin.
Every machinist can sketch her approach to making a widget on the back of a napkin. Electrical engineers can sketch schematics. Chemical engineers can sketch reactions. Architects do nothing but sketch.
Why? Because practice makes perfect: In most technical fields, thinking on paper is an important part of basic education.
Why? Because even at the highest level so much of the most important creative work is done on whiteboards or notebooks or lunch-counter napkins, often in the middle of an impromptu jam session with the smartest peers you can find. My Ph.D. work was mostly involved with machines and materials, but the essential plans and conclusions were sketched out on a set of whiteboards in a series of evening discussions after eating pizza with some folks from my research group. This was completely typical.
If you can't think about programming without electronic help, does that mean you can't think about programming while walking down the street, or showering, or shaving, or doing dishes? If you can't discuss software, even at the oh-so-basic level of an interview question, without a screen and keyboard in front of you, does that mean that you can't design software while eating at a nice restaurant with your collaborators?
If you can't communicate technically in person in real time -- and we're talking really basic stuff, not formal proofs of Euclid's Algorithm or anything -- why should you be hired onto a team? The team can just outsource you.
(In short, yes one should be able to think about programming problems while away from the computer. However, one doesn't arrive at a solution away from the computer. Napkins don't compile.)
Writing code in an interview will tell you one of two things:
1. This person has encountered the problem before and is simply regurgitating the solution they came to when they had four months to work on it and the assistance of a TA and other students.
2. This person has not encountered the problem before.
While the latter case is considered ideal, it only works if you know how to ask the proper questions. I suggest avoiding it because there are more direct ways to get what you want to know.
My suggestion? Code reviews. Have some pre-made examples or ask the candidate to bring their own code. No one has to be put on the spot. It's much easier to control the dialog.
There is no such thing as first year programming problems. At best you provide a simple problem with minimal constrains, but they have nothing to do with professional programming.
PS: What would you do if someone said write a function that will sort these three numbers? Hint: there is no safe answer.
I'd be interested in hearing what you're thinking of -- but if you're right that actually makes it a perfect interview question. The baseline implementation is simple, but you can keep pointing out deficiencies and observe how the candidate attacks the revised problem.
The point of interview coding problems isn't to produces production-quality code with no preparation, it's to gain some insight in the way the candidate attacks a problem, particularly when approaching the edge of his abilities.
At one of the interviews I went through for my current job, I completely tanked on a question that fished for a particular design pattern. But while I didn't figure out I needed to use that particular pattern, I was able to participate actively in the discussion on how and why the solution I chose wasn't optimal.
Simply put based the type job your applying for there is types of solutions they are going to want to see. Without knowing more about the job you may be thinking frameworks while they want ASM.
Of course, but that's not a year one problem. If I say how much energy does a 10kg rock gain falling 50m in a 1G gravity field you can just solve it. However, when handed a simple programming problem the natural instinct is to ask for just a little more information.
I find many programmers have issues quickly context switching between thinking about the problem, discovering what the constraints are, coding a solution, and then debugging that solution. Ask them to do it on a blackboard under a little pressure and they can't do it. The problem is the better programmers often do worse in these situations because they think about more things at each step so they need to keep purging more ideas.
I'm not sure I follow. I seem to remember being given various algorithmic and data structure related problems to solve in 1st year of University - both the implementation and appropriate application of algorithms - that I tend to find myself using as fundamental building blocks in my work. Granted, I haven't had to write a sort function since 1st year, but knowing when to use various approaches to representing and processing data and their limitations is pretty much fundamental stuff.
Problems without safe answers are great. They are infinite fodder for discussion.
P.S. Let's assume, oh interviewer, that your answer to my question "what kind of numbers?" is "integers, for now".
sort(a,b,c) {
exchange(a,b) if a > b
exchange(b,c) if b > c
exchange(a,b) if a > b
return (a,b,c)
}
I think that's probably the stupidest thing that could possibly work, not counting:
<?php
$sorted = sort($unsorted);
Assuming it does work, of course. It may have a bug. Probably does, in fact.
Now you could ask me to find the bug and I'd write out some test cases in the margin. Or you could ask me what happens if a string gets in there, or how I'd generalize this algorithm to N numbers, or what kind of language I'm using with this exchange primitive in it (answer: my own highly arbitrary mental pseudocode!) or how I'd implement the exchange primitive, or how fast this algorithm will run on N numbers (not very; it looks to be O(N!), and that's not counting the fact that my exchange primitive is probably wicked slow).
Or, depending on the job, you might head in some other direction.
My point is there is no default correct answer to that type of problem. In physics there are default approaches based on ignoring wind resistance etc. However, in computing knowing which questions to ask is the real test and they don't teach you that in your first year.
EX1: You wrote code before asking for more details you fail.
EX2: Then again some people view asking questions as stalling.
Perhaps they are thinking about sorting a vector and want you to use the the language library of your choice or write something. Or perhaps they want a few lines of ASM that include at most 2 swaps and:
x = x xor y
y = x xor y
x = x xor y
But if it's a high level ASM then you may have XCHG etc.
EX1: You wrote code before asking for more details you fail.
EX2: Then again some people view asking questions as stalling.
This is interviewing, not a mathematics competition or a judicial proceeding. It's not a test, it's a first date.
If your interviewer applies either of these rules so strictly that you "fail", you probably don't want to work for them...
...unless you really are the type of person who wants a work environment where such rules apply strictly, and you happen to have the same ruleset as the person who is interviewing you. In which case the two of you may work together very well, and the interview will be a big success.
The first rule of interviewing is: Although one of you is leading, and one of you is following, you are interviewing each other. It's a conversation. If I start out answering your question on a track that you don't want to follow -- integers and not vectors, Lisp but not ASM -- you need to lead me in the right direction, just as you would do if we were discussing a real problem. Your ability to guide the conversation, and my ability to follow, and our resultant ability to establish a rapport and keep the conversation moving, is what is under test here. The problem itself is far less important.
P.S. I have seen that XOR trick before, once, but it still blows my mind. I can never understand it without spending half an hour in a corner muttering to myself. Is there a field where that trick is so idiomatic that it's a reasonable thing to expect a candidate to come up with it an interview?
Yes, ultra low power embedded computers. 2 years ago a friend was working on a 32khz 8bit cpu with 384 bytes of ram and 2,000 bytes of ROM. The problem may have been simple but he setup multi tasking so he could do some networking while still keeping track of some other things and manual error correction because the memory was being flipped in the field. Basically, it needed to operate for years in a remote location on the power output of a watch battery and when your putting a million of the things in the field better code wins out over better hardware.
PS: In the end he still he still had 12 bit's of unused memory and in his words "you can do a lot with 12 bit's of ram".
In my experience thinking is nigh impossible with your hands on the keyboard. Thinking happens in the shower, or with a pen in your hand and a sheet of paper in front of you, or in a conversation.
Here's a homework question that I got last week:
Two numbers x and y in 0..50 with x <= y get selected. Bob gets told x^2+y^2, Alice gets told x+y. Alice and Bob have the following conversation:
- Bob: I don't know which numbers x and y are.
- Alice: I don't know which numbers x and y are.
- Bob: I don't know which numbers x and y are.
- Alice: I don't know which numbers x and y are.
- Bob: I don't know which numbers x and y are.
- Alice: I don't know which numbers x and y are.
- Bob: Now I know which numbers x and y are.
Question: which numbers can x and y be?
If you're able to solve this problem by firing up your editor and starting coding the 10 lines of code required to solve it I'd be very surprised. Hard problems require real thinking.
Maybe my thinking is a bit slow here, but can't you even only begin to hope to answer this question if you assume Alice and Bob are cooperating in some fashion?
It's a very awkwardly phrased recursion problem. The point is to find a unique x, y where x <= y. The algorithm starts with the set of all possible (x, y) pairs, and switches between the Bob and Alice stages.
In Bob's stage, eliminate pairs that give a unique value for x^2 + y^2. If such a unique value matches the value Bob was given, then obviously you know x, y for sure.
Otherwise, switch to Alice's stage, which operates on the remaining pairs from Bob's stage, and eliminates all pairs that give a unique value for x + y.
The weirdness in the question is both Alice and Bob are performing the exact same algorithm, but (to use CSP parlance) there is a channel from Bob to Alice in Bob's stage, and vice versa, due to the different information given to both parties. Alice must wait for Bob to declare if the algorithm has terminated or not.
I don't think the algorithm you're proposing works, although that was my first idea as well. And I don't a priori see why the pair (x,y) would have to be unique (but it does appear to be, even if instead of choosing x and y in 0..5 you choose from all natural numbers).
Well, it is assumed they are speaking the truth, and it is assumed that they are good mathematicians (i.e. if they could know what x and y are at some point, they would know).
The idea is that if Bob says that he doesn't know what x and y are, then Alice can deduce some things from that, because she knows for which x and y he would know what they are. For example, after the first time Bob says he doesn't know Alice can deduce that x=1 y=1 is not the solution, because then Bob would know (because Bob gets told 1^2 + 1^2 = 2, and 2 = x^2 + y^2 implies x=1 y=1).
That's a similar puzzle. Maybe it's because I solved the homework puzzle first, but the blue eyes puzzle is much much easier. You might want to try to solve that first ;)
The cool thing about the blue eyes puzzle is that you can solve it without a computer or pen and paper.
If I ask a physicist to sketch out a solution to a problem, I'll be willing to accept that they may need to look up some constants or formulas along the way, because knowing how to attack the problem and memorizing a bunch of numbers are two very different things; the latter is useful from time to time, but it's the former that I care about if I'm interviewing you.
Why, then, do so many interview processes assume that the ability to, essentially, vomit rote-memorized bits of syntax, argument orders, etc. onto a whiteboard is so important that any "real programmer" should be able to do it on command?
See Tim Bray doesn't know operator precedence rules. It's perfectly possible to live and work and thrive without memorizing everything. This is what being an engineer is all about. Yet the FUD that goes into interview & recruitment processes (as well as other aspects of a programmer's work, but that's a longer story) is astonishing.
If you're talking pseudo-code, I'd agree. And I think all these various sketches you're talking about are comparable to psuedo-code. Those sketches aren't going to tell you exactly what PSI some escape valve needs to blow at, or what temperature a reaction is going to run at, etc.
If you're expecting me to write out code that can be ocr'ed and compiled, which is basically what most whiteboard tests expect, I'd disagree.
I failed one whiteboard test (C#) because:
(a) I didn't know the formatting for Console.WriteLine off the top of my head, because who the hell uses that when writing an app anyway?
(b) Because I didn't check the List<int> parameter too see if it was null, even though I did handle an empty list correctly.
With the whole interview thing going on, I didn't even argue point (b), there was too much going on. On the way home I was thinking about it, and as a design decision I actually would've just let the function throw a NullPointerException. No specification was provided to the contrary. Should I have wrapped it in a FooAppException, java-style? Or just silently done nothing even though the inputs were invalid?
I would expect any programmer would be able to write a program on paper.
I wouldn't expect it to be perfect or even compilable, just the same as a widget or schematic. Physicists and mathematicians have an advantage in producing 'perfect' things on paper, because they 'solve' where the other examples you gave 'develop'. They work in the other direction; the mathematical pursuits analyze systems whereas you have asked the other pursuits to create systems, which is much more difficult on a piece of paper.
Now, if you had the designers working forwards- analyzing code or schematics or widgets- then I would expect an accurate answer (with a little fuzz for basic mistakes, same as I'd give a mathematician slack for accidentally dropping a minus sign)
While you're absolutely correct, it's worth noting that for most of the disciplines you mention, the actual work takes place on paper too. A mathematician, physicist or engineer will spend most of his working life scribbling on paper, so it makes a lot of sense to interview that way.
There are plenty of other fields that don't work quite that way.
You wouldn't interview a baseball player by asking him to describe hitting a curve ball on paper, or a nurse by asking him to draw stiches on a piece of paper. Every field has its own medium of expression. For many fields, that's paper. For programming, it's a text editor.
2. I mostly agree. However, if you are applying for a position at a company that specializes in program languages or program analysis, then I disagree. These applicants should be sophisticated enough on the topic of programming languages to be able to code on a whiteboard.
College undergraduates: If you want to do well in interviews, especially ones that involve whiteboard coding, take or audit a graduate course on programming languages and pay more-than-average attention. Your code will be better, especially in rarely encountered (and thus poorly understood) corner cases. And you will interview better.
Rather than simply speaking broadly, here's a very simple example of when I would expect someone who is sophisticated on the topic of programming languages to excel over applicants who are merely practitioners. (In practice, I actually do see this fairly frequently.)
Both C++ and Java provide "dynamic dispatch" as a language feature. However, by default, C++ does not use it; by default, it uses "ad hoc polymorphism" on the static types of its arguments, including the argument passed as the implicit this pointer. In order to enable "dynamic dispatch", the member function you want it applied to must be decorated with the "virtual" keyword.
If someone is able to reason at the level of "dynamic dispatch" and "ad hoc polymorphism" and how to activate these features, s/he should be able to write correct, OO code on a whiteboard. However, if s/he is not formally trained in programming languages, while this person may understand this on some level in practice, s/he may under pressure lose this distinction in whiteboard code, particularly if there is no test environment available.
I don't honestly believe that anyone who has done OOP in C++ has never run into this, so I chalk it up to lack of formal training on programming languages. And while this person may not be appropriate for a company that requires sophistication on the very specific topic of programming languages, this person may be appropriate for another.
I have plenty more examples, but this is a simple one that I think illustrates my point for most people.
On a side note, becoming somewhat formally trained in programming languages, whether or not this is the field of computer science you are interested in, allows you to easily pick up powerful languages, such as Scala, which some people are apparently unable to pick up.
I would consider this to be a pretty fine-grained differentiator in who you want to hire however. The formal training aspect gives you the name of things, but it doesn't make you better at reasoning in general. Given the choice between the faster, smarter thinker and the guy with the more specific domain and terminology knowledge which would you hire?
Must I choose? May I choose the smarter, faster thinker with domain knowledge? :P
I do not think domain expertise should be marginalized, especially when the domain is deep. Someone who is smart and fast but who has only ever thought in Spring and Hibernate isn't going to be able to start collapsing strongly connected components in call graphs. There is far too much distance between a blank slate and being able to do that effectively.
And how can a person who is able to achieve mastery of a particularly difficult domain be unintelligent? Truly becoming a master at something is a rare trait. I read in _Coders at Work_ that Ken Thompson, the inventor of Unix, looks specifically for the ability to acquire mastery: He picks an item on the candidate's resume, whether or not he himself knows anything about it, and proceeds to grill the interviewee about it. He reasons that, if the candidate is unable to convincingly convey mastery to someone who is entirely uninitiated to the topic, then how can this person be an effective programmer and team mate (at Google)? On the other hand, if this very same tactic actually sets the candidate off -- that is, the candidate starts waxing romantic about the topic while deftly dispatching any technical concerns -- then not only will this person be effective but this is someone who will be a pleasure to work with.
BTW, I believe that knowing the terminology is of only secondary importance. Its purpose is to effectively verbalize fine distinctions to team mates and often serves as a marker for greater sophistication. (Note that plenty of people throws terms around _incorrectly_, often very much so; I am specifically not referring to these people.)
Maybe it's the dogmatic zealotry, but it seems like 9 out of 10 programmers just repeat what they hear to be common wisdom so that they don't stick out like a sore thumb. Who would want to be one of these mythical programmers that cannot program? Who wants to be called "dead weight" and cast out of the group? Who would ever admit to being one of these fabled creatures?
We programmers need to stop being so nasty and elitist. Programming is hard and I'd be impressed if you could write down a working solution to a toy computer science problem you probably slaved over for months in university on a napkin in 10 minutes. You should go on Jeopardy. You'd make a killing. I can't do that; I don't have a mind for trivia. We need to stop entertaining our egos and thinking of everyone as "dead weight." We can all stand to improve the code we write. We should be encouraging one another and learning together.
We don't "interview" people anymore. We "screen" them. I suspect it has something to do with the elitism in the industry as well as the inherent anxiousness and dread of interviewing people you don't know. It's become a terribly broken process, yet it seems precious few people such as the OP realize this.
We could do something about this. Here are some tips I have from my experiences:
1. Know the person's name before they walk into the room. Don't shake their hand as you look down at their resume to figure out their name. At least make it look like you put thought and care into who you invite into your office for an interview.
2. Don't use a white board or a pad of paper. A select few eccentric programmers have ever actually sat down and wrote out a program on paper. The tools of the trade are debuggers, compilers/interpreters, and text editors. If you want to see how they approach problems, tell them to come prepared with code samples to share or something. Make sure they're aware that they'll be talking about their solution, the tools they used, etc.
One last thing (and a bit of a shameless plug), I think software can be used to ease some of the pain of the hiring process. I'm working on a project to amalgamate meta-data from repository analysis tools and social networks into a single candidate profile that should give you a pretty clear indication of their skills and abilities. The idea is that you should only invite people you are interested in hiring into the interview. To be able to do that you need to know as much about this person as you can and be comfortable that you have an accurate picture of their abilities and work history. The volume of resumes can make this hard... why not automate it?
Just sayin'