

Unsettling thought - chuckthompson
http://thinkdifferent767.wordpress.com/2010/02/27/unsettling-thought/

======
mds
"I’ve interviewed people with a good deal of experience in industry, with
degrees from prestigious universities, who have founded startups or done any
number of impressive things, who just melt down when asked to write a simple
piece of code."

Doesn't this just show that the ability to write code in an interview
situation is a poor predictor of future performance?

~~~
waterlesscloud
Exactly. When the evidence clashes with your theory, your theory is wrong.

If people who _have actually produced vital code_ aren't passing your
interview test, your interview test is poorly conceived.

~~~
JoeAltmaier
He mentions some of these candidates get hired and wash out. That seems like a
pretty good correlation.

~~~
hga
Indeed. The issue here is "How easily can you afford a dud hire?" Too many
people out there with _great_ resumes can't program their way out of a paper
bag.

The whiteboard test may be unfair to those who melt under interview pressure,
but if the greatest danger is false positives for the "can they code?" test---
if it's a startup where the price of one bad hire is very possibly if not
likely the failure of the entire venture---it's the best test we've got.

Note that the test doesn't have to be "tricky" or anything like that, e.g. a
simple "reverse a doubly linked list" will weed out a surprising number of
candidates. My three basic tests, back when C/C++ were the only choices to
use, were that one (tests groking pointers), do a recursive factorial (any
language will do for that), and "find the errors in this block of code".

Mistakes in doing any of the above are perfectly fine, what you're looking for
first and foremost is "do they have a clue?"

Or use another higher level test from one of the best managers I ever had: if
you have any doubt about the candidate, don't hire them. And if you doubt they
can really code....

------
rickdangerous1
When you ask someone to stand at a whiteboard and write code with a pen you're
asking them to demonstrate being able to write pseudo code with a pen. If you
need that skill at your company go ahead and interview that way. Most software
activities require the ability to write software at a keyboard with an IDE.

I suck at writing pseudo code on a whiteboard...I also suck at writing code
while someone there is watching every mistake I make. If I don't know the
exact answer in advance, I need to feel my way by trying something, back
tracking then trying a variation etc...You can't do that process effectively
in an interview at a whiteboard with a pen. Also, I don't bother carrying
around advanced algorythms in my head for doing this and that. What I do have
is an effective strategy and skill for discovering the algorythms I need just
- in - time. Who's got time to memorize arbitary algorythms so they can pass
whiteboard interviews anyway?

~~~
johnswamps
I recently had an interview at google which I did not pass. The problem I did
the worst on was finding the median of two sorted arrays. If I had 5 minutes
with my favorite editor and an easy way to run unit tests, I could have easily
written a correct version of the algorithm. It's not a hard problem, and a lot
easier than many of the algorithms I write every week.

Instead, I spent a long time erasing what I had written, running out of room
on the edge of the board, staring at the board, thinking about off by one
errors, etc. Just looking at code on a computer screen is a lot easier. You're
used to seeing code in a nice monotype font with syntax coloring, not some
scribbles on a board. And if the interviewer had just left the room for 10
minutes and let me write it on the board by myself I think I would have done a
lot better.

~~~
AngryParsley
_If I had 5 minutes with my favorite editor and an easy way to run unit tests,
I could have easily written a correct version of the algorithm._

If you did have your preferred development environment in front of you, your
interview questions would likely be harder.

I see two possible solutions to this problem:

1\. Interviewers: Change the interview process so that candidates are expected
bring their own computers to write code on. Increase the difficulty of the
questions.

2\. Candidates: Practice interviewing, including writing code on a whiteboard.
Have a friend pretend to be the interviewer.

BTW if you ever interview at Google again, I suggest reading [http://steve-
yegge.blogspot.com/2008/03/get-that-job-at-goog...](http://steve-
yegge.blogspot.com/2008/03/get-that-job-at-google.html) . It definitely helped
me. Actually, I suggest reading that before you interview _anywhere_.

~~~
barrkel
The nice thing about harder questions is that you can be sure that flakes are
more likely to fail at them. Bring on the hard questions, I say, so long as
they are not "trick"-based.

~~~
AngryParsley
Interviewers would have to spend a _lot_ more time thinking up questions, so
the cost-benefit analysis heavily discourages that. There's also the status-
quo bias to deal with.

I don't understand why people don't practice interviewing. It's worth your
time to spend a few hours practicing something that could determine your
future for years. Employers will change their interview process some day, but
until then, if you want a good job you sometimes have to jump through stupid
hoops.

Of course, I'd like interviewers to practice as well. When I interview
someone, I want to get some idea of the candidate's skills. I seriously doubt
my hastily-thought-up questions are anywhere close to optimal at achieving
that goal.

~~~
stretchwithme
usually, they've got tough problems they need solved, so thinking up tough
questions isn't really necessary

send your best people to startup weekend and similar events. It should take
only a few hours to identify the top people and establish a rapport that may
lead to a successful hire.

------
noonespecial
To be fair, a great deal of programming in today's world consists of using
tightly constrained IDE's to glue together libraries and gui kits at very high
levels of abstraction. To suddenly ask someone from this tradition to whip out
a merge-sort in bare C and then describe it in O notation might be a bit
jarring.

The people who built my house likely never took Strength of Materials during
their civil engineering undergads, they just follow the building codes and
nail together pre-made pieces (sometimes very large pieces) of house.

Would I prefer a PhD in EE to do the electric and a 6 year civil engineer to
nail together the boards, just to be sure everything is done right? Perhaps,
but I'm sure not willing to pay the extra it would take to make that happen. I
still get a decent house with those professionals working a few levels
upstream from the builders.

~~~
pedrocr
_The people who built my house likely never took Strength of Materials during
their civil engineering undergads, they just follow the building codes and
nail together pre-made pieces (sometimes very large pieces) of house._

The problem with this kind of analogy is that a builder starts with a set of
well-defined plans drawn up by some architect or engineer and then executes
the house to those specs. The only design document that lives up to that
standard when it comes to programming is the full source itself. The part the
homebuilders do is what the compiler/linker/toolchain do.

There's a classic essay about this called "What is software design?"

[http://www.bleading-
edge.com/Publications/C++Journal/Cpjour2...](http://www.bleading-
edge.com/Publications/C++Journal/Cpjour2.htm)

~~~
loup-vaillant
Good link. I have to disagree, however with the assertion that C++ was a step
in the right direction. C++ tries to bridge a gap between low-level design and
high level design. I think this was a wrong choice to make, because it made it
incredibly complex and hard to use.

Many projects don't need to worry about some low levels aspect of the design
(if at all): memory management, for instance, can mostly be left to compilers
and linkers. When we really need to, we can locally use really low level
languages, like C.

~~~
jemfinch
> Many projects don't need to worry about some low levels aspect of the design
> (if at all): memory management, for instance, can mostly be left to
> compilers and linkers.

And in properly written C++, it is.

~~~
loup-vaillant
No it is not. More precisely, I don't see how you could avoid manual memory
management in any significant C++ project. Here's why:

The only memory that is automatically managed in C++ is the stack. (If you
disagree, please know that I will be very difficult to convince.) So,
"properly written C++" literally means "C++ code which doesn't uses the heap
at all". That's probably not what you meant.

Relaxing this rule a bit, you could code in a RAII fashion. That way, the
users of properly written objects won't manage the memory themselves. The
implementation of those, however, still have to. A prime example is the STL.

Plus, I'm not sure RAII all the way down is "properly written". See, such
logic is quite copy-prone, affecting the code's efficiency. You use C++ for
it's performance, right? So you _have_ to manage the memory manually at some
point.

Or you could use smart pointers. They mitigate the need for manual memory
management, and allow sharing. But even then, you might want to (manually) pay
attention to loops in the pointing chains.

~~~
jemfinch
_Relaxing this rule a bit, you could code in a RAII fashion. That way, the
users of properly written objects won't manage the memory themselves._

Which is exactly my point: between the standard library and smart pointers,
many projects will never have to touch any details of memory management.

 _The implementation of those, however, still have to. A prime example is the
STL._

Of course. But you only need one standard library, and many projects can use
it. Don't forget your original claim, which I quoted in my previous post:
"Many projects don't need to worry about some low levels aspect of the design
(if at all)." It's absolutely true that many sizable projects written in
modern C++ never have to consider the low-level details of things like memory
management, since those details have been pushed into the libraries they use.

 _Plus, I'm not sure RAII all the way down is "properly written". See, such
logic is quite copy-prone, affecting the code's efficiency._

There are ways to mitigate that impact, if it becomes a performance issue, but
it rarely does.

 _Or you could use smart pointers. They mitigate the need for manual memory
management, and allow sharing. But even then, you might want to (manually) pay
attention to loops in the pointing chains._

That's only a problem for self-referential data structures, of which there are
few not already implemented for you in the standard library.

~~~
loup-vaillant
_There are ways to mitigate that impact, if it becomes a performance issue,
but it rarely does._

Ah. So you don't really care about performance. In that case, the only
justification left to C++ is legacy code. (Knowing Ocaml and Haskell makes me
quite certain of it.)

That was my original point: C++, even when you try to use a wisely chosen
subset of it, remains very complicated and error prone. I blame it's design
choices. I agree that those choices were precisely what made C++ popular, but
popularity is hardly a criterion for me. And on all other fronts, C++ really
sucks.

~~~
jemfinch
_So you don't really care about performance._

Did I say that?

 _That was my original point: C++, even when you try to use a wisely chosen
subset of it, remains very complicated and error prone._

Your original point, which I've now quoted twice, was that C++ is
inappropriate because many programs don't need to deal with low-level details
like memory management. My counterclaim, which you have yet to refute, is that
C++ is no obstacle to that end.

 _I blame it's design choices._

The vast majority of people who blame C++'s design choices don't understand
them. Have you read Stroustrup's D&E?

 _And on all other fronts, C++ really sucks._

Stating a claim is no defense of it.

~~~
loup-vaillant
> > So you don't really care about performance.

> _Did I say that?_

Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance
is rarely an issue. So, you rarely care about performance. That's fine:
performance rarely matters, anyway. When it does, we can still locally
optimize.

> > And on all other fronts, C++ really sucks.

> _Stating a claim is no defense of it._

You're right. _This_ is: <http://yosefk.com/c++fqa/> The writing is quite fun,
and the whole thing is actually informative. To sum up, the guy says that for
a new project with few dependencies, C++ is almost never the best choice.
Meaning, (almost) no niche is best filled by C++. Each one is better served
with another language.

> _Your original point, which I've now quoted twice, was that C++ is
> inappropriate because many programs don't need to deal with low-level
> details like memory management. My counterclaim, which you have yet to
> refute, is that C++ is no obstacle to that end._

You're right (again). I can't refute that point. Now _my_ point is, that
doesn't make C++ appropriate. See, when you don't need to do low-level stuff,
many programming languages are vastly simpler, safer, more terse, and more
flexible than C++. All at the same time. And you can learn them in no time
(you were able to learn C++, after all). So, in that case, C++ isn't the best
option. Why bother with it?

But still, I wonder how a significant project could avoid to implement some
sort of data structure itself (which would mean worry about memory). Do you
have any example?

> The vast majority of people who blame C++'s design choices don't understand
> them. Have you read Stroustrup's D&E?

I didn't. As I understand it, Stroustrup had some goals, and C++ achieved
them. One such goal was to bring Object Orientation to C programmers (the
"masses"). So I won't say that C++ didn't achieve it's purposes. It did. I
just say those purposes weren't worth the behemoth that C++ is.

Object Orientation for instance, is a mistake. As seen by C++ (and Java), OO
encourages high coupling and side effects more than is healthy. And that's
before you need to apply one of the baroque design patterns from the GoF book.

~~~
jemfinch
_Yes, by saying that copy prone RAII is rarely an issue. Meaning, performance
is rarely an issue. So, you rarely care about performance._

You need to do some work on correcting your faulty interpreter. Saying that
copying rarely causes performance problems is not at all saying that I don't
care about performance.

 _You're right. This is:<http://yosefk.com/c++fqa/> The writing is quite fun,
and the whole thing is actually informative._

Not really. Yosefk, like many C++ detractors, very clearly does not understand
the rationale for a number of C++ features. But this isn't the place for me to
spend hours refuting a link that too you mere seconds to dig up.

 _See, when you don't need to do low-level stuff, many programming languages
are vastly simpler, safer, more terse, and more flexible than C++._

That's not actually the case, though. For a lot of simple (e.g., scripting)
tasks, writing them in C++ results in a program a few small lines longer and
orders of magnitude faster. In one case I had billions of integers on which I
needed to calculate some simple satistics; while the Python program was
running, I was able to write, compile, and run to completion a C++ version
that was a mere four lines longer (mostly empty-brace lines).

Some more complex tasks are actually easier in C++ than in other languages. I
had to write a parser and virtual machine for an assembly language in college.
Doing the bit-level operations in Python would have been a pain, in large part
due to the automatic promotion of integers to longs; doing them in C++ was
simple and preserved the semantics that I required. I didn't need to manage
any low-level allocation in that program; all my "new" calls went straight
into smart pointers (auto_ptr actually worked fine in my situation and didn't
require a non-standard library) and they handled all deallocation. Valgrind
confirmed that there were no memory leaks, with no effort at all on my part.

The vast majority of people who consider C++ difficult to write are unaware
(commonly through willful ignorance) of how to write C++ for this the
frequently cited issues never arise in the first place.

 _And you can learn them in no time (you were able to learn C++, after all)._

It's not a matter of learning other languages; I'm competent in Python, OCaml,
Perl, and a number of other languages I've worked with over the years. C++ is
actually a rather late addition to my bevy of languages.

 _So, in that case, C++ isn't the best option. Why bother with it?_

Just because I can learn other languages doesn't mean C++ isn't the best
option. Sure, I could similar speed in OCaml, but then I'd be the only one who
could work on it, and my employer would be in a tight spot if I were hit by a
bus. I could write it in Python or Perl a little bit faster, but it would be
an order of magnitude slower, and I'd have to throw tons more hardware at the
problem to process the same amount of data.

 _Object Orientation for instance, is a mistake._

Ah. I see now that I'm arguing with an ideologue. Good day.

~~~
loup-vaillant
It look that we don't agree on the definition of "best". When I judge a
language I don't look at the availability of programmers or libraries: that's
a short term concern. A valid one, mind you, but one that can stick us to a
local maximum.

> _[Yosefk don' get it]. But this isn't the place for me to spend hours
> refuting a link that too you mere seconds to dig up._

Actually, I've read the whole thing. And a good deal of the FAQ as well. Also,
I think there is a good chance that Yosef did understood the rationale behind
C++, but was challenging it nonetheless.

> _Ah. I see now that I'm arguing with an ideologue._

I know my statement contradicts 99% of the industry. But I don't have much
choice. Basically I believe 2 things: (1) side effects, like assignment,
should be avoided or isolated, and (2) coupling between modules should be
minimized. OO as I see it violates both principles: objects are state-full by
default, and coupling is often high (many methods per class, inheritance). The
conclusion is inevitable: either I don't "get" OO, or my beliefs are false, or
99% of the industry is making a mistake.

Now I don't believe that OO is _always_ a mistake. I just believe that for
most problems, it is a mistake to apply an OO solution.

(Note that I say "believe", not "think". Actually, I am still full of doubts).

------
thewileyone
I have to admit that I'm not the greatest programmer in the world and I
currently work for a bank. I've been terrible in interviews when coding on a
whiteboard is required.

But I'm the guy who figured out how to fix the auto-updating mechanism in a
client to reduce the update time of 60 days to 7 days for over 6 million
installs. I'm the guy who wrote an XML stream parser before RSS readers became
embedded in every framework out there. I'm also the guy who wrote a web-front
end to a manufacturing forecasting system that sat on an AS400 system and
designed the entire middle layer architecture to support the transactions.

I'm not the greatest programmer in the world, but I think I've done some
really cool stuff; even cooler that I have an BSEE and not a BSCS.

Oh yeah, I work at a bank now cause I wanted to improve something tangible.

------
sh1mmer
One of my best friends from university went on to write embedded systems for
train controllers (this is in the UK). Given the amount of web stuff we did at
uni I thought this would be the last thing he'd do.

He's more than happy and joined the company because they gave him hard,
interesting challenges.

Not all good people end up at "trendy" places.

------
alanh
I know from experience that a number of people who make important software
used by the financial industry aren't the greatest programmers.

I think this is part of why there is so much process and quality control at
these sort of companies.

~~~
JoeAltmaier
ANd boy do programmers that have real skills Resent these processes. Because
all the do (for us) is get in the way. Its hard for companies to please all of
the people.

~~~
JoeAltmaier
So folks Don't resent these processes? You've never heard anyone complain
about them? Explain.

------
tjmc
The pendulum can swing the other way too, where "bright" developers over-
engineer their solutions. It's either to avoid boredom or "just in case" some
future feature is added. I've spent a fair bit of time working with code in
some pretty "unglamorous" industries - banking, insurance, mining etc. One of
the issues I regularly see is some huge rube-goldberg steamroller of an app
that only needs to crack a small nut. These developers are just as dangerous
in my view.

------
yanilkr
Well there are other job roles like program manager, QA manager, scrum master,
product owner etc.

------
stretchwithme
a lot of us don't create code on command. especially if we aren't coding in
the language of interest on a daily basis. and we reuse our old code and code
we find. then we iterate and iterate until its solid and the customer is happy

and then many, like me, don't have a software engineering background and don't
exactly speak the same language (don't even know UML).

I discovered recursion and binary search algorithms as I programmed, but if
you asked me about either topic, I would not have known what you meant even
though I had experience with them, until much later.

------
LiveTheDream
Every time a university switches their Intro to Computer Science course from C
or C++ to Java, a kitten dies.

~~~
WalterGR
What about if they use Scheme instead?

Or switch not from C/C++ to Java, but from Scheme to Python?

~~~
jdp
New Jersey Institute of Technology has recently switched from Java to Python.
I remember seeing my classmates struggle with the syntax of Java rather than
struggling with the actual problem, I'm interested to see the results of the
switch.

------
lenni
I can confirm the thing about the CS students who want to work for banks from
my time at uni.

