Hacker News Reader

Comment by rf15 | Hacker News Reader

> I don’t like hard or tricky questions.

...

> I’ve actually expressed the problem in an ambiguous way.

So when other people do it, hard and tricky questions are bad, but when you deliberately set your candidate up for failure by withholding concrete information, that's clever and insightful. Got it.

Or more productively put: The author obviously enjoys tearing down simple questions with complex implications (one often does in the sw field) and reflects over their candidates, but seemingly lacks the self-reflection to understand what makes questions hard or tricky and why interviewers like to pick them.

View on HN

Viewpoint as someone whose primary job right now is recruiting: my observation on what differentiates Fine software engineers from Great ones is how they understand the problem, engage with it, and go get what they need to solve it. Fine software engineers need to have the problem pre-digested; Great ones can take ambiguous problems, figure out what's missing, and hunt it down.

I don't see the author's withholding of all problem parameters as tricky at all, but an attempt to accurately mimic the ambiguities of the real world to see what the candidate does with it.

Your mistake is in thinking you can communicate so perfectly that they haven't decided they have the answer to the question from your description.

I do interviews for my team, and I'm very aware that framing questions the wrong way quickly leads people into the trappings of their own obsessions. Be that a need for optimising the wrong things (e.g. optimising minute but easy to optimise logic next to large, network-heavy calls), or assuming the wrong perspective on a task (e.g. getting tasked with an accidentally math-heavy problem, and assuming it's about solving the math instead of their overall approach to new requirements) or simply lacking the confidence to question obvious problems in the task they were given. Interviewing is a stressful to downright dehumanising process that is hard to get right, even with years of experience.

I don't see it. Usually the bad tricks are CS puzzle gotchas, not a designed-in, well-spottable, management underspecification, which is actually testing for an everyday-used skill in the actual job.

Except it's not a "actual job" setting. It's an interview.

Especially for more junior people it's selecting on confidence, because especially in a hiring setting they don't want to "seem stupid" by asking questions. I guess this is also a problem for more senior people. It's just a different setting than "actual job".

If you want to ask if anything could be clarified then ask.

In the beginning of the interview, tell them that it’s completely fine and expected to ask clarifying questions.

That has only limited effect, as this kind of thing is more of an emotional thing.

You people just love making up excuses for failing simple interview questions don't you?

> So when other people do it, hard and tricky questions are bad, but when you deliberately set your candidate up for failure by withholding concrete information, that's clever and insightful. Got it.

To me the worst part is the nonsense rationale to argue away using a database to store and query this data. Taken from the article:

> In theory you could write a pretty simple SQL query, and sure, Big Tech companies have giant data warehouses where you can easily do this sort of thing. But for the scope of a coding interview, you wouldn’t want to. Since this is not a distributed systems problem and the data fits in memory, why introduce the additional complexity and dependencies of a database for something that you can solve with 20 lines of simple code?

The blogger's problem statement explicitly mentions the system needs to track business metrics. Business metrics include things like clickstream metrics and the task of analyzing business metrics is exploratory in nature and requires dashboarding. Only an utter moron would look at those requirements and say "hey, this is a task for logs dumped onto a text file". There is no way in hell that this task does not involve in the very least a database.

This is yet another example of a technical recruiter evaluating candidates, and rejecting them, because they did not presented the wrong solution to the wrong problem that the recruiter somehow convinced himself it was the right one for some reason.

I assure you, Carlos is not a “tech recruiter”.

The blogger describes his blog post as "A coding interview question, from the viewpoint of an Google/Amazon/Microsoft interviewer".

I'm not sure it makes any sense to refer to anyone engaged in interviewing and candidate evaluation as anything other than a tech recruiter.

Ok. If that is what you meant. I thought you meant a recruiter as in a tech recruiter that finds candidates from different sources and then sets up the actual interview loop after a brief initial call that might involve a simple technical equestrian.

"Recruiter" usually refers to a person whose role is sourcing talent. Their responsibilities are more like identifying candidates, salesmanship toward the candidate, and minor filtering that doesn't require too much subject matter expertise (resume review, canned questions with correct/incorrect answers)

"Interviewer", by contrast, is much more often an actual practitioner whose main role is something else (it rarely makes sense to keep a stable of people around who are solid enough engineers to give interviews and not have them do actual engineering).

Reply on news.ycombinator.com