These coding tests are actually quite an equalizer in terms of interviews: you may be ace at answering all whiteboard/phone-screen questions, but when it comes down to actually coding -- something you are being hired to do, you can't crack it. On the other end: it lets people who may not be amazing at whiteboard questions the chance to show that despite that they can get things done.
When somebody interviews for a software engineering position, the goal of the company is to as quickly as possible get an objective opinion on the person by seeing how that person compares to other candidates they have seen. This is good for the candidate too, because who wants to be subjected to an arbitrary process?
All of the alternatives suggested in the article are fine, but they don't make the interview process very objective.
Things you can see during a coding test:
- How they tend to structure their code
- Do they like to over-engineer problems
- Do they dive right in or think things out
- How easy is their code to read?
- Are they experimental, do things in an interesting way?
- Are they prone to making bizarre design decisions
etc. etc.