
DHH anti-whiteboard movement - panitaxx
https://twitter.com/i/moments/835942450103451649
======
et-al
Glad dhh is starting some pushback.

Just as a minor aside, for anyone interviewing out there, don't fret about
syntax that much. If you forget, tell your interviewer "i forgot the exact
syntax, but let's assume it takes in x,y,z".

The key thing I'm look for is an understanding of what a function does and how
you're going leverage that to solve the larger problem at hand. I'd hope other
interviewers are the same way.

~~~
MrTonyD
I'm a very old timer...and I think people have forgotten that there was a time
here in Silicon Valley when it was enough to be someone with programming
experience. The interviews - such as they were - were mostly just to see if
you were someone who wasn't a complete jerk. As the supply of programmers has
steadily increased, the hoops to jump through have also increased. So now it
is acceptable to test people and just generally ask any lame question because
"you are the hiring manager". Experience and education should be enough - I'm
really not clear about why it isn't. (Not saying that programmers don't have
different skills - and different experience. But, for the most part, most
programmers can be taught enough to do most things.)

~~~
toast0
> I'm a very old timer...and I think people have forgotten that there was a
> time here in Silicon Valley when it was enough to be someone with
> programming experience. [snip] Experience and education should be enough -
> I'm really not clear about why it isn't.

There are people who managed to get a CS (or similar) degree but can't program
or problem solve, but manage to get hired at enough places to appear to have
experience, but still can't program or problem solve. That's why I interview
with a programming programming problem that I hope is at least a little bit
interesting.

~~~
donw
The real key is problem-solving ability: can a prospective hire get a grip on
a real-world problem, and then break things down into solvable components.

Real-world problem solving is often _very_ different than the very clean-cut
computer-science exercises that companies tend to throw at candidates, which
nominally have a set of solutions, only one of which is "correct" (in terms of
computational complexity).

Personally, I'm a big fan of one of two styles of interviewing.

Pair interviews are great, because they are the closest thing to a real-world
test-drive that you can get. During a pair interview, you work on real
production code, with a member of the team that you will be working with, and
at the end, it's pretty easy to tell whether or not the Thunderbirds are "go".

For non-pairing teams, I usually go with a _simple_ (think "fizzbuzz")
programming exercise, followed by a combination of collaborative problem-
solving sessions with members of the team, exploring the candidate's
background (what problems have they solved in the past?), and also a check to
make sure that there's a fit in terms of engineering culture (somebody that
hates TDD will hate working with me, for instance).

------
eschutte2
Algo/puzzle/riddle is not the same as whiteboard. I'm all for getting rid of
the former, but I have no problem getting up and writing on a whiteboard as
long as it's used for its correct purpose, viz. as a tool for talking through
a problem together.

I once had an interviewer give me a somewhat interesting puzzle to work
through on the whiteboard, but then he got all stammery and flustered when I
asked a few simple follow-up questions about it. I think there are people out
there who just can't handle humans and have to use the whiteboard as a shield.

~~~
donw
While problem-solving is fine, I am not a fan of algorithms questions.

Not because algorithms are unimportant, but because being able to code a
heapsort from memory is, from a skills perspective, effectively useless.

As the creator of Homebrew put it: "90% of our engineers use the software you
wrote, but you can’t invert a binary tree on a whiteboard so fuck off."

To me, it is enough to know what algorithms you could bring to bear on a given
problem, and have a rough knowledge of their complexity.

The things I care more about are: Can you tackle a messy-real world problem,
one that doesn't have a clear solution? Do you collaborate effectively as a
member of a team? What about your software engineering skills -- is your code
well-tested and readable? That sort of thing.

That latter point is _important_. The best engineer in the world is a business
liability if nobody else can maintain their code.

------
meowface
What's with the artifacty JPG? Is this Twitter's idea of curated content?

------
aisofteng
A good number of these confessions are downright embarrassing.

