[brianberns]

> Here's an entirely novel concept for evaluating if somebody can write code that solves actual problems. We could ask people to, IDK, write code that solves actual problems. They're there for a day. A good coder can solve some pretty interesting problems in a day.

You mean solve an actual business problem that the interviewing company has? The ramp-up time to be productive in any real business that I've been associated with is significantly greater than the time available in a single interview (usually an hour or so). This is why toy problems are used.

Another issue is that it's not really fair to ask an interviewee to solve your company's problems for free. In fact, without some sort of contract, the interviewee technically owns her own work, so even if she manages to solve a real problem, the company really shouldn't use it.

(BTW, 5K interviews at one hour per interview is 625 eight-hour workdays. Assuming 50 work weeks of five days each in a year, that's 2.5 work years devoted to nothing but interviewing in your career. Yes?)

[pmiller2]

Not an actual problem the company has, but a pared down version of a problem the company had.

[brianberns]

Easier said than done. You probably end up with something that's essentially a toy problem anyway.

[groby_b]

Thankfully not 2.5 work years. See above for explanation. Probably around 0.5 work years, smeared over almost a decade.

And no, not an actual business problem, a constructed problem. But in the same domain. (See other comment above)