3 ms·

The problems I ask are not amenable to solution by searching Google, and frankly, I am not actually interested in the solution. The problems I give are so easy

The problems I ask are not amenable to solution by searching Google, and frankly, I am not actually interested in the solution. The problems I give are so easy that someone who cannot solve them by writing the code from top to bottom in one go is unlikely to be successful. The problem is a starting point for a larger conversation about modern software development. For example, I used to give a question where the solution was literally: take two pairs of numbers, find their differences, add the differences together. (The problem involves computing the difference between two times represented in an unusual format.) A candidate who is unable to take the differences of two pairs of numbers and add them together is going to be unsuccessful -- and I have had candidates show up in my office claiming to be "9 out of 10" C++ programmers who could not write correct code that added and subtracted four numbers. The vast majority of programmers will solve the problem correctly, and that is step one; I want to know how are you going to test it, can you prove that it is correct, if the times were in different time zones how would you change the signature of the method, should the method return an error for invalid inputs... I want to know if the candidate can actually reason about code.

athreya86 11y ago
If you want to reason about code, why not give them the solution and ask them how they would implement it - discussing with them about how they would implement the solution would be more enlightening. When you are being interviewed, the first hurdle is 'solving' the problem - coming up with a solution. Evaluating a developer on 'how they solve' a problem in highly stressful situation seems somewhat unreasonable - after all, what is more important in their day-to-day job is the ability to write maintainable, easy-to-understand code. In real life, problems are often solved via brainstorming with the team, going through iterations of getting/clarifying requirements
- ericlippert 11y ago
  I agree; a problem I often give -- which I will discuss on my blog next week -- is "here's an existing solution to a problem, it is full of security holes and bad programming practices, describe to me some techniques you would use to fix this code without changing the public interface". That's problem people face in real-world development all the time: bunch of code, works when callers are benign, badly broken when callers are hostile, the client has shipped so we can't change the interface, fix the problem.

athreya86 11y ago

If you want to reason about code, why not give them the solution and ask them how they would implement it - discussing with them about how they would implement the solution would be more enlightening. When you are being interviewed, the first hurdle is 'solving' the problem - coming up with a solution. Evaluating a developer on 'how they solve' a problem in highly stressful situation seems somewhat unreasonable - after all, what is more important in their day-to-day job is the ability to write maintainable, easy-to-understand code. In real life, problems are often solved via brainstorming with the team, going through iterations of getting/clarifying requirements

ericlippert 11y ago
I agree; a problem I often give -- which I will discuss on my blog next week -- is "here's an existing solution to a problem, it is full of security holes and bad programming practices, describe to me some techniques you would use to fix this code without changing the public interface". That's problem people face in real-world development all the time: bunch of code, works when callers are benign, badly broken when callers are hostile, the client has shipped so we can't change the interface, fix the problem.