Ask HN: How often at work do you use what you've been tested on in interviews? - pmoriarty
======
Jemaclus
Almost never. I've never in my professional career had to invert a binary tree
or write a sorting algorithm from scratch or reinvent a queue data structure.
I've never had to build a Minesweeper clone or generate a maze. Any time I go
into interviews and they ask me to do these kinds of tasks, I mentally roll my
eyes and my excitement about the role drops.

I once interviewed at CrunchyRoll a couple of years ago, and every single
interviewer asked me to implement some flavor of a tree traversal algorithm.
The final guy mixed it up by asking me to solve the Knapsack Problem. At the
end of the day, I said to the interviewer, "You must traverse trees a lot,
then" and he looked at me like I was crazy and said "No, never."

Being a Netflix for anime company, I'm willing to bet they don't fill
boxes/knapsacks with products, either.

Ok, so then WTF am I doing here?

------
codingdave
It depends on which part of an interview you are talking about. Big O notation
has never been talked about in my daily work, but you absolutely need to make
your code perform well when you write it. I've never had to specifically
traverse a binary tree, but I absolutely need to be able to process data in a
single pass, and I constantly am iterating through something or another.

So if you think you are being tested on being able to recite CS algorithms,
the answer is "almost never". But if you think you are being tested on, "Can
you solve a problem with code, and make it perform well?", the answer is
"Every day."

------
JohnFen
Very often, but I think it depends on what you think you've been tested on.
Often, the test is somewhat different than it may appear.

For instance, you may be asked to write a short program to solve some example
problem. That problem may be entirely unrelated to the sort of work you'll do
in the position, but the point of the exercise isn't to find out if you know
how to solve that particular problem, it's to get an insight into your
approach to problem-solving and development more generally.

------
downerending
Not often.

Worse still, the stuff I'm "tested" on in interviews is often unrelated to the
job spec.

And of course, the job spec is often not very well aligned with the real job
spec (what one actually does every day).

------
GoForthAssemble
A bit sideways from topic but; I got grilled by the head of the Euro fighter
project (Ford management) on the importance of using arrays for everything.
Don't do 'int a;' always create an array. I was dismissed half way through for
not agreeing.

~~~
jb775
What was the argument for always creating an array?

~~~
pipingdog
The point of the question, I imagine (and am giving the interviewer the
benefit of the doubt), was to see how the candidate negotiated technical
compromises. Merely disagreeing without exploring the reasoning behind it and
perhaps finding a different solution together might be a red flag for that
environment.

~~~
GoForthAssemble
The guys who were originally going to do the interview were in the room.
Squirming. I asked if his background was APL (you know array based stuff) and
was told that APL, and I shit you not, 'was not A Programming Language'.

------
diehunde
I mean it depends. I was tested for Python and SQL and yeah I use both all the
time. Now, the specific Python questions of course not. They were just stupid
riddles.

