Yeah this somehow still works for pretty much every other profession, and worked fine for programming until a few years ago when everyone decided timed programming challenges were the way to go.

I wish all jobs could just hire devs for short contracts then convert the keepers to full time. I'd be more than happy in that scenario because I know they'll want to convert me and now it's up to me.

The big problem with this is that the short contract does not guarantee continuity of health insurance coverage, and this is a dealbreaker for a lot of folks. The pool of applicants who would accept these offers excludes the top-performing folks who have much better alternatives than contract-to-hire.

Developers who have great insurance coverage at their current job and require it at their next job aren't candidates for startups like mine. We don't have health insurance for employees - it's just too expensive for all but the very well-funded startups.

For this reason, experienced developers from other countries which have universal healthcare coverage and low cost of living, such as many Eastern European Countries, are very attractive to many startups.

> I hire from an international pool, often on Upwork, so I can start developers on a project basis.

I wish I could always hire developers to start on a project basis, but that's just not possible for many (most?) of the best local candidates. Someone who is great who has a full time job at company A is very, very rarely interested in leaving for company B on a project basis.

For our last hire, I was the only one on the hiring committee to ask about past projects. The others defaulted to "fundamentals" questions.

I think the reason people do this is a mix of 1) not knowing what traits to look for 2) not comfortable with unstructured conversation 3) frankly that it takes work to evaluate each resume and research projects enough to have a useful conversation.

For me though, how they achieve success at past work is the best indicator of future success.

Yup. If you need to hire a juggler, throw them some balls and get them to juggle for you.

You'll get the talented, flexible people that can get things done.

Here's the problem with doing this in the US: if you're out of a job, you're out of health insurance. If your whole family is on your health insurance plan, you'll never accept a project-based gig that might not become full time. So with this approach, you're filtering out a new and different subset of the applicant pool before they even interview.

Yeah this is the M.I.T. and Harvard "process". Hire success, instead of fostering success. Works well for small companies. If you need to hire 10.000 to 30.000 people a year, this approach is absolutely useless.

Also just because someone can't come up with the coolest solution for your project, doesn't mean they aren't good developers. This is even more biased than algorithmic interviews, because algorithmic interviews have structure. I actually CAN solve a puzzle in 20 mins. You definitely can not solve a project in 20 minutes or even an hour. It is impossible. And the best candidates will be those who sit back, analyze the problem for days or even weeks and come up with a good solution for your project. This approach is so infeasible for general interviewing that I don't even know where to begin. You are basically filtering out EVERYONE and take the one person who knew enough upfront to accidentially solve your problem best...

He said "impressive proposal", not "coolest solution".

To me, "impressive proposal" means "articulation of a workable plan", the components of which are relatively small, actionable, and take into accounts requirements, and that demonstrates a good understanding of risk. In fact I'd argue that the ability to do this kind of top-level break-down well is one of the best indicators of seniority. The downside is that to do it well requires knowledge of a very specific process, architecture, and technology stack. That is, if you're good at breaking down problems use stateful Erlang and OpenBSD running on bare-metal with web clients, you might have an issue breaking down using stateless C# on Azure with Android native clients. Some combinations are more compatible than others, of course, but any senior dev in one stack is going to have to recapitulate the learning curve of another stack before they can regain this superpower! (We may like to think that only architecture matters, but it is relatively rare that an architecture rendered in one stack is actually isomorphic to the same architecture rendered in another!)