
Organizational Skills Beat Algorithmic Wizardry - sbierwagen
http://prog21.dadgum.com/177.html
======
louischatriot
I agree with the OP but I still think the power of algorithms and
datastructures should not be understated, as they power most of the software
everyone (including "organizational" coders) use, e.g. databases.

For example, I'm writing a pure JS database
([https://github.com/louischatriot/nedb](https://github.com/louischatriot/nedb)),
and using indexing I was able to speed it up hundreds fold. That's clearly not
something I could have done without knowing about self-balancing binary search
trees.

I also think that knowing algorithms does make you a better programmer, even
if you don't use them on a daily basis.

~~~
bsaul
There really are two classes of programmer : the one that build "tools" for
other developers, and the ones that build end-user software.

The first ones needs to be fluent in every types of algorithms and data
structure. The other type will have the task of modeling real world processes
into a computer (which means "concept organization translation" rather than
pure algorithms).

The first ones deal with primitive types, and very rarely more than that. The
second ones need to model all the entities of a real life problem and their
complex interactions (complex in the sense of combinations and organization).

That's why I think there will always be a gap between those two developers.
They are dealing with very different kind of tasks, yet their jobs titles are
the same.

~~~
contingencies
This distinction is artificial. I know I do both every day.

~~~
alephnil
So do I, but those who build basic tools very often also make stuff for end
users too, but there is a lot of programmers that only do end user software
based on existing tools. They think basic tools is something someone else
does, and if there is no such tool, then what they tried is "hard to do". It
will never appear to them that they can make the tools themselves, or they
don't have the skills to do it.

The distinction is real, in that many programmers never do build basic tools,
while it is artificial in the sense that there is no reason for this other
than lack of skill and organizational culture that says that that is not
something you are supposed to do.

------
bjhoops1
In my experience, some of the smartest, best guys at algorithms and puzzles
make some of the worst coders. No one can understand their code, it's brittle
and their work eventually gets replaced by code written by somehow with half
their IQ but a decent sense of organization.

~~~
thewarrior
This seems very unlikely.

~~~
scott_s
The absolute best people I know at "algorithms" are either CS theoreticians or
straight-up mathematicians. They can program, perhaps even better than average
coder, but they don't have quite the same whole-system view as a systems
person or professional software engineer.

If you're solving problems that require algorithmic ingenuity, you absolutely
want these people. And if you can pair them with a good engineer who can
integrate their algorithm into a non-trivial system, that's when the magic
happens.

------
arbuge
Precisely so. I consider myself to be a pretty good coder because I'm good at
keeping track of many things going on at once (I used to be a chip designer in
a prior life), but I'm 100% sure I'd flunk the puzzles that companies
interviewing for coders throw out in their interviews.

Good to see a realization by Google that those puzzles aren't all that useful:
[http://qz.com/96206/google-admits-those-infamous-
brainteaser...](http://qz.com/96206/google-admits-those-infamous-brainteasers-
were-completely-useless-for-hiring/)

Google might be one company where algorithmic wizardry might be expected to be
more important than most, so that's saying something...

~~~
goyalpulkit
I think that the only reason the algorithmic interviews are still so common is
because of the difficulty in analyzing the real skills of the candidate. I
have worked with guys really good at algorithms, but it is no way related to
how good they are at building complex projects.

------
mech4bg
There's a difference between asking an interviewee to implement an obscure
data structure and knowing your basic algorithms and knowing how much
complexity is added by using certain data structures. i.e. I'd expect any
coder to understand what the performance trade offs are between a hash table
and a binary search tree, and why you'd use one over the other. This stuff
matters in day to day backend code whenever you're dealing with a non-trivial
dataset.

However writing off in-depth knowledge of algorithms as esoteric or a waste of
time is disingenuous in my opinion. I've seen lots of coders write over-
engineered, far too complex code, but they were usually not great at
algorithms.

Studying up for a Google interview was a transforming experience for me as a
programmer - I realized how much I was missing and how little I'd let myself
forget the basics since college. It made me a much better coder and made it
much easier for me to learn new languages and systems. Understanding CS
fundamentals gives you a great platform to work off, and understanding the
complex issues makes you a better coder for the day to day stuff.

------
joshuaellinger
When I interview, I use this question is a reverse fashion.

I asks how would you implement a b-tree index (for example). The right answer
is -- "I wouldn't. DB vendors put years into getting this right.".

If you want this sort of gimmick to stop, when you are in an interview, you
should just have the balls to ask how it is relevant to your potential job.
Their response will give you a good idea if you really want to work there.

As an interviewer, you litmus-tests on questions like this is that they should
be (a) answerable by all your existing employees and (b) reveal the thought
process of the applicant. If they don't do that, find some better questions.

~~~
drewcoo
That may work for you and I don't mean this as personal criticism, but hostile
interview techniques like that are enough for me to not accept a position if
it's offered. Likewise, if I were interviewing someone and the candidate asked
hostile questions to see if I "had balls" that would be a no hire. Just my
opinion, of course. YMMV.

~~~
joshuaellinger
I think you misread my post slightly.

I consider the trick questions from Google interviewers to be hostile. The
only reason not to call them on it in the interview is that you want the job
and think that you can get it by being nice rather than honest.

"having balls" != "hostile". "having balls" == "telling the truth"

The point I was trying to make in an interviewer is that you really want to
find out what someone is going to do when you ask them to do something that
they think is stupid. Because you will eventually.

As an interviewee, you really want to find out what happens if you have to
challenge the management.

You can be both honest and nice. It is just harder than trying to answer the
question directly.

------
benjamincburns
I think my company does it right.

After a phone screen we ask candidates to complete two problems at home at
their leisure. One is a simple filesystem traversal problem where we ask you
to build in some runtime extensibility, and the other is a binary space
partitioning problem (2D bounding box query) with a very difficult performance
requirement (low 10's of ms max for 1M records).

All of our interviews are conducted by more senior software developers. Before
we ever interview you we read through your code. These aren't huge tasks, but
they're enough to show whether or not you use good organization. Then comes
the interview...

We do use the first problem as sort of a litmus test. We figure that runtime
instantiation of an arbitrary class which implements a known interface is a
little on the edge of the realm of what you'll be doing day-to-day, but it's
close enough that if given the problem to take home you should know how to
Google the right runtime API calls to make it happen. And we're pretty
flexible. If you misunderstood the extensibility requirement and when asked
how you'd make it "runtime extensible" you can spit out something marginally
close to "MyInterface blarg =
(MyInterface)Class.forName(pluginFQDN).newInstance()," or even "I'd Google
'instantiate class by name in Java'" you're still doing more or less fine.
You're doing _very_ well if you can tell me how to add the plugin to your tool
in such a way that it doesn't leak implementation details to the user either
through its use or its installation procedure.

We absolutely _do not_ use the second problem in anything close to a pass/fail
manner. If you get the optimal solution, awesome. If not, no problem. Either
way, let's talk about it. Let's work together. Let's have an in depth
technical discussion about the various pros and cons of different techniques
to solving this problem. If I say something which in the context of our
discussion is by common-sense reasoning obviously wrong, will you call me out
on it (preferably politely)? If I say something that you don't understand will
you just nod and smile, or will you say "wait, what?" Or the single biggest
problem I see surprisingly often - are you capable of in some way
communicating a semi-complex idea to another person who is "skilled in the
art," either verbally, on the whiteboard, or otherwise? These are the things
we're evaluating on the second problem, not if you can pull a kd/quad/r/other-
tree out of your ass.

~~~
raghava
Asking candidates to complete problems at their leisure is a very good idea.
But recruiters can bungle up on this too.

For something that's purely procedural in nature, asking for a complete and
proper object oriented solution would not be such a good idea. Likewise,
forcing the candidate to use pure procedural method for something that
definitely needs OOP.

~~~
benjamincburns
Fortunately we have good recruiters. Once they've identified a candidate they
play purely a support role in the technical side of the evaluation process.

I'm not sure I follow that last statement 100%, but if you "go against the
grain" all we'd care about is that you're able to reasonably articulate the
"why" behind your decisions.

------
xntrk
I think the best interview I ever had I was sat down in front of a computer
and asked to complete two different classes and make the tests pass. This
tests ability to write code under a deadline and shows that the candidate
knows how to use some programming tools editor, testing framework etc.

------
mathattack
Very true. So much of the day to day job is everything except solving the very
hard algorithms. But it does help to have that person around.

A separate thread
([https://news.ycombinator.com/item?id=5911017](https://news.ycombinator.com/item?id=5911017))
discusses Google giving up on some of the insanity. In the original NY Times
([http://mobile.nytimes.com/2013/06/20/business/in-head-
huntin...](http://mobile.nytimes.com/2013/06/20/business/in-head-hunting-big-
data-may-not-be-such-a-big-deal.html)) article, Question 3 covers doing away
with brainteasers.

------
fatman
I just had my ego smacked in another algorithmic interview with a large, fancy
software company a few days ago (took too long to get too rough an answer). I
like to think I'm not stupid - my current day to day developing gig is heavy
on thinking & mathematics and I do OK with it - it's more than just
"organization". It just seems like if I spent a few hours a week entering
TopCoder competitions, in 6 months I could ace these things - but what end
result skill is the interviewer really selecting for?

~~~
victorhn
> It just seems like if I spent a few hours a week entering TopCoder
> competitions, in 6 months I could ace these things

Then why don't you just do it? And you forget once for all about these
algorithmic interviews and show your other more job-relevant skills.

------
lifeisstillgood
Absolutely.

There are times when a new algorithm (or actually a new data structure) will
revolutionise the system. But taking advantage of that is an effort of
reorganisaing the code.

------
avoutthere
I've always thought that companies like Google miss out on many talented,
hard-working, passionate developers simply because those developers can't
tackle the ridiculous programming questions in interviews. Then these same
companies turn around and complain that there aren't enough qualified
candidates.

------
piranha
The biggest problem here is that I don't see a clear way how do you assess
organizational skills of a candidate?

~~~
bsaul
that's something i closely relate to verbal expression. the first thing you
need to structure are your thoughts. so i simply ask them to describe to me a
system they've previously built. if the language is clear, then so are the
thoughts and so most likely will the code be.

~~~
RivieraKid
Are you really sure that this isn't a myth? I often have problem expressing
myself, finding the right words, but I am quite a good programmer.

~~~
bsaul
Well, it's probably not equivalent, but it's a good hint (aka : you can't
express clearly something that isn't well structured in your mind). Plus, it
also let me test verbal skills themselves, which is extremely important as
soon as you're working in a team.

Another way of looking at it is that "finding the right word" often means find
the good "fit" between abstract concepts shapes or feelings, and a construct
of known language items. That's precisely what you're doing as a developer.

~~~
RivieraKid
Ok, so it's based on reasoning full of assumptions that may be wrong, not on
empirical evidence. For me, it's quite hard to think aloud when solving some
problem, because it forces me to translate what goes in my mind into words,
which is quite distracting, I cannot fully immerse into the problem.

~~~
bsaul
I suppose you're more a "tool" developper than a "business process automation"
one. In the latter, you very often have to talk through the problem with your
customer.

But it is an assumption indeed... Only it is based on my personnal experience.

As for the comment mentionning google developpers, the ones i see are good
enough verbally to talk about their jobs at google i/o.

------
pacala
"organizational skills". aka politics :/

