

Ask HN: How are engineering skill and tech-interview skills related? - artagnon

Tech interviews are mostly about implementing canned algorithms/ data structures, and coming up with small variations of those solutions.  Preparation involves heading over to TopCoder and solving solved problems one problem after another: A* algorithms, red-black trees, TSP and so on.<p>However, what does that have to do with being a good engineer?  A top-scoring high schooler can do routine integral calculus problems faster and more accurately than a good mathematician immersed in group theory.  Moreover, why would a good mathematician be _interested_ in solving these problems, when he can just use Mathematica to do it for him?<p>How many good engineers implement B+ trees on a regular basis?  Then why test it?  That is not to say a good engineer will not able to recognize the need for a B+ tree in a real-world problem: it is to say that she will never implement a toy B+ tree when a production-grade one is available in an existing database/ filesystem implementation (that she can just modify and use).
======
Xorlev
Hiring is a inherently broken process. Being on the giving end of the hiring
process however, I'm not sure yet if I'm perpetuating a broken system or truly
helping solve the issue.

I generally ask an algorithms question not because I care about the algorithm
its self (spoiler: it's not even about datastructures), but about how the
candidate comes up with test cases and error conditions. Truthfully, my
'algorithms' question is more gauging their effectiveness at QAing their own
code.

In general though, I call those sorts of problems CS trivia. At best, they act
as a proxy gauge of skill. The theory is, any 'good' programmer can fall back
on their experience and solve problems on the fly. Some candidates keep their
cool and methodically solve the problem. Others would need time in the best of
cases.

To conclude, I think it's just generally the lack of available skill to
interview and general risk-aversity. Hiring a bad employee is an expensive
mistake, and in a startup, it could be one that kills the company.

~~~
artagnon
In general, standardized testing based on CS trivia is a good gauge of how
well the candidate has prepared for the interview. To put it bluntly, it tests
how many piss boring problems the candidate is willing to put herself through
to get into your company.

If the problem is uninteresting and tedious, it's likely that your candidate
simply doesn't _want_ to solve the problem; to accurately judge whether she is
_able_ to solve a problem would require giving her a problem she feels like
solving in the first place. Yes, some candidates do get nervous and break; you
might want to filter out such candidates on the basis that they can't handle
"pressure".

What I don't understand is how you minimize risk: picking a rotten candidate
who has prepared thoroughly for the specific interview, and leaving out good
engineers is an expensive mistake. At best, it probably works heuristically
for freshers because she's likely to retain atleast some amount of the toy
exercises she was made to do as part of her coursework.

I've personally seen too many cases of "gamification" of the standardized
testing process, and am disappointed that companies haven't been able to come
up with a better system.

For the record: this is not sour grapes. I have no desire to work on the
proprietary codebase of any company, and am quite happy just doing what I want
(contributing to real open source projects). My comment is just a general
remark on the state of affairs.

~~~
jabbernotty
There are many different kinds of pressure. I don't always handle 'interview
pressure' well (depends on the job and interview), but in most positions that
is unlikely to tell you anything about my performance during the actual job.
Unless you are hiring me to do short-term placements at clients.

~~~
artagnon
Which is precisely why I put that word in quotes :)

