I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.

No one desires to be in a contract limbo where they aren't sure if they're going to be hired for real or or if they're doing the job search all over again in a few weeks.

Further, as soon as you use contract work to determine hiring criteria -- you've added your management into the mix. Are expectations made clear? Is the person's time managed efficiently? If management fails at any point then it's detrimental to the prospective employee's future, likely not by their own fault.

The point is, there's no reason for it to be a genuine contract position, and every reason for it to be concise enough for them to fit in during their off hours. After all, you are going to have to look at it too :)

And they do have the time for it: after all, they are making the time for interviewing.

It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc.

I think it's a win-win.

One size definitely does not fit all here.

Trouble is most employed people will have restrictions on outside work and if its related work the current employer will own that IP.

Quitting a full time job for a new position is a big commitment on my part, and I'd like a big commitment on the other side of the table. Not to mention contracting gigs don't usually have insurance, vacation, or other benefits.

If it means a more rigorous interview that's okay with me.

An unemployed candidate can do a contract like that while evaluating other jobs and possibly waiting for other offers to come in.

An employed candidate can do the work in off-hours.

if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

I'm not sure if this is a joke, but I'll bite.

The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue.

GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.

Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wisdom.

I loved software engineering so much that I decided to turn it into a career, so that I could do it every day. But now you want me to do it every day and every night? No. My work during the day is fulfilling. My hobbies provide variety and an opportunity to pursue other interests.

A "portfolio" does not have to, and should not, consist of side projects. Don't have any real code that you are allowed to share? Obviously, many employers won't hire engineers without reviewing existing code or having you engage in a coding exercise, but here's an idea: take a bunch of screenshots of public-facing applications/functionality you've built for your current and/or past employers. With WordPress and a $25 portfolio theme, you can have a decent-looking showcase of your work product up and running in a matter of hours.

If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.

Not being able to show "code" or "screenshots" is not the fault of the prospective employee (as you "oh so subtly" implied with your last sentence).

The point here is not what you share, but that you have something to share and can present it in a manner that's compelling to your prospective employer. In some cases, that might be nothing more than a well-written, detailed description of what you developed. In others, a picture is worth a thousand words and can a preferable format for somebody who isn't a great writer.

And finally, while I wouldn't be so naive as to argue that "engineering" equals "working on public-facing applications", engineers should consider the risks of roles that do not enable them to work on systems that are "visible" or "close to the money". Obviously, there are some industries and specializations that provide lucrative opportunities that don't do this, so there are exceptions. Not every young engineer, however, can realistically count on being able to build a decades-long career in these industries/roles.

I agree with this

> If you have absolutely nothing that you can share (code, screenshots, a URL, a "case study") with a prospective employer, it's not the prospective employer that has a problem.

I disagree with this. If you require this to be true, you've instantly excluded everyone's experience in either government (particularly defense), or industry when you work on internal services. There's a huge number of enterprise developers at my current company who will never be able to show you their work because they're all internal applications. Maybe a "case study" would work, but you have to be real careful of not to cover anything that doesn't fall into the trade secret category.

If your resume is significant, then I will probably add to the signals with a phone call followup. I'm not looking to create false negatives.

I also want to point out that taking some time to develop a small and interesting project (say, a pure left-leaning red-black tree with deletion - not much code, but tricky to get right) does not take that much time and massively demonstrates your capability over having nothing at all. It also demonstrates your social awareness of the state of the field when you have a github account with projects in recent technology.

On the upside, the person with a code portfolio and less other hobbies is also more likely to be winning to commit more of their time to work, stay later, do "hackathons." It's a win-win for the employer! /s

I've interviewed many candidates, and it surprised me that pretty much none of them would take the initiative and sell me on what they could do. They'd passively wait for questions and then answer the questions.

I don't understand why technical interviews are not more oriented to "how would you design X? Ok, what objects? What interfaces? How does that work, explain like I'm your 10yr old nephew? Ok, pseudo code that part. What are challenges with it? Have you coded similar things? Tell me about one. How would you do it different now? How would you convince me that it's worth refactoring? How about if I was your peer and I told you your idea was the worst thing I'd ever heard? Ok, now assume I'm working for you, and it's my second week, explain how to write your new design from scratch, and what some gotchas I should avoid are?"

We all know that green field coding is a rarity, and most time is spent writing/running tests, refactoring, bug squashing, design writing, code reviewing, team managing (always at least upwards and sideways). Most of this is still "technical", but seems to be overlooked with endless stupid brain teasers. I know what Knuth volumes are, I know what google is, and I know my basic algorithms. Most people don't need to have memorised how to implement random algorithm x.

This is why we at Google don't (or shouldn't, at least - it's widely discouraged) ask brainteaser questions in interviews.

I disagree on whiteboard coding though. I don't find it that easy, but I think it's reasonable to expect a demonstration of relevant skills before you hire a candidate. Any sensible interviewer won't expect syntax-perfect code on a whiteboard, but it's at least a way of seeing if the candidate can walk the walk rather than just talking for an hour.

> I guess I do not see how you can lose if you take the contract-to-hire approach ..

For the first month, the vast majority of people are relatively unproductive. After the next month, good candidates are generally still going through a significant learning curve. Contracting several candidates for a few months to pick one who seems good enough is expensive for relatively little output - apart from salaries, they need desks and computers etc, and you have to do some interviewing to pick them in the first place. It's not a worthless approach, but I don't see it as a panacea.

Which I have argued many times on here, should be glaringly obvious. Measure what you want to measure. I have never said "I'm so happy we hired Jane, she just tore up that smart pointer implementation yesterday". I like and dislike colleagues based not on comp sci algorithms, but whether their code is readable, how many bugs are in it, how quickly they can produce production quality code, whether they are responsible and hit deadlines, if they ask for help when they need it, if they offer help when other need it, if they are creative, if they are doers and achievers, if they take baths (seriously), if they step out of their office and interact once in a while, if they are problem solvers, if they read and keep up with their field, if they are capable of learning, if they write good documentation, if the client likes them, if I like them, if younger people look up to them, if older people feel some pressure because here is somebody up and coming, if when I go to modify their code I only need to change it in one place, and my change fits in naturally without breaking 15 different things (because it is designed with extensibility in mind), and that my heart beats a little faster because their code is just so beautiful. And so on.

Google doesn't try to measure any of that. At all. And then you (google, not you archangle_one) express mystification at why your interviews do no better than chance. There's a clue there, I'd say. If you don't measure job performance, why do you think your measure say anything about job performance?

They also knew before hand and gave me a chance perhaps i would do something very impressive. i'm not saying my submission was perfect, i might have done a couple of things wrong, or during that period they might have found someone better, there might have been several reasons i think, but i still learned a ton about Rails.