I understand where the author is coming from because many interviews questions are unreasonable and test absolutely nothing.
However, if someone couldn't code a linked list on a whiteboard, I'd be severely worried. Same goes for a binary tree. If you know what a linked list or binary tree is, you should have no issues figuring out how to represent them with code in 10 minutes.
The other trickier problems are there to test problem solving ability, which I believe is a valid thing to test.
I think the reason for this style of interview is that companies are afraid of false negatives. They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified.
Additionally, swearing all over the place never helps your case...
They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified.
And then they complain that they can't hire developers.
I don't think these types of interviews are well conceived. Human memory is extremely context dependent and a whiteboard/interview type situation doesn't establish the right context for someone who's accustomed to working alone with a mouse, keyboard and compiler.
Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. So these types of interviews might be good at selecting people who know all about linked lists and binary trees but not much else.
I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
Well I know that I've solved a few problems in my time: like developing a multi-threaded distributed object-oriented control system, implementing a JPEG2000 encoder, a convolutional neural net, as well as solving a number of debugging problems that escaped my colleagues.
I also know I failed miserably at a trivial coding task in an interview.
So I don't know. If I'm the only one who has that kind of problem, maybe my brain works differently from other people's.
How trivial? What was the task, then? And what where the conditions? Were you required to remember some nitty details? In an interview, you can fail in almost anything, depending on how nervous you are.
The problem was: given the following prototype implement the function
void move( char** colNames, int toColumn, int fromColumn );
The function should move the column name at index fromColumn to the position toColumn. (It does not swap the columns.)
Now I just spent 43 min implementing this with a compiler and some trial and error.
During the interview I was expected to do it with pen and paper.
Now my IQ is above the 99th percentile but apparently there are people who can do this sort of thing in their head without errors and that's what some interviewers appear to be looking for. That's why this post hit home for me, though personally I probably wouldn't have had much trouble with linked lists.
I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple fix, it also says nothing about the logic in the code.
Unless I've needed a specific language, like SQL for example, anytime I've asked a candidate to code on the whiteboard pseudocode has always been fine.
What makes you think it was held against you? Most programmers can be kind of OCD about code and would want to point out that kind of error, whether they thought it was relevant to your abilities or not.
Code on the whiteboard is counterproductive at best.
Let's hook up your laptop to the projector so I can get a glimpse of how you interact with your computer. I learn more about you by seeing your relationship with your text editor, how you look up information you can't remember, etc. Not watching you sweat with a marker in your hand.
well a programmer that is coding a linked list in c/c++ probably(definitely) should know the pointer semantics. If they are looking that up then they should be a pass unless you are looking for a really junior programmer. Now if you are asking them to connect to a db and update a record with a stored procedure and they looked up the syntax for a db connection to a mysql database then you know they are fairly proficient at that type of coding but just forgot the exact syntax of a db connection because it's not something done every day whereas any c programmer worth their salt should know basic pointer rules.
Any language I have not used for a while get’s tossed out of the buffer, and I need to lookup even the most basic of syntax when I start coding in it. Once I get going I can easily recall if it’s *, &, ->, or ^ but at the start I really do need a refresher.
PS: Oddly enough, I have little issue working on a multi language programs, it's just I think in terms of pointer not C pointer.
My laptop is for reading email and surfing the web in hotel rooms. Occasionally I program on it when I don't have a choice, but I'm far less productive than on my regular workstation, both because of the ergonomic problems and because I haven't invested the time to set up all my usual software the way I like it. (Am I a dinosaur? Does everyone else have a laptop as his primary machine these days?)
As a college student I have noticed many of my peers have to make the choice between a desktop and a laptop. The laptops often win because of their ability to be carried to classes and to collaborate with peers. Having a whiteboard to collaborate on at school and a computer right there to program on afterwards is very nice.
However, if someone couldn't code a linked list on a whiteboard, I'd be severely worried. Same goes for a binary tree. If you know what a linked list or binary tree is, you should have no issues figuring out how to represent them with code in 10 minutes.
The other trickier problems are there to test problem solving ability, which I believe is a valid thing to test.
I think the reason for this style of interview is that companies are afraid of false negatives. They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified.
Additionally, swearing all over the place never helps your case...