One of the harder parts of interviews is knowing what time complexity you should be aiming for on a problem. Sometimes you're breaking your brain trying to come up with an O(n) solution when O(n^2) is completely fine, especially in an interview setting. On Leetcode, this isn't an issue because the input sizes have constraints, and if you know what you're doing, you can know a 10^5 sized array requires an O(n) solution, a 1000 element array requires an O(n^2) solution, etc (I'm oversimplifying, but you get the point).
In interviews, should you be able to just ask for the same thing? Yes, it somewhat gives away the expected time complexity, but I think it is a positive signal if an interviewee can translate these limits into time complexities. Also, it is disingenuous for an interviewer to say "the array can have billions and billions of elements" because even the perfect algorithm will not pass in any reasonable amount of time.
I'm sure this is pretty interviewer and company dependent, but curious if anyone who has interviewed in big tech companies would weigh in on whether this is a reasonable ask. Thanks!
Interviews are not coding competitions. Many interviews don't even run the code.
Interviewers want to know your thought process, want to know if you know all the ways this can be done, and that you know how you would choose between them depending on the need, and then you are able to implement at least 1 approach.
I think knowing and dealing with constraints might be more helpful in the initial online assessments that include a problem or two from hackerrank or similar platforms.
Yes, you can ask about the input size. In fact, it's expected. Any good interviewer would want to avoid someone who over-engineers.
There's a caveat though. It could be that input size is small enough that an O(n^2) will do, but that doesn't mean it's a good enough answer. A faster, simpler, more maintainable O(n) solution could still exist.
These interviews are trying to simulate working conditions, where answers are not known beforehand. Some interviewers want to see whether you can figure out if something better doesn't exist, or we can improve runtime by sacrificing space or any improvement will necessarily lead to harder-to-maintain code.
You absolutely can ask about the input size but the solution that the interviewer is looking for is most likely not going to be dependent on the input size the same way people can guess the optimal time complexity for leetcode questions based on the question's listed input size.
Interviews are very much unlike leetcode. You are not expected to figure out the optimal time complexity according to the size of the input, number of test cases, etc.