Ask HN: How are engineering skill and tech-interview skills related? | Hacker News Reader

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

6 pointsartagnon4 comments

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.

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?

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).

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.

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.

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.

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

Reply on news.ycombinator.com