I once decided to skip the standard programming problem during the interview process, and I ended up regretting it extremely. The person we hired was nice, and a good "culture" fit, but couldn't code for beans. We had to let them go and I felt pretty bad about it. Programming questions certainly aren't the be all and end all, but as a filter they are useful.
Hiring Developers: You're Doing It Wrong
61–70 of 230 posts
Re: Hiring Developers: You're Doing It Wrong
#62Earlier quoted context omitted.
No, you've missed a key risk: (4) that the prospective employer continues to get resumes from people even after "filling" the position and decides on T+89 that you're great, but they can do even better. During the 90 day contract, both you and the employer must technically still be "looking" (the company still has an FT headcount to fill, and the dev still doesn't have a job). But the company is inherently better pos…
(4) isn't really a risk if the employer is following a consistent hiring procedure, since they will not have had the time necessary to evaluate your potential replacement. What sane employer is going to willingly pass up someone who's been vetted over 3 months (and determined to meet the standards) for an unknown?
Re: Hiring Developers: You're Doing It Wrong
#63Earlier quoted context omitted.
Try looking at it a different way - assume, you will have a full time job at either of these prospective employers. Do you want the one that makes FT offers immediately, or the one that makes them only after testing new people out for 3 months?
I want the one that makes FT offers, because I don't believe that the best programmers, who can write their own ticket in this business climate, would put up with this contracting bullshit. This approach to hiring is a cop-out. It says, "we don't know how to hire properly, so we're going to push the risk onto the candidates".
Anyways, I don't see why this is a cop-out any more than any other hiring procedure. No company has anywhere near a 100% success rate - this procedure acknowledges the shortcomings of a traditional interview process (namely that succeeding on an interview and succeeding as a developer are two very different animals) and tries to address them.
Re: Hiring Developers: You're Doing It Wrong
#64Earlier quoted context omitted.
(4) isn't really a risk if the employer is following a consistent hiring procedure, since they will not have had the time necessary to evaluate your potential replacement. What sane employer is going to willingly pass up someone who's been vetted over 3 months (and determined to meet the standards) for an unknown?
Hey, if you say so. If this is working out for you, that's great. I wouldn't do it. I'd tell friends not to go along with it. In Q1'2011, I wouldn't have wanted to do anything that made it even epsilon harder to recruit and retain the best people. But I'm (a) in a talent-intensive business with fierce competition for people, and (b) a consultant who knows a bit about how contracts are actually valued and who thus thi…
Personally, I'd rather work at a company that falls into the latter category.
Re: Hiring Developers: You're Doing It Wrong
#65My current system is: 1) Simple programming challenge ( 2) Casual discussion-style interview to get to know how they think and behave. 3) Short term contract with a predefined project ( 4) Full time hire with salary + equity.
Wow, you actually encounter people willing to take you up on #3 these days? They're either in love with your company or desperate for work.
Re: Hiring Developers: You're Doing It Wrong
#66Earlier quoted context omitted.
Conversely, (3) might attract some programmers who want to work at a place that is very careful about who they bring on FT. There are three risks compared to a FT offer - (1) the business goes south and they can't afford to bring you on FT (in which case you might be screwed even if you had gotten a FT offer), (2) you're not a cultural fit (in which case, it's the better outcome for everybody) and (3) you don't meet…
No, you've missed a key risk: (4) that the prospective employer continues to get resumes from people even after "filling" the position and decides on T+89 that you're great, but they can do even better. During the 90 day contract, both you and the employer must technically still be "looking" (the company still has an FT headcount to fill, and the dev still doesn't have a job). But the company is inherently better pos…
Now sure, this guy is the rare 10% that is completely honest and pure, I will assume that and he has no ill motive at all. But the other 90% that he has no control over is the real issue with this. Most people with talent that have been around the block a couple times have gotten burned by this scam and avoid these scenarios like the plague. If you are a reputed expert the way you handle this is either handle it as a straight consulting job at your standard rate (which should be something like $180-$250/hr if you are any good at what you do or $120 if you are a newbie) for the 90 days, or you put a big fat penalty in the contract that if they say no at the end they have to pay severance to cover the full cost of both of your relocations, the one out there, and the one back, including losses from the required hasty real estate transactions. Will they agree to these? Usually not, and that's the point. You really only want to do business with people who are fair dealing, not people looking to cheat contractors through false promises.
Another scam is the two day long interview where you work on some serious problem the company is having and it happens that you are known as an expert in that field, your name coming up on some searches. For me it was Windows graphics drivers. Back in the 1990s I would get tons of job interview requests and then would be treated to two days of intense querying to "prove" that I knew how to solve their problems in detail during which they either took a lot of notes or recorded the interview. Lots of other people get this one too.
Another related scam is the programming problem you are supposed to solve which should take 30 minutes, but as an expert it takes a full week. Instead of being a puzzle it is something obviously related to their business.
Just say no to all these! I know the bright eyed and bushy tailed kids won't listen, but this old geezer has to warn them nonetheless.
Re: Hiring Developers: You're Doing It Wrong
#671. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.
2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).
Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.
There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...
The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.
3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.
Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.
Re: Hiring Developers: You're Doing It Wrong
#68Earlier quoted context omitted.
If the 3 month contract is paid the normal wage then I'd rather go to a company that does this because it means that there's an higher probability of having competent coworkers there. That's the reason why I do the same in my own company now. This is of course because he said he didn't care about location, so there's no moving costs and so on...
Why would the competent developers migrate to the company that is more hostile, in a purely objective sense, than the alternatives?
Re: Hiring Developers: You're Doing It Wrong
#69Earlier quoted context omitted.
Wow, you actually encounter people willing to take you up on #3 these days? They're either in love with your company or desperate for work.
Someone who opts-in to #3 is not necessarily desperate. In fact, to the contrary, they likely also want an opportunity to feel the company out and be more confident in their choice to stay/leave at the end of 3mo.
Re: Hiring Developers: You're Doing It Wrong
#70Earlier quoted context omitted.
Hey, if you say so. If this is working out for you, that's great. I wouldn't do it. I'd tell friends not to go along with it. In Q1'2011, I wouldn't have wanted to do anything that made it even epsilon harder to recruit and retain the best people. But I'm (a) in a talent-intensive business with fierce competition for people, and (b) a consultant who knows a bit about how contracts are actually valued and who thus thi…
To each their own - if your only goal is to minimize missing qualified people, then I would agree that you should offer FT offers to everyone. If you have a stronger goal of minimizing the number of unqualified people you hire, then that's a different issue. Personally, I'd rather work at a company that falls into the latter category.
I don't think most people even question how ridiculous it is that companies interview a person for a couple hours and then agree to work with them for many months or years before they will even consider firing them (usually only after additional months of trying to "work it out").
In my opinion the best recruitment tool is having a team that a potential candidate would be really happy (and lucky) to work with. You can only do that if you keep standards up and hire slowly and methodically. A bit of a pain in the beginning, but worth it for everyone involved in the end.