I had a live coding interview yesterday and I faced interesting ( at least for me) issue.?
A small background: I was about to implement a function ?to figure out if sum of any 2 elements in input array is equal to given number. Example?
Input. ? ? ? ? ? ? ? Output?
[1,2] and 3 ? ? true?
[1,2,3] and 5 ? ? ? true?
[1,2,3] and 4 ? ? ? ? true?
[1,2,3] and 6 ? ? ? ?False?
As I was constrainted by time (~ 25 mins) I started with TDD but decided to skip most of micro steps.? In the end I implemented something pretty naive ( with O(n^2) complexity - comparing sum of all possible pairs) but it wasn’t highly welcome by interviewer.?
Moreover my interviewer wanted ?me to add extra test cases ?( beside the ones which brought me to my solution - as shown above ) just in case when” in future you want to refactor an existing solution to something more sophisticated”. I strongly refused as these tests will not make any sense from TDD point of view: they will all immediately pass.?
Do you believe that adding extra tests cases “for future refactoring” makes sense ??
I can imagine that for a particular solution of this task ( algorithm being sorting input list + using 2 pointers) If I go strictly with TDD ( a new test case must first fail) a new solution would ( but does t need to ) require a different test cases...
What do you think ?
Is it possible that TDD is not a good fit for strong “algorithmic tasks” ?
Br JM?
--
