My first job was at a reasonably large CAD company. One of the reasons I went there was because they were the only company where I felt the interview process wa

My first job was at a reasonably large CAD company. One of the reasons I went there was because they were the only company where I felt the interview process wasn't fundamentally broken. They had the usual interview rounds, but they also had a round where the candidate had to come in and work there for a full day on a given task. The task has been the same for every interviewee for a long time. It was to write an add-on for the company's CAD product which would take a polygon and a directed line and split the polygon along the line, keeping the right side. Sounds simple enough, but given the peculiarities of the data representation of the software, pressure, etc. it took at least a day to get it right, even though the problem is stated beforehand and the candidates can think about it at home. The code also has to handle "tricky" cases like spiral shaped polygons, edges lying on the line, several consecutive vertices lying on the line, floating point issues, etc. The interviewer, who was in the meantime working on his own workstation, would eventually give the interviewee a test file with these tricky polygons to make sure the program worked. While working there, when they were interviewing, I would always go over to the interviewee to see how they were doing, and maybe give them pointers. My conclusion was that this task is too hard for a significant % of programmers. Here are two memorable cases: Guy was a mathematician in his last year. I went over, and saw some odd looking code. Turns out he was trying to first rotate the entire problem so that the line was the x-axis, because then presumably it's easier to solve. Unfortunately, he couldn't get the rotation right. This other guy was a CS major in this last year. I went over, and he was looking at the MSDN docs and it was obvious he was searching for polygon related functions. Turns out he thought there must be a function somewhere in the MSDN docs that solves this problem, there's no point in writing it!