What they're testing
Whether you separate justified optimisation from reflexive optimisation.
The short answer~30 seconds
No. 50² is 2,500 operations — microseconds, and simpler code has fewer bugs. But I'd ask two things: is n always under 50, or is that just today's observation; and who guarantees it — is there a constraint in the data layer, or is it "it has been so far". If n is user-controlled, this stops being a performance question and becomes a security one.
The long answer
The point worth making is that most real performance problems aren't algorithmic complexity but I/O: a database query, a network call, a disk read. An O(n²) loop over 50 in-memory items is thousands of times faster than one HTTP call. Optimising the loop while the function makes three API calls is a very common misallocation.
What separates this from "never optimise early" is having explicit conditions. I would optimise if: n is determined by external input, or the code sits on a hot path that has been MEASURED as slow, or the faster version isn't meaningfully more complex. The third is the forgotten one — sometimes the O(n) version is just as short, and then there's no reason to choose the slow one.
What they'll ask next
?How do you stop n from growing?
Set an explicit limit with a test behind it rather than a comment. An if (items.length > 100) throw plus a test is a real contract; a // n is always small comment is a hope.
These lose points
- Optimising everything reflexively. More complex code is read repeatedly for years, while a few microseconds are unmeasurable.
- Answering "no" without asking where n comes from. If a user supplies it, the answer inverts entirely.
Sources
- Donald Knuth — Structured Programming with go to Statements (the source of the "premature optimization" line, including the half people drop)