It certainly sounds like the author doesn't think there are any actual incompetent engineers out there.
Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.
Look at past experience, and ask the candidate to talk about that experience to verify that they aren't lying.
If someone has 5 years experience working at Google, and they can talk coherently about technical aspects of the projects they worked on, there is no reason to ask them to code on a whiteboard.
The way it currently works is this: I see you have a CS, degree and 10 years experience at a well known company. Excellent. Now you have 2 eggs and a 100 story skyscraper. Tell me the minimum number of egg drops you'll have to perform to discover the minimum height that will break the egg.
Every engineer no matter how experienced has to answer questions like they just left school yesterday, no other industry does this.
>Personally, I know that to be false. I have worked with incompetent engineers, who literally couldn't code FizzBuzz.
99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.
I always argue for this, and about 98% of the time people look at me like I'm sort of crazy man and our company is going to go down in flames. Everyone has an anecdote, "well, there was this one time ....", yet I'm convinced that there's roughly 0 real value add from all of the hoops and hurdles most interviews provide in terms of accurately identifying strong candidates.
I always try to make the argument that if someone can talk intelligently about a wide range of programming knowledge in an actual conversation - for instance, knowing that data type X would be a logical segue from the current point, and do that throughout the interview, personally I think the likelihood of them being an idiot are slim. However, most people I argue this to are always afraid of this, afraid that some interloper will sneak through unless we put them through a gauntlet of questions regarding things they'll never do in their day to day life.
Like make a table view that has word counts for a string. Or make this simple puzzle game. Or make a simple address book app.
My current opinion on this would be to offer a laptop so you aren't disadvantaging candidates who don't have one too badly, but let people use their own if they have one (and let them know ahead of time that it will be an option and what they should be set up for.)
In the past, I've used CollabEdit for "phone screens" and the whiteboard for in-person interviews. I try to ask some "coding" questions (identify a better data structure / algo for a particular scenario and then implement it in code) and some problem-solving conversational questions. Seems to work pretty well, but I'm always on the lookout for better approaches. Part of the problem is that the software field is so broad that it's hard to get a sense of a person's abilities with such a limited amount of time to ask questions.
Would you rather a laptop w/ standard editors and IDEs or would you prefer a google doc, collabedit or a whiteboard like many places do?
Moreover, if you're that useless without your dual monitors and a full-size keyboard, would a whiteboard-based interview be any better?
Could you use this specific scenario to view how the candidate would react? If he starts to complain that the right tools are not on the laptop, or he is unfamiliar with environment, does it is signify that he is focusing too much on the tools rather than on solving the problem?
Maybe his time management skills needs some work, ie limited time to solve the problem and too much time worrying about environment.
However...
99 times out of 100 you could catch that engineer by talking to him about technical aspects of past projects he worked on.
That does not work for us.
We must put each and every candidate in front of a keyboard, and bang out at least a little code.
We had one candidate, recently graduated with an MS in CS. Nice personality, good talker in general. The candidate seemed to understand CS and could explain how to solve problems.
However, even with repeated prompting, I could not get this person to even type in a loop to start to solve the problem presented.
We've interviewed multiple candidates with a BS in CS or similar who also spectacularly failed at doing even basic coding tasks.
Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.
>That does not work for us.
How do you know, did you try it? I said 99/100, sure there are some rare people who may slip through, but there are people who slip through a coding challenge as well.
How do you know that your coding test is better at detecting secretly terrible engineers than talking through past projects (for experienced engineers)?
>Some people are really great talkers. They really do sound like they know what they are doing. But that does not mean they can actually do anything.
That's sounds like a problem with the questions you're asking. Some people can throw out buzzwords and talk at a high level, but if you really dig down into the implementation details of project you can weed those people out.
A degree is not experience, CS != programming.
So we end up asking them all those sorts of questions.
Going through a CS degree without learning to code is easy. Depending on your CS course you may hardly have touched any code beyond extremely entry level courses where you're being hand-held the entire way, if you pick the "right" subject.
CS is not software engineering.
Similar with internships.
For both those situations, I can understand that you want to verify ability to actually write code.
What you seem to be implying, is that this is obviously true for graduates, but couldn't possibly be true for people with real experience. (But your implication has no evidence to support it)
Exactly why do you believe that it is completely plausible for a recent CS graduate to be able to explain the technical details of their final year project when in reality they contributed zero code to that project, yet it is entirely implausible for someone with 3 years experience to be able to be able to explain the technical details of their most recent development projects when in reality they contributed zero code to those projects?
Here is problem. It's not entirely implausible, just very unlikely.
The type of interview I'm talking about isn't going to catch every single bad candidate just the vast majority. But whiteboard interviews don't catch every candidate either and they have an extreme amount of false negatives.
To your point about students, they have much less work experience to talk about. The point of the interview is to look at their experience and talk about it to verity they aren't lying. In most cases the student doesn't have enough experience to tell me anything.
That being said, if a student can talk me through technical implementation details of a final project, then I think that's a pretty good indication that the student can code.
I would say the false positive rate for that test would be very close to the false positive rate for a white board interview with drastically lower false negatives.
If you're Google and you have a limitless number of people who want to work for you, you can get away with taking a vastly higher false negative rate for a slightly lower false positive rate. However, if you're almost every other company out there, you might want to reconsider.
Let's name some schools here. In no school I am reasonably familiar with (either first hand or by friends with attendees) would this possible.
I do think there are incompetent engineers, and I have interviewed about a dozen of them. It is very easy to filter them out.
The challenging part is to evaluate how good the candidates are, and if they would be good for the team and for the applied positions.
In start-ups with <20 engineers, you would like to have the candidates to be able to wear many hats. In a big engineering team, the requirements could be different. For example, besides challenging and creative work, there could be some tedious, even boring, work. The latter is also important, both for the whole system running smoothly and for the long term health of the system. So if the candidate is sufficiently competent, very detail-oriented, disciplined, team-oriented, she/he would be an excellent fit for the job, even if she/he is not technically very strong and couldn't figure out challenging technical issues. An excellent engineer, on the other hand, might get bore, grumpy, and leave in 6 months. It is expensive to restart the hiring process.
int* foo; // The addition of a star here, on a type, means we're converting the type /into/ a pointer-to-int /from/ a plain int.
int i = *foo; // The addition of a star here, on a value, means we're converting the type /from/ a pointer-to-int /into/ a plain int (reference).
int& foo = ...; // The addition of & here, on a type, means we're converting the type /into/ a reference /from/ a plain int.
p = &foo; // The addition of & here, on a value, means we're converting the type /from/ a reference /into/ a pointer-to-int.
(edit: C++ style comments used even in 'C' code to try and prevent YN from treating stars as formatting... replaced a few instances with 'a star'... changed emphasis to use slashes because it's still eating asterisks characters...)
The problem with randomly trying things with pointers is that sometimes you can accidentally fix the issue but introduce a subtle bug that's dependent on the data being stored.
Operative word worked. This is exactly what the article says: "They always seem to be elsewhere. For everyone."
(The presence of incompetent engineers was certainly a factor in why I left that job.)
It's an idea, not an iron-clad rule, that perhaps "incompetence" isn't as rampant as so many people suggest.