That being said, I've never done any pairing so maybe it would work better in that type of environment.
The worst part was, you wouldn't even know how long the trial period was -- they'd just ask you, last minute, if you could come in again for another trial. If it's a place you wanted to work at eventually, you'd say yes.
That sounds illegal, at least here in Canada.
The food service industry in the US has never had much interest in labor laws I guess
You act like no one's been fired after their first day at Starbucks.
There are a few ways to approach a job interview. The one I like is to say, "I'm a professional working in this area; those people are professionals working in this area; I should learn what they're up to and we should see if it makes sense for us to work together right now" and right now is key, because sometimes the timing or the particular projects aren't a good match, but the people are and you'll want to stay in touch in the future.
One nice non-coincidental advantage of treating it this way is that "success" is a lot easier to achieve, so the interview's going to be a lot less stressful.
So now approach it from that perspective. You could spend a day (or two hours, or two days, or whatever interview duration) chit chatting, talking to HR people about benefits, describing past projects and whatever. But time is really short and the important questions are: what are you actually going to be working on? and are the people you'll be working with any good? Are their experience, personality, skills, etc. going to set you up to do well, help your career, get stuff out the door, and whatever other concerns you have. How are you possibly going to learn any of that without talking to them at length and in detail about their projects? And the best way to "talk in detail" is to pretend you have the job for a day and get up to speed.
So are you now "working a day for free?" Not really. Because, if the people you're interviewing with are people you'd want to work with, they've had a lot longer than you to think about their problems and know a shitload about them. If you contribute anything of value that day, they probably would have gotten as much value from talking their sticking points over with any bright, engaged outsider to get a fresh perspective.
In the rare occasions where the applicant really does provide high value consulting for free for a day, he or she should have known better than to interview there in the first place. If there really was no way to know in advance, just accept that you had a dud of an interview and go on with your life. You've still learned whether that particular company is one you'd want to have a business relationship with in the future, which is valuable, and whether any of their employees are particularly good or bad, which is also valuable; and, if the company has the right values, there's a good chance that they'd want to hire you for contract work. So even those interviews still tend to work out.
tl;dr - when you interview for a job, no matter what, you're working. You'll get the most out of it as an interviewee if you take it seriously as work and try to get as close to the day-to-day job as you possibly can. If the company materially benefits as well, even better.
Puzzles, whiteboard coding, and so on don't tell me whether or not somebody can actually build software.
If the goal was to get free work, we wouldn't sacrifice staff time on the interviews. We'd give the applicant a challenging "homework" assignment and ask them to do it on their own time.
I'm in academia. I've had job interviews where I've literally gone office to office discussing people's research projects and helping them come up with ideas. It was fun, and it never occurred to me that I was being taken advantage of. Worst case scenario, they might think of me as a potential consultant down the line.
Yep. That basically amounts to an application fee.
Plus they will spend time before and after the interview discussing your qualifications, performance etc. It comes out about even.
If the job doesn't work out, they lose small% of potential productivity, while you will lose 100% of your income.
Companies have numerous employees, but you only have one employer. You bet everything on your employer, they only bet a small part of their hand on you.
What if a company gave you an itemized bill after your interview? You're still exchanging something of value for their time; is that reasonable or ridiculous?
Of the three job interviews I've traveled for in the last year, all were paid by the company 100%.
A company would have to be pretty damn unique in order to justify having candidates pay for their own travel + lodging.
Regardless, companies across just about all industries that hire from remote talent pools will pay for travel (consulting, finance, government, NGOs, banking, accounting, manufacturing, insurance, you-name-it).
Whether or not a given company expands its talent search to include workers in distant locations is bound by several factors, none of which are unique to "SV and Microsoft".
I doubt there would be anything wrong with saying "we maintain open source project X and we only hire people who have made submissions in this project that we have accepted. If you want to be considered for employment, you must first get involved in the community."
- Are the candidates able to help make meaningful contributions to whatever the senior engineers are working on without having the background and domain knowledge?
- Do the employees have to spend a significant amount of the 2-3 hours with the candidate bringing them up to speed on what they are working on, just so that the candidate isn't totally in the dark? If yes, does this totally sideline the employees day/flow?
- What do you do if the employees don't have several hours of non-stop coding lined up for the day?
I don't doubt this method works well - but I'm curious how you work through some of the stickier issues of pairing a total outsider with a fully-up-to-speed engineer and then evaluating the outsider based on what was produced in those 2-3 hours.
- No - Yes - You have to put other things on hold and come up with something non-stop code worthy, which may be frustrating.
There's a solution I like though - work on a known bug or new feature in some open source project, potentially of the candidate's choosing, but preferably not one either the candidate or interviewer is already a major contributor to. That way both people come to the problem with a similar low level of expertise and have to work together to come up to speed (which is a great real-work-like exercise). It also makes it obvious what to work non-stop on for that time. Bonus points for being way more useful than a make-work wheel reinvention project and for not being free work for the interviewer's company.
One piece of logistical advice here: keep different kinds of keyboards/IDEs available. I use a mac and I interviewed a candidate who wasnt comfortable with the mac keyboard. In an interview situation where a person is already slightly nervous the last thing you want is for them to be worrying about keyboard shortcuts!
The purpose of pairing in this context is not to see a meaningful contribution; rather, it's to see how the candidate interacts with a codebase he's never seen before, and developers he's never worked with before. Can they spot mistakes? Recognize patterns? Read and write code? Does the candidate know the ecosystem well enough to suggest methods or libraries?
Most importantly, pairing tells us whether or not the candidate can communicate effectively. Are they terrified to offer suggestions, or overly arrogant and controlling? Can they explain clearly? Do they clarify when the other half of the pair doesn't understand?
For example, many moons ago, I did some pairing with a candidate that gave me a suggestion on how I could make a section of my code both smaller and easier to read by combining a couple of iterators in an obvious way that I hadn't noticed. We ended up hiring that guy.
The getting-up-to-speed part happens as they pair, with a lot of explanation happening as they work on the system, and it's another important part of seeing how they work -- can the candidate understand new concepts quickly? Do they stop and ask questions when they don't understand?
This type of interview is a performance hit for that employee for the day, but this is fine, as I consider hiring to be very important, and losing a day or two of engineering time over the course of a month is a price I'm willing to pay -- keep in mind that the phone screens eliminate a lot of people.
Admittedly, I've never had a day when my guys didn't have work to do, but not all interviews involved the company codebase.
I make it a point to carve space out for my team to do miniature research projects, in a fashion similar to the way HP used to work, or Google's "20% time". These are timeboxed, and at the end, the result needs to be made available to the team; and yes, "this didn't work because of X and Y" is totally acceptable. This always pays off in terms of education, and every now and then you get something useful out of them, but they're also fair game for pairing during programming interviews.
Hopefully I've answered your questions.
Note that this requires that your team does pairing.
Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes?
Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via Skype, in their own personal development environment.
Start with a chat over Skype. Talk to them a bit about their preferences and experiences at other companies. Are they comfortable to talk to? Do they have opinions about the stuff they've worked with? This is important -- A Java developer that doesn't have a vocal preference on checked exceptions or static typing probably isn't very experienced.
Then give 'em the FizzBuzz.
At this point, do you want to hire them?
If so, it's time to invite them into the office.
When they come in, at the very least you should buy them lunch and pay for transportation. They're taking a day, not paid, to come and interview with you -- show some courtesy.
Have them sit down and pair with three of your more senior engineers for a few hours each, both as a pilot and a copilot.
At the end of the day, take your group of three, and see how your interviewee did:
1. Did the candidate demonstrate the expected level of knowledge and contribution?
2. Would they feel comfortable with the candidate as their direct boss?
3. Would they be upset if this candidate went to work for the competition?
If somebody can get through the phone screen and a day of pairing, they're probably competent, and likewise want to continue working with the people they paired with.