Yeah, we agree. We don't plan on asking everyone to do hours of work on their own. A lot of people don't have the time. However, we're also seeing a bunch of applicants who are good programmers, but become really stressed in interviews and do badly (they freeze). These people have trouble getting jobs. What we want to do is offer them the option of doing a larger project on their own, rather than our final interview. I think this might help a lot of people (clearly we have to test this)
Interview environments are always stressful, but so are other common workplace situations. Being unable to manage stress effectively might contribute to poor on-the-job performance, even for people with great pure coding ability.
The process right now seems focused on finding people who are the best at only coding. In the future, do you intend to also consider communication skills? Senior developers act as mentors for junior employees, and often need to coordinate projects across multiple teams.
"Stress" is not some monolithic, universal feeling. This line gets trotted out frequently in these discussions, but no one has shown a correlation between the types of stress induced in interview situations and the types of stress induced in whatever situations are typical for your company. I would hesitate to even equate the stress of high-pressure situations in different companies.
Indeed. I am one of the people that freezes up in interviews. Yet I thrive in stressful work situations, such as customer emergencies (system is down), critical bugs, etc and I resolve the issues quickly precisely because of the right amount of stress.
The best way I can describe the difference in stress is with an analogy. When I visited the Grand Canyon and hiked around the mountain, my body literally froze. I couldn't move a muscle even though my mind knew I could do this and hike around. I knew it was irrational, but I was powerless. This is what interviewing feels like - a fear of heights. And with every rejection letter, the fear is reinforced.
Stress in the office is like playing competitive sports - it's a challenge rather than percieved harm to oneself.
I don't think there's any relation. Some people may be nervous just because they are interacting with strangers, whereas they would have no problem with people they already know.
Personally I don't have nervousness/stress issues in interviews, but I've found that conversation screws up the analytical mode that I use when I'm programming. It's like how people say they don't like having their managers interrupt them in the middle of the day because they get taken "out of the zone." I can program or I can converse, I can't do both without screwing up both of them.
That's just my particular conundrum. People probably have all sorts of reasons (besides the possibility of them being bad at programming) for why they may have trouble in interviews.
Couldn't agree more. When I'm trying to think through a problem I want everyone around me to be friggin' quiet and leave me alone.
When I'm thinking about an abstract concept, trying to visualize how the pieces fit together, 'talking it through' is not helpful either. It's really goddamn distracting.
The feedback I got from my last 'cs 101 algorithms whiteboard quiz for a web dev job' was, "You need to talk more and explain what you're thinking." Ugh. Do you want the code or do you want me to talk, because you're not gonna get both.
I think it's really on the interviewers (and us) to show that people who freeze in tech interviews would also do poorly in a job. It's probably sometimes true, but many times not.
Programming interview stress is a terrible indicator of real-life leadership ability. But communication skills are still an incredibly important of being a good programmer, often more important to success than programming ability (http://blog.codinghorror.com/how-to-write-without-writing/).
Personally, I've spent hours working on a project or problem only to find that, be it the result of miscommunication, lack of critical thinking by a manager, or lack of understanding on my part, what I'd created contributed nothing to the bottom line success of our organization.
Anyone, what kind of resources are there to objectively assess a candidates communication skills, leadership ability, and teamwork? What is a constructive way to provide feedback and resources for interviewees about their performance?
Interview stress is of the type I call "defusing the bomb": everything at stake, essentially immediate time constraints and confrontational. This never occurs in real life.
"Unfortunately something not so different sometimes does. E.g., you're at a startup, you have a critical demo for your best-hope customer, it was scheduled very aggressively because the CEO wanted to fit the customer's availability, it's happening in one hour, and nothing is working.
Not exactly confrontational (though it could easily get that way if you aren't careful) but just as stressful.
Of course it's far better to avoid such situations, but they do happen.
Usually those situations are just "grinding", you need to work expediently, and there is time pressure, but it is not immediate and you don't need to think nearly as much as in an interview. (code -> compile -> ohshit -> repeat quickly) not (oh shit, how do I solve this algorithmic question I have never seen). Most people don't freeze up in the 1-hour until demo situation.
On the other hand, the time constraints in an interview are immediate: you have a few minutes to come up with a solution to a problem (interviewer will put up with at most 10 minutes of silence or babbling), it's often a zero-to-one problem (usually there isn't a way to have a partial solution) and those factors combine into exponentially increasing sense of pressure: as time goes on you become less likely to solve the problem.
Finally, if this situation does happen at all and, contrary to my claim above, certain people do freeze up, it does so so infrequently as to be immaterial in a hiring decision in the vast majority of cases. Its practical importance is certainly disproportionate to the weight placed on it in interviews.
Person after person says they do fine in the job, yet have trouble with interviews.
I've presented in rooms where the lowest ranking officer was a colonel, and most were important people at the Pentagon. No freeze up, easy peasy, because I know what the hell I'm talking about and because I know I'm not going to be judged on some bullshit evaluation. (re: "x<<8 from above). Interviews are more a crap shoot. I mostly get offers, but sometimes just utterly choke. More importantly, I usually feel miserable after.
Don't make up theoretical situations when you have real, empirical data, please.
I made no comment on what kind of interview works best. I merely observed -- what is certainly true -- that sometimes "defusing the bomb" situations actually do come up in real life, where everything is at stake and you have to work under very severe time pressure.
Do you disagree that such situations sometimes arise in real life?
If not -- if your point is that that isn't necessarily a good reason for interviews to involve such situations -- then I think we are in violent agreement. I am not arguing for defusing-the-bomb interviews. I just don't think it's quite right to say that in real life you never have to defuse a bomb.
See my other comment but I think the differences are the immediacy of the time pressure, the sophistication of the thinking required and the all-or-nothing outcome.
So you're interviewing someone and basing a large part of the experience on something that would otherwise happen maybe 0.1% of the time? Also that CEO sounds like an asshole.
It's amazing to me that a real human who has experienced job interviews could think that common workplace situations are comparable coding in front of a stranger at a job interview.
I had an enormous amount of trouble interviewing / whiteboarding initially but I got used to it pretty fast. However, I would still prefer a take home test as I feel its a far better qualifier than an in-person interview.
I personally prefer it to a point. My only request when I get this type of interview is that I'm allowed to make the project and requirements public on my github for future interviewers. If I'm doing a free project I feel it's fair.
Well, that's hard. Standardizing evaluation (critical to reducing bias) requires that everyone (or a lot of people) see a similar problem. And when someone is working on their own time, I think it's important that there's not working code easily accessible online. Perhaps this can be overcome by asking candidates to talk through their code after they are done
In most of the work at home projects I've been given there was a ton of available code online, they've primarily been for front-end positions so it's usually "Make a small app using your favorite library"
I can't imagine there are that many 3-4 hour projects that won't already have available code. The most important part of an at home project in my opinion is the walk through.
The best interview I had asked me to go through the project and explain the what and why I did things and asked for high level understanding of what the framework I chose or the browser/node was doing based on what I wrote.
It was an app in React and they went through why I decided to make a component for x, y but not z and then asked if I understood the virtual DOM as a concept.
To me that's the best you can do, you need to understand how the programmer thinks about problems, works through them and that they are engaged in the ecosystem at large.
If someone solved a significant problem at your request, but despite this you did not hire them or otherwise compensate them for that work, I don't see how you have any right either legally or ethically to expect them not to then use the work to advertise what they can do to anyone else. The premise is one-sided enough already (though the argument elsewhere in this HN discussion that it might be preferred by nervous interviewees is an interesting one I haven't noticed before) and I think expecting any sort of loyalty or confidentiality after the process has ended is rather optimistic.
A lot of companies will ask for existing code examples, in this way I can just point them to my example-code github repo and I've had companies use that instead of asking me to do a specific challenge for them.
Giving an option is an awesome idea! It says a lot about the flexibility and open-mindedness of your company. Too many companies have a "take it or leave it" interview processes.
IMO it depends on the position. I did a test-project with a follow up code review for my first job and it was a fantastic. If I had not gotten the job, I still would have been happy with the experience and code to show future employers.
If you are interviewing for a more junior or senior position, many candidates are probably switching jobs and are already swamped with work. Also, they probably already have some pet projects they can share. Requiring a test project may seem amateurish.
