Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Re: Tests “scoped” to implementation
|
On Thu., Jan. 16, 2020, 06:55 Jakub Milkiewicz, <jmilkiewicz@...> wrote:
Writing the tests first can help identify missing or unclear parts of the specification, which seems useful for these kinds of interview questions. You can demonstrate how you ask for clarification and what you do with the information. Thinking clearly about inputs and expected outputs (a part of TDD) certainly fits algorithmic tasks well, mostly because it helps one detect the situation where their desired algorithm _almost_ meets the specification, but doesn't quite. Incremental design doesn't always lead the programmer to discover a new algorithm that fits the problem well. I don't interpret this as "TDD doesn't fit" but rather that TDD mostly guides one's existing thinking and helps one notice when one needs to learn something to help with the problem. For example, if I don't know binary search, then I don't think incremental design would guide me from linear search to binary search, but the act of trying to build the search feature incrementally _might_ lead me to consider other ways to search. Seeing dozens of examples of searching might give me enough information (I'd see patterns) to have the insight that "with a sorted search space, I can jump around and certain useful invariants hold". Of course, seeing examples is just one way to gain that insight; different people have different ways of getting there. I encourage you to learn how to put your mind in the state that tends to lead it to insight more easily. When I started practising TDD, I spent some months establishing the habit of thinking about tests first. This included choosing to write some code test-first and refactoring it incrementally, _even when I didn't need it_. Once I established more-helpful habits, I stopped approaching TDD so strictly, and instead trusted myself to use any tricks I knew to write code, confident that I would add tests and refactor safely when I found that useful. I don't think I would force myself to answer every interview question by using TDD, although I would probably apply the general principle of "make it run, make it work, make it fast" somehow. This might mean starting with the O(n^2) implementation, then spending the remaining time figuring out how to improve it. It depends significantly on what I believe the interviewer wants: do they prefer a slow-but-working solution or do they prefer to see more of my thinking on an incomplete solution that goes in the right general direction? If I don't know what to do, I just guess and hope that I'm right.? I will say this about your problem statement: given the examples you showed, I have one important question to ask: is the input array sorted or not? I would approach the problem very differently if it were sorted than if it isn't.? Finally, regarding adding extra tests, I do that, but I spent several months practising _not_ doing that precisely in order to understand when I need it and when I don't. I see a pattern among the enthusiastic programmers learning TDD/test-first programming/evolutionary design: they practise, but they don't clearly-enough identify when they're following a set of rules _for practice_ or _to perform_. The implied rule here, "I will only add tests when they force me to change the code", makes perfect sense in a context of deliberate practice, but I don't always follow it when writing code for pay. I followed it long enough to understand why it helped and I follow it when I notice myself falling back into bad old habits.? J. B. Rainsberger :: | | |
to navigate to use esc to dismiss