Hacker News Reader

Comment by hinkley | Hacker News Reader

One of the things I’ve vowed to do for my next interview cycle is set myself up an empty project with test, and it is appalling how many interviewers assume that implementation without any tests is something a senior developer won’t simply laugh at the suggestion and leave the room.

It takes too long to do these basic steps and then copy them to new projects. And generators only work once, if then, which means they are most useful in languages that have stopped iterating, which is not that compelling.

I’m hoping the next version control system solves the rerere problem and we can build our projects by forking a template project, then pull commits from upstream as necessary.

View on HN

You have to remember though that coding interviews != production code. Taken to the extreme, are you also adding logging, metrics, performance benchmarks, etc?

TDD is great if you can get it working in a tight interview time schedule - they can also reveal any misunderstandings of requirements before the actual solution is implemented!

On the flip side however, many interviewers have experienced countless folks who spend the majority of the interview time on tests and setup, only to run out of time on delivering the solution to the actual presented problem. When I feel like somebody's spending too long on these things I'll try to nudge them towards wrapping up the tests and moving onto the solution. You would be surprised though by just how frequently it's met with open hostility, by candidates with only 10-15 mins left in an hour-long interview and no solution started!

And in a real situation I have all of these tools set up and running, so I shouldn't need to spend more than a minute faffing about with them. I'm just writing exploratory tests to make sure that I've got the bits right before I put them together. Even in an hour task those tools can be a force multiplier, once you figure out how to make them work instead of fighting them constantly.

What's happening in interview loops is that we're implicitly or explicitly selecting for people who prefer to YOLO instead of writing tests, and then we are surprised how hard it is to get new and existing hires on board with mature testing processes. The people you need don't work here, they work somewhere else.

Reply on news.ycombinator.com