3 ms·
> In my experience, interviewers will rarely tell you the runtime of the optimal solution. I agree. As an interviewer, I genuinely want each candidate to do w
by aix1 5y ago
> In my experience, interviewers will rarely tell you the runtime of the optimal solution.
I agree. As an interviewer, I genuinely want each candidate to do well and I think that, on balance, setting a specific complexity goal is likely to do more harm that good.
For a strong candidate, it could limit their opportunity to shine by narrowing down the solution space and discouraging them from exploring tradeoffs (e.g. runtime vs memory).
For a weaker candidate, it could mean no solution at all instead of a suboptimal solution. I generally choose my problems such that they admit multiple solutions of varying degrees of efficiency/sophistication. It is generally not a hard requirement that a candidate find the optimal solution in order for me to score the interview favourably.
- simplestats 5y agoIn my experience, "no solution at all" is already the default. When people choke on questions it is because they get stuck trying to guess at what you want, and panic thinking it must be some clever trick they don't recognize. Becasue we've all seen a million tricks and forgotten most of them. If you're happy with just getting it done quick and dirty, at least as a start, then telling them so is obviously better than not doing so. Beyond that, anything more about what you want will help trigger their thinking in terms of the right approach. Unless of course you really are looking for some clever trick (and I have certainly seen those annoying questions).
- esyir 5y agoWhat you do in leetcode is different from what you'd do in an actual interview though. In leetcode, I don't even bother with the trivial solution, as that would never pass the testcases. However, for an interview, I'd always start with the trivial brute force solution, at least to get out a base solution to evaluate, describe and then iterate on,
- aix1 5y agoI don't ask questions that can only be solved with some clever trick. In my experience, I get the most signal by posing a question that has many solutions of varying degrees of efficiency. This way anyone except the least qualified candidates can make some meaningful progress. I then gently guide the candidate to help them produce the best solution they're capable of in the allotted time. I then score the interview on the basis of where they have landed, the process by which they got there and how much help they needed along the way (and of course the role/level they're interviewing for).