You throw a programming puzzle at me, after you've looked at my portfolio, admitted it qualifies, and I explained in detail how I coded each item. If you do this, it shows me you're following a trend in the industry, but that you don't really have a good interview plan.
I just went through an interview, and I got a a puzzle to solve. Basically I had to design a controller for a traffic light at a 4 way intersection. I could use sensors, timers, etc. to control the timer. I could use as little or as much time as I wanted, and make my solution as simple or as complex as I wanted. Once I was finished, I had to present my solution to the tech team, including defending design/architecture choices I made. I thought it was an elegant way to introduce me to the team, and for them to get a feel for how I approach difficult problems and how I would balance time constraints, performance, and complexity on the job.
The first point about the not liking programming puzzles made me not take the article seriously.
Its one thing for you to explain in detail things you did. Some of the best stories about how things are made are told by those who did what they were told and couldn't themselves actually have solved the problems.
I just went through an interview, and I got a a puzzle to solve. Basically I had to design a controller for a traffic light at a 4 way intersection. I could use sensors, timers, etc. to control the timer. I could use as little or as much time as I wanted, and make my solution as simple or as complex as I wanted. Once I was finished, I had to present my solution to the tech team, including defending design/architecture choices I made. I thought it was an elegant way to introduce me to the team, and for them to get a feel for how I approach difficult problems and how I would balance time constraints, performance, and complexity on the job.