2 ms·
I don't think the point the original commentors were making was "don't question requirements." It was: (1) Sure, the problem was somewhat unrealistic/simplifie
by neilc 17y ago
I don't think the point the original commentors were making was "don't question requirements." It was:
(1) Sure, the problem was somewhat unrealistic/simplified. It's just an interview question; you're not being asked to actually build the damn thing, just sketch how you'd build what the interviewer is asking you to implement.
(2) Making an initial observation about the difficulty of actually assessing frequency of word usage is great and probably better than just talking about implementation techniques, but the interviewee kept coming back to it, even when the interviewer wanted to move on. That is just obnoxious.
- Periodic 17y agoI think a good middle ground, and a good practice in general, would be to state your assumptions and make sure you recognize them as such. When you know what your assumptions about a problem are then it quickly becomes clear what questions you'd have to ask if you were going to actually implement your solution. Having a solid definition of your assumptions also lets you create a good base for building a solution and determining if it is at all feasible.