Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Programming Interview Experiment

sourcegraph.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: The Programming Interview Experiment

#51

Post by fsk »

georgemcbay wrote: post #45
fsk wrote: post #20

What about candidates who don't have several hours to spend on a programming assignment? Everyone seems to want one nowadays, and I don't have time to do one for everyone who asks. I've done a bunch of programming tests, without progressing to the interview stage after doing them, and now I usually refuse.

Agreed. While I do think that there is plenty wrong with traditional programmer interviews and that new approaches are needed, it isn't really a scalable solution on the candidate's side to spend hours to days on challenges for individual companies if everyone is asking for one. It becomes sort of like everyone wanting their own app store, or their own always-running polling service running on a desktop or mobile or…

What makes it even more insulting is that, I do the assignment, and still no interview.

If you give a programming assignment, then you should at least have the decency to give an on-site interview to everyone who gives a solution that compiles and runs and gives the correct answer. That's why I usually refuse to do them now.

Not only am I spending a couple hours on someone I never met, the conversion rate is so low that I'm convinced it's a waste of time.

Also it's insulting. You're asking me to waste a couple hours of time for the privilege of maybe getting a chance to talk to you? When "maybe" turns out to be "almost never", I've really soured on the pre-interview programming test.

Re: The Programming Interview Experiment

#52

Post by RunForFun »

In 12 years and more than 10 clients I have yet to run into any developer so incompetent technically as not to be able to perform his/her job effectively. However, what I do run into are individuals who cannot conduct themselves appropriately, those who cannot work in teams, and those who overlook delivering the value for their client/employer that they were hired to deliver.

All of these individuals can code, no question. However, they are impediments to accomplishing the business goals that my teams are tasked with solving.

I find it interesting that everyone I know who has been terminated or laid off has been done so for reasons not related to technical ability, however technical ability is the majority of what's interviewed for.

I think it is much more important to hire people who can work with others and deliver the value desired, but yet this is not what most employers interview for. In my opinion, if I can get a credible recommendation that a candidate is technically competent, then I don't think spending an extra minute on technical questions is important. I would rather be sure they they are competent in all other aspects of the role.

Re: The Programming Interview Experiment

#53

Post by RunForFun »

donretag wrote: post #22

At this point in my career (professional developer since the late '90s), I am extremely picky about who I work for. The interview is a two way street, where the prospective employee also gets to ask questions to the potential employer. In the described workflow, the candidate must spend several hours before talking to anyone in depth at a company. This scenario would simply not work for me. I will not spend hours of…

I also agree with this. When I interview them, my goal is to interview the client, and their goal is to interview me. If I am faced with too many impediments to reaching my goal, I will choose not to continue the interviewing process. Employers need to realize that the process is indeed a two way street and that they need to convince us that we should work with them as much as we need to convince them why they should want to work with us.

Re: The Programming Interview Experiment

#54

Post by bcbrown »

vonmoltke wrote: post #28
fishtoaster wrote: post #17

Earlier quoted context omitted.

It is possible that someone with little dev experience could complete our challenge. We were mostly trying to avoid wasting time: theirs to complete the challenge and ours to review it, if we thought it was extremely unlikely they’d complete it. However, when I referenced the hypothetical ops guy, I was referring more to a misalignment of goals: someone looking for a job where they’d be doing more devops stuff vs our…

> However, when I referenced the hypothetical ops guy, I was referring more to a misalignment of goals: someone looking for a job where they’d be doing more devops stuff vs our need for a dedicated developer. If someone were looking for a devops-oriented job, why would they be applying for your non-devops-oriented position?

Do you think it's a bad idea to have a high-level conversation between the company and the prospective employee before assigning a take-home test?

Re: The Programming Interview Experiment

#55

Post by bcbrown »

usea wrote: post #40
beliu wrote: post #7

Earlier quoted context omitted.

This is a good point, and one I forgot to address. We would never ask to see proprietary source code. Hopefully, a candidate would have a side project or open source work they're willing to share. If not, we'd definitely work around this. For team projects, we'd ask them to describe their contribution. So far, this hasn't been a big problem, but we're still iterating and making the process better!

The article is definitely not clear about this. In fact it says "bonus points if it's open source" implying that you expect to see proprietary work. It was a bit of a red flag for me while reading.

I interpreted that as "bonus points if it's contributions to a big official Open Source project, as opposed to your personal pet project with no exposure or users".

Re: The Programming Interview Experiment

#56

Post by Bahamut »

fishtoaster wrote: post #10
Bahamut wrote: post #5

I had an interview once where I did not have to write a line of code - it felt very refreshing to have my capabilities respected, although I just somehow lucked out it turned out.

Interesting- I have the opposite reaction. I would (and have) refused to work for a company that doesn't ask me to code in an interview. It may be nice for me, but it means they probably didn't ask my potential coworkers to code either, and I don't want to work on a team picked like that.

Well, my GitHub is public (and was probably convincing enough), and everyone but me at the company was asked to code during the interviews - there was evidence on the TV from someone who coded for an interview that morning even. I was found from a local AngularJS meetup, and someone at the company was trying to gently prod me towards interviewing with them over the course of months...which wasn't so much of an interview process as seeing whether I was interested, since they clearly wanted me for my expertise.

Re: The Programming Interview Experiment

#57

Post by chrismcb »

danbruc wrote: post #19

Not in a single interview ever have I been asked about the runtime of an algorithm. On the other hand it is mentioned in almost every article about interviews for programming jobs. How many companies do actually ask such questions? If your future job is mainly building standard business applications, web sites or whatever, no one cares about theoretical runtimes. If your future job is somewhere in research, game, dat…

If your future job is mainly building standard business applications, web sites or whatever you better be caring about theoretical runtimes. I ask about runtime whenever I interview someone. It is important, if you ever deal with more than a few things at a time. Exponential goes up pretty quickly.

Re: The Programming Interview Experiment

#58

Post by vonmoltke »

bcbrown wrote: post #54
vonmoltke wrote: post #28

Earlier quoted context omitted.

> However, when I referenced the hypothetical ops guy, I was referring more to a misalignment of goals: someone looking for a job where they’d be doing more devops stuff vs our need for a dedicated developer. If someone were looking for a devops-oriented job, why would they be applying for your non-devops-oriented position?

Do you think it's a bad idea to have a high-level conversation between the company and the prospective employee before assigning a take-home test?

That depends on the attitude you go into the conversation with and whether your take-home test can be automatically scored well enough for a coarse filter to reject the people who obviously cannot do it. It also depends on how many applicants you have. Spending half an hour per candidate gets onerous when you have hundreds, so cutting to the chase in a semi-automated way may be a better means of whittling the pile down than having a recruiter, founder, or hiring manager filter it based on conscious or unconscious biases.

I was highlighting that line because I think it indicates a subtle bias towards people based on background and assumes people are not making reasoned decisions about what they are applying to. I understand that there are tons of unqualified resume blasters out there, but I figure nearly all of them will either ignore the take-home or submit such schlock that it will be easy to automatically reject them.

Post reply on HN