Show HN: Interviews can be stressful – give take-home projects instead
remoteinterview.io
remoteinterview.io
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!
GlassDoor makes it easy for that reputation to spread.
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.
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.
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.
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 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.
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.
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.
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.
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?
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.
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.
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.
My employers at the time were not ok with that...
Sounds like it's a convert attempt at cutting down on contracting rates.
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).
That need does't exist in the US, where employees can be terminated without cause.
In most companies probation periods are a formality, they're only used for gross incompatibilities. But there are some that use them frequently.
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.
> Sounds like it's a good litmus test.
Yes, indeed!
That's a giant red flag. Saying that sort of thing... no, I'm not committed to you if that's your attitude. Holy hell in a handcart.
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.)
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.
•set a clear and reasonable standard of performance
•communicate the expected level of performance
•measure the employee’s performance
•take appropriate action to address any concerns
•allow a reasonable time for improvement.
from: http://www.hrreporter.com/blog/canadian-hr-law/archive/2013/...
Which is why pretty much every single employment contract in Canada includes a probationary period.
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.
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.
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.
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.
edit: typo
I'd much rather study for interviews.
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.
This is a good post discussing both: http://blog.triplebyte.com/take-home-interviews
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)
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.)
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.
Right, and I'm not saying that that is inaccurate for those particular visas. Just that the generalization to "visa holders" is overbroad.
Can't I talk you some code that I have already written instead of wasting half a day doing some trival project in a rush?
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?
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.
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.
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.
It also separates those with no job who spent 20 hours on the project from those with jobs who put in the requested 4 hours.
Never again.
The equivalent for jobs wouldn't be better.
(shameless plug intensifies)
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".
1. Click "CodePad".
2. Click "Create New Pad".
3. Press browser's back button.
4. Repeat #3 to infinity.
Ubuntu 14.04, latest Chrome
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.
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.
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.