Live data from Hacker News

I will not do a tech interview

medium.com

51–60 of 554 posts

Re: I will not do a tech interview

#51
post #46

The 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.

Easy solution to that is to discuss the work/code in the interview.

Re: I will not do a tech interview

#52
The benefits of a tech interview is that you have an opportunity to present a challenge to the candidate that contract work may not have. I increasingly use problems I have run into myself while working on the product we are hiring for. It's good to know how a candidate will solve these critical problems, because bad solutions can be really bad for your team and product. Contract work will also eat up time just getting the dev running the development environment and leak code/product secrets.

Re: I will not do a tech interview

#53
post #39
post #7

Earlier quoted context omitted.

I don't want my employees to have to learn everything just-in-time. By that logic, the people you hire wouldn't need to know anything. In addition, they don't know what they don't know, so they may not even know that they need a btree index.

>I don't want my employees to have to learn everything just-in-time. You can require knowledge without using dealbreakers like "you must know b-trees". A better alternative would be to say "you need to know 30% of the following group of things: b-trees, tcp/ip vs udp, ..." and so on.

This is a lot like what I try to do in interviews, because I'm mostly just trying to filter out liars. I pick projects out of the candidate's resume and ask them about things they had to have learned to do the job they did.

Re: I will not do a tech interview

#54

I 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 wisdom.

Re: I will not do a tech interview

#55
post #51
post #46

The 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.

Easy solution to that is to discuss the work/code in the interview.

i agree..i remember when i was a graduate assistant we would interview students and discuss their submitted homework. It was such a clear indicator of who worked and who didn't. The rule of thumb though when interviewing teams was to meet them all at the same time and never individually.

Re: I will not do a tech interview

#56
post #46

The 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.

You can tell this by the code, usually the people who offsite the code have the worst syntax, worst grammar and use foreign symbols in the code unless requested otherwise.

Also, after they have submitted it, go into detail with them as to why they did this, or why they did that. Tech interviews with puzzles, quizzes, and logic are just a massive waste of everyones time.

Re: I will not do a tech interview

#57
I'm pretty much at the same point of refusing to do any actual coding on an interview and for pretty much the same reasons. Really like the option of an offline code test followed by discussion of the solutions or a small contract. But it's pretty rare for companies to actually do this, since nearly everyone now follows Google's model.

Re: I will not do a tech interview

#58
post #27

Earlier quoted context omitted.

I guess I do not see how you can lose if you take the contract-to-hire approach I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.

I don't think many candidates are interested in "immediate" hiring. Most people I know need to take extra time to wait for other offers to come in. It also gives the candidate a way to see what kind of problems he'd be working with, and the quality of the code-base, working conditions, etc. I think it's a win-win.

It doesn't have to be immediate, but most high quality workers will not be interested in anything that requires them to spend a period of time without a full-time job. So whatever contract work you give them will have to be small enough that they can do it while still working a full-time job, or you will miss out on most of the high quality people.

Re: I will not do a tech interview

#59
post #46

The 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 dunno. Between off-site contract work and a good design discussion afterwards, I think this would be a good solution. You could make an argument that a candidate that is effectively able to contract the work out and be able to competently discuss the solution (and other approaches) would be a great candidate for the job.

Re: I will not do a tech interview

#60
post #27

Earlier quoted context omitted.

I guess I do not see how you can lose if you take the contract-to-hire approach I agree with most of what you said, but one way you can lose if you insist on contract-to-hire is that you are filtering out a portion of the highest quality candidates who are only interested in immediate full time hiring.

>filtering out a portion of the highest quality candidates if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) - well, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

> if you're not able to easily spot such a candidate without attempting to make him/her to jump through the gimmicks (brainteasers, contract-to-hire, etc..) ell, it indicates the issue with your company and hiring practices in particular are deeper than just what gimmicks to apply.

I'm not sure if this is a joke, but I'll bite.

The entire problem with hiring is that no-one, I repeat, NO-ONE is capable of determining who are the best candidates. If they could then everyone would the same formula and this would be a solved issue.

GOOG and MSFT have tonnes of hiring data and they admit they can't do this very well. It seems very presumptuous of you to assume you can and anyone who can't is somehow an outlier.

Post reply on HN