I spent some time working in enterprise storage (that's a rockin' industry, let me tell you!). We sold large systems typically costing hundreds of thousands of dollars per year. Our potential customers were understandably nervous about spending that kind of money without seeing the product in action. After all, this was a product where the consequences of screwing up included nasty things like lawsuits, loss of data governed by regulations, fines, and other financially undesirable things. So we usually sold our systems as a "try and buy". A try and buy is pretty simple. The customer gets the product and can use it for some period - usually 30 or 90 days - to see how well it works. At the end of the trial period, they either love it and buy it or they send it back. The customer gets the comfort of knowing it actually works and fits their needs and the company gets an easier sale. The company also gets paid from the date of installation, so as long as the product works they get the full sale price. It works remarkably well. What else costs about a hundred thousand dollars a year, represents a possibly really good resource for a company and comes with a risk that it might not work out? Hmm... sounds like a software engineer to me! What would "try and buy" look like for a software engineer? This type of try and buy actually exists already. It goes by different names, of course, since you're not actually buying an engineer, but offering her a job. Instead we call it "contract to hire" or "probation period". It's the same basic idea, though: you start by working for the company for the same period -- anywhere from 30 days to 6 months -- and at the end of that period you either join the company as a full-fledged employee or leave. The initial trial can take several forms: it might be a contract; an employment agreement with a defined evaluation period; or a different employment agreement that doesn't include some things like stock options or benefits. So why would any candidate want to do a try and buy? What's in it for the candidate? How about for the company? I'll let you in on a little secret: when you're talking about employment, the trial period is good for both sides. The employer gets to evaluate the candidate over an extended period and gets to really see how well this person can work with the team and in the company's product. There's no test like actually doing it! The trial period is also great for the candidate. The candidate gets to see if the company is actually a good fit, and whether all those wonderful claims made in the interview actually work. The employer can look for:
- Does the candidate fit into the team culture and dynamic?
- Can the candidate work within our software development process?
- Does the candidate's coding skill and style match up with our needs?
- How good is the candidate at actually delivering product, not just writing code?
- Does the candidate share our goals and values, both technically and as a company?
The candidate also gets to evaluate the company, including:
- Does that open plan office that sounded so cool work for you? Or do you actually prefer the quiet of the cube farm?
- Do you get along with the team?
- All those great claims in the interview about a sustainable process and delivery schedule: true, or just wishful thinking?
- How are the work hours? If you're a morning person and the team generally starts at about noon, that might be a problem.
- What's the code base really like? Do you enjoy working with it?
- How's the commute? Great, or worse than you feared?
What about you? Would you do a try and buy? Why, or why not?
