5 ms·
> 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
by rf15 3y ago
> 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.
- hoseja 3y agoI 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.
- arp242 3y agoExcept 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.
- dwaltrip 3y agoIn the beginning of the interview, tell them that it’s completely fine and expected to ask clarifying questions.
- rewmie 3y ago> 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.
- redditor98654 3y agoI assure you, Carlos is not a “tech recruiter”.
- rewmie 3y agoThe 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.
- redditor98654 3y agoOk. 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.
- mieubrisse 3y agoViewpoint 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.
- PH95VuimJjqBqy 3y agoYour mistake is in thinking you can communicate so perfectly that they haven't decided they have the answer to the question from your description.
- rf15 3y agoI 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.