This is taking interviewing and hiring in the wrong direction. At my company, we have a relatively short interview process, followed by a 3 month full salary probation period.
The interview is used to weed out "red flaggers" and identify high-level strengths and weaknesses. It is completely non-technical. We assume that the person applying for the job has the technical requirements. (We also make judicious use of references, something people seem to have forgotten about. Quick phone call to previous employers can save you tons of money!)
The 3 month probation period is the real "test" and the applicant will be put on a small project with another employee mentoring. If someone lacks technical ability, it will be evident in the first few days and we can move on to the next applicant. If the person doesn't like the work environment, they can walk away no questions asked (maybe the commute is too long or they don't like the office space, etc. etc.).
This is cheaper than having directors and executives try to plan around all sorts of interview stages. It is much less stressful, as the applicant, once into the probation period, is treated like a regular employee and has much more opportunity to "prove their worth". Stop adding more shit to the interview! Don't make it longer, do the opposite!
The big problem with this is that I wouldn't leave my current job for a 3 month contract that may or may not pan out. If I'm currently unemployed, then I might take this risk, but there are other companies who will do the work up front to decide whether I'm a good fit (and them for me), and once I accept the offer, I'm employed for the foreseeable future. The 3 month probation period (or even a 2 week contract, as others suggest) just won't work with senior candidates like me who already have jobs and might just be looking for better opportunities.
This applies even if you aren't leaving an old job. If I'm on the job search, and I get an offer for 3 month probation, they are effectively asking me to end my job search for a chance. If the job doesn't pan out (for any reason, not just that I was a bad coder or something), you can't put 3 months on a resume, so I would have effectively been unemployed for 3 months, on top of however long prior to the probation.
Just call it a short-term contract, which it was. Or just say you weren't working for 3 months. If someone has a problem with that, I wouldn't want to work for them in the first place.
Since employment is almost always at-will, how is this any different from an employer hiring someone full time and laying them off after 3 months? It short enough so you wouldn't qualify for unemployment in most (all?) states.
It's really a matter of defaults. If you hire someone full-time and they're even just more or less average in their role (to your way of thinking), you're probably not going to fire them after 3 months just because they're not the very best hire who has come down the road in the last year. On the other hand, if you offer someone a 3-month try-out and they're "just" solidly competent but they don't really wow you, you may well decide not to extend a full-time position.
I would think that if you are confident that you're qualified for the job then you shouldn't need to worry about any probation period.
Job security between the two is an illusion. It doesn't matter if you're contract or full-time. You can lose one just as easily as you can lose the other.
No, that's not true. A full-time offer is a commitment to full-time employment. A three-month trial period is an overt refusal to offer that commitment.
Software firms can be ruthless about at-will employment, but they can't do that while retaining staff and recruiting new staff effectively. Companies that are ruthless about at-will employment are ostracized, which is why that kind of ruthlessness is rare in the industry.
> but they can't do that while retaining staff and recruiting new staff effectively
I wish I had a better way to ask this, but... can you actually provide any evidence this is true? It is directly counter to my ~10 years of experience, and I've seen it at many companies that are home-run-level successful (i.e. there's no way one could qualify them as having trouble recruiting). I'm not sure I could name even one company that is "ostracized" for their hiring practices.
The only way that I can reconcile this theory with my experience is if I take the maximally extreme definition of "ruthless" ... something like firing someone in their first week after enticing them to leave a job and move across country. That, of course, will get you a bad reputation quickly. But I personally have not seen measurable negative consequences for firing alleged low performers for little to no reason within a 2-3 month period.
I would be curious (and pleased) to hear if this is just an unusual sample of experiences I've had.
Edit: let me clarify that when I say "I haven't seen measurable negative consequences" I don't mean that I have done that to anybody. But it has happened to upwards of 10 people I know.
Probably not. There's a "fire-fast" culture that is probably abused more than applied properly. Again, my objection to "trial period" is that it's an overt refusal to make a commitment to a candidate; at the end of a trial period, you can be released for all the same reasons as you could be at an interview: poor culture fit, lack of "passion", &c.
Do unscrupulous companies fire for culture fit? I'm sure there are lots that do; I wish I knew more about which ones they were.
I'm not sure that's true. (I don't disagree, I'm just not sure.)
I think an employer might be more willing to take a risk on a candidate they're not sure of if it's only for a few weeks. "Well, we're 50/50 on this guy, so let's bring him in for 2 weeks and see how it goes." On the other hand, if it's a permanent hire right off the bat, they'll want to be a fair bit better than just 50/50.
Answers to this would be all over the map, but I'm going with "no."
If I/we make a job offer to someone, it's because we think you're a good fit and you will be productive. Bringing someone in for 2 weeks, then someone else in for a month, then another guy for 2 months wastes even more time than just interviewing them each for half a day. Not to mention the uncertainty and morale effects on the rest of the team.
At least in California, you can be fired at any time for any reason. You are essentially on contract whether you know it or not. So whether it's 3 month or 1 year, it really doesn't matter. What matters is if you want to have the job, and if you're qualified for it.
I think it's better if there's a new hire that isn't working out, to just give them some severance pay and fire them quickly. Obviously you should be hiring with good intentions and believe that they will do well after due diligence, so 50/50 isn't a good probability to hire someone, it just causes a lot of disruption and lot of bad will.
Virtually every state in the country is at-will, which is a good thing. But the norms of this industry put the onus on the employer to (a) verify that candidates can execute before extending offers to them and (b) demonstrate conclusively that the fault is with the employee before terminating.
A trial period essentially tells candidates "your first three months on this job are a kind of extended interview". People are rejected after interviews based on standards of evidence far, far lower than the ones commonly used to terminate employees.
I'm fine with employers hiring in good faith, and then firing within a few months if the candidate isn't a good fit. It's far more efficient and easier for everyone that way, instead of dragging down the team, creating a burden on others, etc.
Why would I ever accept a job at a company who treated the first 3 months of my employment as an extended interview, after which I could be released without penalty?
When a software accepts a full-time position, they are taking a mammoth pay cut from what they could make 1099 contracting. They do that because the full-time position comes with a commitment to continued employment, so even though they could be making 2x-3x more per day consulting, they don't have to hustle to keep their utilization up.
The "3 month probation" thing is essentially a temp-to-perm contacting position. Do you pay people 2x-3x more during that period?
> The "3 month probation" thing is essentially a temp-to-perm contacting position. Do you pay people 2x-3x more during that period?
What about paying people the 2x-3x more in the event you decide not to keep the hire? Then the mechanism becomes a 3-month option to make the job either full time or a fairly compensated contract.
> What about paying people the 2x-3x more in the event you decide not to keep the hire?
This could be pretty easily abused, since it doesn't sound hard to get through the door if they are assuming you're qualified technically. So all you have to do is know just enough to fake it a little bit, then coast for as long as you can to get a big payout at the end.
If you're running easy-in, fast-fire, then you should pay 2x-3x continuously during the trial period, just like you would to a freelance consultant doing the same work.
But if you're running a real hiring process with accuracy as a goal, as you probably should be, then the 2x-3x payout at the end of the trial program at least fixes some of the incentive problems, and, if you're running that program in good faith, you're doing it because you expect most people you extend offers to will pan out --- so you'll rarely pay that bonus.
Agree completely. And I wouldn't leave my currently solid job, as much as I might dislike it, for a 3 month contract-to-hire position. That's insanity.
I tried to design a similar system that moved the yearly bonus for the first year into a non-contingent bonus at the 6 month period. So regardless of whether you left, we fired you, or you stayed, you got your bonus at the 6 month timeframe.
What I find interesting is that so many tech companies (maybe not just tech) seem to approach employing people from a negative standpoint. Everything is aimed at "weeding people out"...it's almost like the default assumption is that candidates won't be suitable for a position.
> they are taking a mammoth pay cut from what they could make 1099 contracting. They do that because the full-time position comes with a commitment to continued employment,
Sounds like it's a convert attempt at cutting down on contracting rates.
In France there's a 4 month probation period extensible to up to 7 months. It's too long, 7 months makes very little sense, and some companies abuse it. Basically you can pretty much fire at will during this probation period, but after it's _really_ hard to fire under French employment laws. If you're in a field where it's hard to land a job, it's 7 months of butt clenching.
I've worked in a company where I've been let go after 2 months in the probation period, but it was clear I wasn't a good fit with the company culture. This is what the probation period is for, we didn't need 7 months to figure that out. On the other hand, I worked for a consulting company that automatically extended all the probation periods, and laid off people that were on probation if they didn't have enough consulting contracts to feed everybody on the payroll (and then reshuffle contracts among people post-probation that were unfireable).
In Germany we got 6 months. You can get fired faster in this time (2 weeks) but you can also leave faster. I saw employees and employers use this a few times.
The probationary periods in France and Germany address a different public policy issue than the trial period we're discussing here. After the probationary period in France expires, it is legally much more difficult to terminate an employee.
That need does't exist in the US, where employees can be terminated without cause.
Nobody mentioned senior candidates. Not the linked site or the parent you're replying to. Yes, you may want to have a different hiring practice for the few senior members of your team. You may also want to have a different hiring practice for the CTO. Nobody is suggesting these positions are equivalent and should have equivalent hiring practices.
> Are they committed to my company and the job or not?
What have you done for them besides offering a rosy mission/vision statement that may or may not end up being a bad joke like a lot of rosy mission/vision statements out there?
Just because you have chosen to call yourself an founder does not compel the Magic Fairy of Labor to provide an endless pool of fans that will throw themselves between yourself and a bullet every time the "needs" of the company demand it.
> Are they committed to my company and the job or not?
Unless they are heavily (to the point it provides the overwhelming majority of their material support) invested -- in equity terms -- in your company, why should they be committed to it? Certainly, someone holding -- much less seeking -- at-will employment has little rational reason to be particularly committed to the company, as the company has made relatively little commitment to them (essentially, none beyond paying them for work already done, and not dismissing them for any legally-prohibited reason.)
> Quick phone call to previous employers can save you tons of money!
That may be really dangerous for the ex-employer. I'd never comment on an ex-employee beyond confirming that he worked on the given dates.
> This is cheaper than having directors and executives try to plan around all sorts of interview stages.
From my experience, in the first 3-6 month you invest a whole lot in the new employee. He or she is very far from 100% productive and you also need to assign someone for mentoring which also takes company resources. Bad hires are really expensive.
In my previous company I was involved a lot in hiring. After CV screening we normally did a 1-2 hour interview (both technical and non-technical) which was (in a positive case) follow by an offer to spend one day working with us. Finally, a permanent contract with 6 month probation time (standard practice in Germany). We had very high success rate. No bad hires on my memory, low fluctuation, very high employee loyality. The company has stellar employee feedback on kununu.com.
The downside was that many applicants were really discouraged by our hiring process. Some people were outraged by the fact that they had to actually write code on the interview. Some thought we the purpose of the probation day was to make the work for free. But that's OK, we've found a lot of great people anyway.
Now I'm working for a huge corporation. I'm normally not involved in interviews for permanent positions but I'm always interviewing when staffing external developers my projects. (We staff developers mainly externally.) It's normally 1-hour interview, again both technical as well as non-technical.
In any case I can't imagine hiring on the basis of a non-technical interview. Bad hires are just way too expensive.
If you are in the US, what is the difference between the "3 month probation period" and the rest of their employment, since you can fire them at any time anyways?
There's effectively no difference, but the general understanding (with some exceptions, e.g., Netflix) is that hiring someone full-time involves a commitment on behalf of both sides to do what's possible to make it work. If there are issues, the employer and employee will try to fix them. With a probationary period that explicitly involves a determination on a longer-term relationship, that's not a given. At least, that's my understanding, and others may correct me.
Why do you except Netflix here? I'm not familiar with anything unusual about their hiring, and a couple of quick searches didn't turn up anything. Has their hiring been on HN previously?
I assume that he's referring to some of the pieces that have been written about Netflix practices such as lack of performance improvement plans. If someone isn't working out for whatever reason--maybe the job requirements have changed--let them go rather than stringing things along. I'm not sure that's inconsistent with trying to make things work though, just not trying to make things work out when you know how the story will end. https://hbr.org/2014/01/how-netflix-reinvented-hr
I believe PIPs exist to both measure the employee's performance and provide documentation to fire the employee. PIPs exist solely for legal reasons -- it protects the employer from being liable for an unjust firing. I'd be interested to see stats around how many times a PIP turned around and improved the employee.
>Quick phone call to previous employers can save you tons of money
Not sure about that - I thought that most companies these days will confirm the dates of past employment and nothing else (for fear of lawsuits).
Also, anyone who submits references will make sure that they (the references) speak highly of the job-seeker, even if s/he is a total flake.
So I have to relocate or stay away from my family for 3 months for some coding job. wtf. And everyday is an "interview" for 3 months where my every move will watched and analyzed?
What a strange and disrespectful way to treat people.
I imagine you don't have a lot of H1B hires. I'm on one and I wouldn't even consider interviewing at a company that did a trial period. It's just too much risk.
Consulting works a lot like this. Talking with new clients, they ask if I can do something. I say sure, and by when. If it works, we agree on billing rate. Initial projects are almost always small. Unless they're desperate. If they like what I've done, and are OK about the cost, they come back.
I like the sound of this. As well as giving the candidate ample opportunity to show what they can do, it'll also be representative of the actual work they'll be doing in that role so everyone will be going into the post-probation period with eyes wide open.
What's wrong with adding a short online programming test at the start of the interview process to weed out clearly unsuitable candidates? Interviews take up a lot of time.
The 3 month probation method may work with large and stable companies but for a startup, keeping a bad programmer for 3 months will be highly toxic and can actually kill the company.
A bad hire will drain financial resources yet contribute little to success of the product/company. If a company has a good financial cushion, then you are right that a hiring mistake will not be catastrophic. However if a company is struggling financially then it can be.
Well that's the great thing about it being probationary! You don't have to keep them for the whole period, if you realize they aren't a fit in the first week, you can move on.
You make good points. For top talent, it's much less stressful and uncertain and more likely to result in gain to just continue working on and publishing one's own products than to deal with the mess of precious entitled thinking that dominates the interviewing and hiring process of the contemporary corporate scene.
I've always liked take-home projects for 2 reasons:
1) I get extremely anxious during interviews, so I don't perform well in them (to the point of crying sometimes - http://blog.pamelafox.org/2013/09/technical-interviews-make-...)
2) I like getting to see what it'd be like to do the sort of work that the company would be asking me to do for my job - it's a good taste to see if the company would be a good fit for me. The best take-homes are the ones that very closely approximate the actual job.
However, not everyone likes take-home projects or has the time to do them. So it seems that companies should ideally offer each candidate multiple paths, and develop consistent rubrics to evaluate how each candidate does across paths.
I also do like the idea of probation, as it once again seems like it could be both good for the company and good for the employer, to give them both a sense of fit. Jobs are such big decisions, it's stressful for both the employer and employee to figure out if it's the right path for them.
This is silly. First of all, are interviews stressful, yes. That's not a bad thing. The real world is stressful. Soft skills matter. Interviews are useful to see how candidates react.
Second, most people aren't born with the perfect skill set for a job. Most don't even acquire it in university, or at a previous job. Most important is the ability to learn and grow.
Third, in this day and age, you may send hundreds of resumes, and have multiple interviews. Are you going to do 2 weeks of take-home projects? What if you have multiple interviews in one day, and both places expect you to finish take-home projects. What then?
This just seems like another hoop to make candidates jump through, with no good outcomes.
Interviews, for many people, are stressful in a way that jobs are not.
Personally, the most stressful things I've had to do as a developer (including speaking in meetings large and small) are an order of magnitude less stressful than even the best interviews.
During my last job search I did a take-home project, spent far more time on it then was specified, and then was rejected without an explanation. What a wonderfully productive use of 40 hours.
I always end up enjoying the projects and learning a lot about a new domain in the process. I think for me, I see them as an opportunity to write code outside of my current role or comfort zone. I have been rejected once, the team really liked the project and I spent a considerable amount of time on it, but they found a more experienced engineer.
As someone who has had "8 hour" take home projects with requirements like "build a responsive site for this fictitious product and include creative UX features as well as a full summary of thought process during the project" I think this idea is horrible. I refuse to do take home tests, they are a waste of my time.
I've been to 50+ interviews on both sides of the table and can tell you there is always a few questions you can ask to determine someones development competency.
Not to mention I have literally thousands of hours of work I can send you from PSDs to code if you want to dive into my work.
Best interview I have had was an interview, then it was followed up by a paid "side-project". I got paid to do some work for them and everybody was happy. Eventually, I figured out there where some politics/business practices that I didn't care for and I politely declined the position. It just wasn't a fit, not the end of the world, nobodies feelings where hurt. (it also helps having a job, when looking for one.)
The thought of 3 month probation period is just silly, the author clear doesn't understand the concept of risk.
I know when I walk into an interview and someone asks me the difference between php 5.6 and 5.7, that's when I walk out. (true story)
> You cannot legally do paid side jobs with visa holders.
An alien admitted under a visa can do paid side jobs if the visa they have permits work in the United States (unless the visa only allows restricted work not compatible with the particular paid side job.)
H1-B & TN visa holders can only do work for their specified employer(s) in their visas. I would be pleasantly surprised if this was actually not the case.
If you have a green card or general work permit then it doesn't matter of course. To get a general work permit although, you're usually pretty close to getting a green card.
The vast majority of people you could hire that have visas are those two categories. L visas are even worse because I think you cannot transfer employers with them. The few H1-B spouses, O-* holders and others are few and far between.
I think companies should optimize on giving options between all of the proven methods.
Some may like the classic interviews but some may have a good github profile which is also a good signal on how the applicant is.
As in the classic interview, discussion based on previous project, discussion on take-home interview.
I think there can be good results when candidate is given the choice.
There are simply too many things that you learn in the interview that are too difficult to learn any other way. Having someone code is NOT about seeing what kind of code they produce (well maybe a little); it's about getting to know as much as you can about them in as little time as possible.
I want to put the candidate under some amount of stress to see how they respond. After all, responding to stress (deadlines, technical issues, people issues, etc.) is a very important part of a programmers job.
Just a few of the things I usually learn with a short coding test in an interview right away:
- Did he understand the problem?
- How did he approach the problem?
- Does he appear as if he has any idea what he’s doing?
- Can he explain what he has done?
- Can he defend what he has done?
- Does he understand the concepts of order, cleanness, iteration, branching, recursion, etc., etc., etc...
- Based on this small sample, do I think he can do the work we need done?
- Do I like him? Will he fit in and be a good team member?
Of course, I share all of this with the candidate. There's no secret agenda. We just want to make a fair assessment of fit. This is good for everyone.
All a take-home project does is separate those who can build superior code from those who can build good code under ideal conditions. This is nice to know, but not a very important metric in the real world.
Ideal conditions rarely happen on real projects. Why simulate them in the screening process?
The problem is that most interviewers think they can assess these things, but (a) really can't, and (b) are having their readings confounded by the nervousness and discomfort of candidates.
Also: we banned "Do I like him? Will be fit in" at Matasano several years ago, and were far better off for doing so.
Answer honestly: for every bullet in this list, did your team have a standardized rubric by which you could mechanically evaluate candidates? Matasano had a much smaller list of considerations for candidates, but developing working rubrics for assessing them took years. If you really have a working rubric for this ambitious list, you could be making a lot of money with it.
Note also the pronoun you've chosen to use through your comment. I know it isn't deliberate, but that choice also has an impact.
This is an excellent point and it's one of the ways we tried to reduce the interview subjectivity at my last employer.
Don't get me wrong: in the end, an interview is highly subjective, but when five people are evaluating someone, you want to have some way of calibrating their expectations so they are at least close to being on the same page.
It helped to even out the process. If Tim says the candidate was a 3 out of 5 on multithreading concepts, I know what questions he could have been asked (there may be 6 to choose from on the list) and what quality of answers he gave (typical candidate responses are shown, in increasing order of "quality").
Did it help get us better developers? I don't think so. In the end we concluded that our biggest problem wasn't screening good from bad candidates -- we usually made pretty good hires. The problem was getting good candidates to apply in the first place.
I don't disagree with you, but my problem with short coding tests is that they're often very, very contrived. The kind of contrived that it is extremely likely that it will be something I have zero experience with in my day-to-day work. It's extremely difficult to find a coding challenge that hits all the points you mentioned.
At my current company, we have several problems that we choose between, depending on the skill level of the candidate. But even after interviewing over a hundred candidates, I still feel like none of us get half the information we think we're getting.
I don't have any answers, but I don't think your plan of attack is necessarily any better than the author's.
And using the assumption that the quality of employed engineers is higher than the quality of unemployed engineers, you are lowering the quality of your perspective employment pool.
Nope. I've had several of these, all were at least a full days work, which I had to cram into late evenings etc on top of day job. And to top it all, they weren't even discussed in the interview!
Take-home projects are not the best way to judge skills (atleast in their current form). In the future, there would be some centralized solution so we don't waste time again and again.
My "centralized solution" is my career. I've successfully done a lot of hard work, I can speak intelligently about it, what more do you want? (generic you, not OP you)
I never met anyone that can talk well about code, that can't actually code. I met plenty who like to throw hip new technology buzzwords around without actually having good reason to use new technology.
We are trying to do same i.e. streamline the process. I do both take-home projects as well as pair-programming during screening. Take-home projects give me a big picture about candidates' ability to solve problems with software whereas pair-programming interviews tells me about his ability to think in terms of code at deeper level.
That assumes that you know how to test and judge engineers. I think the larger issue in engineering interviews these days is that we simply don't know how to effectively separate good engineers from the bad, and given the nature of our job there is a sometimes significant lasting negative impact of a bad/messy programmer.
In addition people are better at different things. I joined a startup recently. The code is well organised at the top level, and the logging was superb. However the architecture was terrible, horriby overengineered. And it looked like a Java programmer doing python - camel case instead of underscores (well a mix just to be inconsitent). Joins done at the application level rather than the database. And just doing way more work that was needed to calculate something.
Is there a mechanism for paying the test taker? A developer shouldn't be expected to work for free. The outside chance he'd be the 1/100 applicant to land the job isn't enough.
The best company I ever worked for did a two hour pair programming session on a simple rails app (since they were a rails shop) with every candidate that got passed the "chat over coffee" stage. You'd get to see the kind of code the candidates write and how they work through problems, how they work with another developer, and get a really good overall sense of how they would work as part of the team.
I like pair programming sessions a lot because both the candidate and the employer are investing an equal amount of time. While the intention behind take-home projects is good, the result is often that the candidate invests several hours into a project just to be quickly passed over by the employer.
Personality, communication skills, etc., all matter. A lot. There's more to being a good software engineer than knowing how to code well. You have to be able to back up your ideas, convince others of your ideas, hear others view points and objections to your ideas, etc. Take home projects are great, but they're not a substitute for a face-to-face interview.
We do both:
- A take-home project that takes a few hours
- We assess their code; if it looks good, we bring them in for a few more interviews, both tech and non-tech
- If it doesn't look good, we move on to the next candidate
OMG. A few more interviews? Can't you handle everything in one or two interviews?
Seriously, from my (quite senior) point of view - if you've seen my CV, done research on me (StackOverflow, GitHub etc.), seen my code from the take-home project, did a technical and non-technical interview and still unsure if I'm a match or not, I'd really doubt your competence. I must be really so exceptionally interested in the position to do a "few more interviews".
I think this is ideal - as long as the technical interviews are about the project itself. Reading these responses, I get that a lot of people here are in the role of interviewer and seem to forget what it's like to be trying to get in the door. You cram as much algorithm knowledge, language trivia so you can be prepared for 4-5 pet interview questions that could be anything. It truly sucks, is a huge time investment for the prospective employee and most of the time it's not clear what the Nth interviewer is looking for when he asks you your favorite network protocol.
I like it. Let the company decide what's best. This is just another tool they can choose to use.
The term "take home project" is wrong. It's a take home "interview"! I keep my interview challenges at a 1-2 hour time frame if you know what you're doing. If you take longer, you may not be qualified.
I'm all for trying out new ways to interview people, but IMHO people should err on the side of caution and be willing to let "good" candidates slip through the cracks than risk hiring someone who is a dud. Personally, I think it matters if someone can come up with a solution in 1 hour vs 15 hours.
There's a difference between being able to come up with a solution in 1 hour vs being able to come up with a solution in 1 hour on a whiteboard, with no internet access, and with someone breathing down your neck the whole time.
If your company has a genuine need to screen candidates for their ability to perform under the special conditions of the latter, then by all means, set up your interviews with those special conditions. Otherwise, I feel you'd be better served by an interview that more closely emulates the actual working environment that your employees work under.
My ideal technical interview would be one where the candidate is assigned a problem that is representative of the work that they're being hired for, and then left alone to work on it for an hour or two in their own preferred working environment, and then the interviewer and candidate can meet up and demo the solution and discuss implementation details.
>There's a difference between being able to come up with a solution in 1 hour vs being able to come up with a solution in 1 hour on a whiteboard, with no internet access, and with someone breathing down your neck the whole time.
You can usually fit about 15 lines of code on a whiteboard which tends to bias questions to simple logic questions. Why do you need internet access? Also why does someone have to breath down your neck? They could leave you alone for 45 minutes and come back.
>Otherwise, I feel you'd be better served by an interview that more closely emulates the actual working environment that your employees work under.
Why do you feel this way?
I think that programmers should have as many programming related patterns memorized as possible - For e.g. How to compose different kinds of programs when given different resource restrictions, or having basic algorithmic concepts in their head so they can quickly choose one over the other. A programming test should immediately indicate if the candidate has such things on the tip of their tongue or not.
In much the same way as you don't open a high school physics textbook when you go about building an airplane, you don't want someone who has to google basic programming knowledge that they should just have in their head.
IME, when you start with a very high level of intrinsic knowledge it's much easier to make connections and come up with unique solutions, because your not constantly 'searching' for things. Instead you're just 'picking' the right building blocks. Or maybe trying to quickly eliminate obviously bad choices. Ofcource there is much more nuance, but you can't state everything in a single comment ! :")
For the same reason why I feel whiteboarding and having someone breathing down your neck are generally not reasonable conditions to place on a candidate (and you seem to agree with me for these two points, so I'll only expand on the point about internet access): It doesn't make sense to place artificial limits on candidates' abilities to perform their work, when that's exactly what you're trying to gauge in a technical interview.
RE: internet access.
As with natural language, developers tend to have an active vocabulary (concepts and APIs that they come across often and can recall on demand), a passive vocabulary (concepts and APIs that they may be aware of and recognize, but cannot apply immediately or without reference), and a set of completely unknown vocabulary.
Yes, developers should strive to build and maintain our active vocabulary to the greatest extent possible (i.e. memorize all the things) since it would make us more productive. However, human active memory is severely limited compared to the vast amount of knowledge developers often need to perform their work, and as such the vast majority of most developers' knowledge tends to reside in their passive vocabulary.
To force candidates to develop without internet access means limiting them to their active vocabulary, when this is only a tiny subset of their total vocabulary. This means you won't get an accurate picture of their ability to perform their work, which is exactly what we're trying to gauge in a technical interview.
IMHO the dangers of hiring a dud are overstated and the costs of passing on a winner are understated. The former generally assumes the worst case while the latter generally assumes passes are "free" beyond the resources committed to the interview. Neither position is realistic.
this is equivalent to asking math students to provide their answer but not show their work. I interview people to figure out how they think and learn how they solve problems. I don't actually care about the answer they give to the technical question nearly as much as how they got there. No way in hell I'd do this, nevermind pay for it.
The interview is used to weed out "red flaggers" and identify high-level strengths and weaknesses. It is completely non-technical. We assume that the person applying for the job has the technical requirements. (We also make judicious use of references, something people seem to have forgotten about. Quick phone call to previous employers can save you tons of money!)
The 3 month probation period is the real "test" and the applicant will be put on a small project with another employee mentoring. If someone lacks technical ability, it will be evident in the first few days and we can move on to the next applicant. If the person doesn't like the work environment, they can walk away no questions asked (maybe the commute is too long or they don't like the office space, etc. etc.).
This is cheaper than having directors and executives try to plan around all sorts of interview stages. It is much less stressful, as the applicant, once into the probation period, is treated like a regular employee and has much more opportunity to "prove their worth". Stop adding more shit to the interview! Don't make it longer, do the opposite!