I used to use diff as an interview question. Implementing a simple algorithm that produces reasonable (not necessarily minimal) diffs is fairly straightforward.

I used to use diff as an interview question. Implementing a simple algorithm that produces reasonable (not necessarily minimal) diffs is fairly straightforward. If you're on track for an ok-to-good score in implementing diff, it leaves just the right amount of time to have a rich discussion about optimizing and other approaches. I feel like this makes the interview a balanced test for programming capability, problem solving and communication. I tested it quite a bit on folks I knew and it had some of the lowest rates of false positives. The "candidates" enjoyed it and felt they solved something much more interesting to them, leaving a memory they carry through their software engineering lives. The ones I tested it on have actually mentioned it in future conversations. Interviews today are too focused on maximum time spent coding. Instead verifying ability to code is quick and we focus more on improving it and use conversation to test more high order bits.