Is this staged interview/probationary hire process a good idea?

Question

I have a personal project (web app) which is going well and I think there's a realistic chance of it growing into a startup, at which point I would have to hire people.

This would be the first time I've done anything like this. I've been daydreaming about what the hiring process might be like, when there's only me in the beginning. Technology interviews are notorious for testing people on things which don't necessarily predict the quality of the hire.

I was thinking of doing something like this.

• Candidate sends their CV, gets a phone call, and an interview on the order of, say one hour. So far so normal.

• If the interview goes well, the candidate is hired for up to one day (perhaps the same day), and paid by the hour for however many hours it ends up being. On this day they'd be given access to source code and development systems as if they were an employee and asked to do a few challenging and time-limited tasks which are actually relevant to the project.

• If the first day goes well, the candidate is hired for up to one week, paid per day for however many days it ends up being. Again they're asked to do actually relevant work, but this time they're not being time pressured and the tasks would be larger in scope. Here they'd be demonstrating their self-management skills as much as anything else.

• If the first week goes well they're given a normal contract, probationary for the first few months, and treated as a full employee.

The upsides to this process as I see it are that the candidate is being more thoroughly tested in the real work environment, and paying the candidate to do anything beyond a couple of hours' interview seems reasonable.

I can anticipate the potential downsides of legal and managerial overhead, this looks like it will involve a significant upfront investment of effort to organise. Also for the first week the candidate could be fired at any moment, this might create a threatening atmosphere. For a one-man team which is just starting to expand, maybe this sets the wrong tone.

Instinctively, this feels like a good idea, but I haven't heard of anyone hiring this way.

Is it a good idea? Do you have experience seeing anything like this go well or badly?

Answer 1

Most good programmers are already employed. They're taking vacation time, realistically, to come to the interview. You'd be asking them to take another vacation day to work with you (unless you plan on them doing their time-limited tasks after they put in a full day at their current employer). Then you'd be asking them to take a week of vacation to work with you for a week which likely also takes some time to arrange. And only then, after burning through a large chunk of their vacation hours, you would potentially offer them a probationary contract that would allow them to consider giving two weeks notice at their current employer. That certainly reduces your risk of hiring someone that isn't going to be productive but it means that the candidate is taking a tremendous risk.

Of course, it creates a number of risks for you. There is some intellectual property risk. Depending on the candidate's current employment agreement, you might find that their current employer has rights to the code that they write for you. There is a timing risk. You're going to have to wait for them to arrange a vacation day and then to arrange a vacation week and then to put in their notice before they can stat their probationary contract. That's a fair amount of waiting and coordinating. If you're a slow-moving Fortune 500, that might not be a huge issue. If you're a fast-moving startup, an interview process that stretches over a month or two would be problematic.

If you decide that you'll only hire folks that are currently unemployed, which will severely restrict the pool of solid candidates, then you just have the logistical problems. Getting a new employee set up is a fair amount of work particularly when you're going to measure their first day output and can't afford a hiccup when something doesn't work smoothly. And there is a lot of employment paperwork that needs to happen to make sure that you do the proper witholding, send out the proper tax forms at the end of the year, you've got the appropriate NDAs an the like. From the employee standpoint, the extra work involved in doing a single day of contract work may well cost them more in tax preparation fees than they'd make. And that may interfere with their unemployment benefits.

And unless you are doing something terribly repetitive and uninteresting, expecting someone to deliver a lot of value in a single day or a single week is probably optimistic. People take time to come up to speed on an existing code base, understand your architecture, get their environment set up for maximum productivity, etc. If you're just asking them to make small tweaks in very localized pieces of code based on fully developed specs, that might be enough time. But that won't tell you a whole lot about their ability to do the more involved tasks that you're likely hiring them for.

Answer 2

Go with a more 'normal' hiring process. Good employees are very wary about startups with unusual ways of doing things, most tend to 'unusual' themselves out of business (most startups fail).

What you can do is use freelancers on specific portions and then if they measure up, offer them full time positions. Then you get the benefit of watching them do relevant work and you can analyse their work ethic, efficiency etc,. before hiring them. Basically works out the same as what you describe but without the hassles.

At the same time use a normal hiring process to look for others. You're looking for someone reliable and competent, not an artist/genius type. The normal hiring process should show you who is/isn't (that's the reason people use it, that's what prospective employee's prepare for and it generally works).

Answer 3

This 'one-day' stuff is not going to pan out. Any seasoned developer worth his/her salt is only going to laugh at such an idea. Additionally, I think it's advisable that you find out how much money it's going to cost you to get a person into a legitimate payroll system, do all the legal paperwork, locate desk space, and pay worker's compensation with the intent of having that all be in place for one day. It is far from trivial and it's going to be a component for anybody running a business.

Answer 4

I am retired now, however, I have been a technology consultant for 30 years and boot-strapped quite a few start-ups that have pioneered technology we would all easily recognize today. I have done this for myself and others.

That being said, I have always recruited people I know and trust.

You cannot trust people you do not know. For some of the start-ups, I recruited co-workers to work in the evening and weekends. This is surprisingly easy since people are always interested in technology and money. The point is, I never poached employees. However, if the start-up succeeded, then I was happy if they joined the company full time during the day.

When projects were small and just starting out, each start-up would be given shares just like a corporation that allowed me to take a critical few programmers and offer them some ownership. This does two things. It gives them a stake in the success of the company. It also gives them an incentive to take a chance even for less money.

However, to do this, you must be a good salesman, choose the very best of the best technologists you have access to, be able to consistently motivate and keep peoples interest, deliver a product in a timely manner, and finally, be truthful and trusted. These are good leadership skills you will need anyway so going through this process is extremely good exercise for the future. It is also not as easy as people think.

Otherwise, the normal hiring process is fraught with risk. Hiring people you know and trust is far easier. However, sometimes people will disappoint you. So make sure you have an out. Put it all in writing. Make it official.

Here is an example.

I had an idea for a new point of sale (POS) that exists today. Pioneering a comprehensive POS that manages the entire business chain did not exist at the time. I began working on the core of the product. After 6 months, I hired a friend and gave him %50 of the product due to the level of participation he was engaged in. I needed the 6 months to create a proof of concept that people can see. It was a working product, even if it was not complete. When we needed expertise and help, we would peel off a small percentage of ownership for key programmers that filed in the gaps. This was from 1% to 5% max. We kept the personnel head count very lean. In the end, the intent was to sell the product to someone already in the business which we did. Each earned a significant income within a year. My primary partner and I earned our yearly income in just one year of part-time programming rather easily. We were highly paid at the time so it was a real boost!

Answer 5

I don't think a 'one day contract' is a good idea. I think that good candidates would not agree to do that for a startup. They might for Google or Amazon, but not for [unnamed startup with zero employees].

It's also unlikely that you would get very much out of someone in just one day; unless you're doing something uninteresting that is more a commodity operation (i.e., setting up websites for people), it usually takes some time to get up to speed on the project in a useful fashion. Startups are quicker than most in this regard, but one day seems like a stretch. Employment paperwork takes time, after all, if nothing else.

However, what you're describing is not all that unusual for companies with a somewhat longer probationary period. You could possibly hire someone on a short contract, say one to three months, if they seem like good candidates. This is called "Contract to Hire" and means that after the contract term, you consider their performance and offer them a full time position if they meet your standards.

You still need to make some effort on the interview side, though; I personally think interviews are mostly just about identifying red flags and are mostly useless for identifying good candidates, so I wouldn't worry too much about that. Make sure the person knows how to program, look at their github depot, take them to lunch or coffee or a bar and see how their personality meshes with yours; that's enough.

Answer 6

I know a person hired similar way.

The process has been a bit simpler than what you suggest:

1. A thorough telephone interview.
2. A week test with real tasks, accommodation and expenses paid + plus a decent compensation.
3. Usual (several months) trial period.
4. Time unlimited contract.

The main difference to what you suggest was timing: between points 1, 2 and 3 there were several weeks pauses for the candidate to arrange her schedule and vacation time.

It was a very specific case: the candidate was looking for a job but had not yet given notice (she was leaving the job on mutual agreement in no hurry) and her original employer was open to this sort of thing. Throughout the process many favors were done on all three sides and it still was a cumbersome affair. The field was building engineering, not as fast paced as software development, and the candidate was at the time only several years before planned retirement. The candidate also had a sound recommendation from another long time employee and applied for a position which was very hard to fill. The hiring company has had been thirty years in business, had around thousand employees and has been known to be very successful (read: had better predictability for the candidate than a brand new startup).

Yes, it worked out but I can't imagine this is the optimal way to get the people you need in your situation (I'm not in a startup business so don't take my word for it).