This piece mirrors my thoughts on tech interviews as well. Firing brain teasers at somebody under the pressure of a job interview environment gives very little indication of how the candidate will actually perform their day-to-day job duties. I've long thought that the short-term contract method was far superior. This is especially relevant in light of yesterday's post about the "Wretched Google Interview" (https://news.ycombinator.com/item?id=6243627).
I will not do a tech interview
101–110 of 554 posts
Re: I will not do a tech interview
#102Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
> if you freeze up in interviews, are you also going to freeze up in developer meetings? No, the examples you listed are very different settings. An interview is far from a casual conversation, no matter the tone of your voice. An outsider is trying to prove themself to the group, they are under direct scrutiny at all times. One mistake can widely swing the interviewer's impression and cost them the job. No matter ho…
Not to mention getting a job or not getting a job has the potential to be life changing. There are very few developer meetings or code reviews that will have such a huge impact on one's quality of life.
Re: I will not do a tech interview
#103The whole point of tech interviews is to see if the candidate actually has the requisite skills for the job. Off-site contract work is NOT a solution. Hint: the candidate may not be doing the work himself; he may be farming it out to oDesk or Elance at a fraction of the price and playing WoW all day.
I don't know...seems far fetched. You should be able to sniff that out when talking with the dev about their code.
And if someone at oDesk or Elance does that nice of a job you should just hire them.
Re: I will not do a tech interview
#104To go on a tangent, the OP mentions once being asked for his favorite video games...if I'm ever in a interviewer role -- and the candidate mentions in passing that he plays video games as one of his interests -- I think that'd be a great expository question.
For instance, a gamer who enjoys TF2 or better yet, Left4Dead...that's a partial sign that they enjoy teamwork, despite the downsides of dealing with weak-links and griefers. Someone who enjoys only Halo deathmatch...well, hopefully their skills match their bravado ;)
Re: I will not do a tech interview
#105I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this. Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherr…
I've become a real believer in the "portfolio". I make the assumption that any person with a github (bitbucket/etc) site with a track record is someone worth looking at; if their portfolio demonstrates quality work and the resume looks all right, I'll recommend them. Yes, false negatives, people with horrible IP agreements get screwed, etc. False positives are much worse than false negatives in the common business wi…
I couldn't agree more. I think far too many candidates fail to make an effort to demonstrate what they have achieved in the past, which is generally a pretty good indicator of what they're capable of delivering going forward. Although portfolios are a must for designers, I'm always amazed that more developers don't put something similar together to showcase their work.
Re: I will not do a tech interview
#106well you better have something to show then such as a public github repo.
It's funny, I have a very well developed github account and a couple of public web application side projects. I'm always curious where employers think that code came from when they reject me for not being able to do fizzbuzz on a white board in front of 5 people.
Your example shows that even within IT there are segments of people. There are people who are algorithm/book smart. They can code fizzbuzz, b-trees, etc... all day long on the white board. But those same people may not be able to ship something. There are other people who don't even care what a b-tree is until they come across some problem they are researching on SO because their shipped app is broken.
Each of those people are important to have depending on the companies situation and that's why no one interview process works for all programming positions.
Re: I will not do a tech interview
#107Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…
if you freeze up in interviews, are you also going to freeze up in developer meetings?
Are you really saying that your developer meetings are as high-stakes as job interviews?
Re: I will not do a tech interview
#108I have passed a bunch of job interviews in the past - but I feel the exact same away and hire this way these days. I really do not see the point of brainteasers or white board coding questions if you have a budget where you can just pay out a contract like this. Also, I believe there was an article posted here a few weeks back that indicated Google's brainteasers did not lead to quality candidates - I know I am cherr…
i once needed a job so bad and was asked to solve a Rails challenge. i never did Rails before but i learned it and solved the challenge in a week. i also thoroughly documented my learning process and decisions. However i was rejected for being too fresh which i understood, i learned a lot during that week and even though i didn't get the job i feel that i achieved something. so i also don't see how you can lose with…
That's great that you got something out of it, but I have to wonder why it took them until after you completed the task to figure out that you were "too fresh."
Re: I will not do a tech interview
#109> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about t…
It would also breach the work contract of many developers. Most work contracts tend to (1) prohibit you from taking on other paid work (2) claim copyright of the work you do while under employment (which is why the FSF & Apache foundation require employer waivers from contributors).
You could make it a short take-home assignment where the code doesn't get used by the interviewing company and the assignment is short enough that the interviewee doesn't feel like they need to get paid for it. It would basically be the same as doing it in-person but removes the added stress of the over-the-shoulder scrutiny, leading to a more realistic scenario where a developer has resources such as Google and Stack Overflow at their disposal.
In my engineering days, a company I interviewed for had me prototype some stuff in SolidWorks but gave me the courtesy of working alone. I just had to tell them when I was done. Even this was much more preferable to an in-person on-the-spot tech interview. I got an offer for that job, but if I had to perform the same task with someone watching, I don't think it would have gone as well.
Re: I will not do a tech interview
#110> I politely suggest that a short contract job might be the best option for a company to evaluate a senior developer I like the twist of doing the contract off site on the developers own time. Every time I see someone on hacker news saying, "we've solved the interview problem. We just require every new hire to give up their old job and contract with us for a week to see if they are a good fit", I often wonder about t…
Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense.
Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at least 10 hours preparing for it (with perhaps only a bit of assurance that I had prepared properly). If I were given a ~10 hour contract project, I would know the problem up front, and be free to complete it without the stress of a whiteboard session.