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

11–20 of 59 posts

Re: The Programming Interview Experiment

#11

Post by pavel_lishin »

fishtoaster wrote: post #8

To start, I think your interviewing practices are significantly better than the stock whiteboard-based version (and your criticisms thereof are spot-on). That said, some concerns: Leading with the source graph challenge seems a bit much. My experience has been that it’s necessary to have at least some filter for the unwashed masses before requiring that much work of someone. At my last company, we had a 30-minute non…

> some filter for the unwashed masses

I have a feeling that an unwashed boson wouldn't be able to complete the challenge at all.

Re: The Programming Interview Experiment

#13

Post by jasonpeacock »

fishtoaster wrote: post #8

To start, I think your interviewing practices are significantly better than the stock whiteboard-based version (and your criticisms thereof are spot-on). That said, some concerns: Leading with the source graph challenge seems a bit much. My experience has been that it’s necessary to have at least some filter for the unwashed masses before requiring that much work of someone. At my last company, we had a 30-minute non…

But what if the ops engineer can pass the coding challenge? He maybe trying to change roles.

Or the dev that only knows pascal - if they can pass the challenge using pascal then I'd think they could easily learn whatever coding language your team uses. Learning a language is easier than learning coding.

That's what I like about coding, and about these blind challenges - it's purely skill based. If they want to apply and can pass the test, they they're worth talking to. If the wrong people are applying (and passing) then your job description and challenge are wrong and need to be calibrated.

Re: The Programming Interview Experiment

#15

Post by benched »

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.

I didn't have to write a line of code during interviews for my current job. It felt like they looked at my resume and concluded it wouldn't add anything. I did, however, had to write code to solve a non-trivial, job-related problem, as a pre-interview screening step. If I hadn't had to write any code at all, I think I might have felt a little uncomfortable. Like, is everybody really sure about this?

Re: The Programming Interview Experiment

#16

Post by benched »

jasonpeacock wrote: post #4

"Bring the source code—we’ll ask to take a look at it." Seriously?? What actual company do you know that would allow its IP to walk out the door? And possibly to a competitor? Additionally, projects are usually the work of a team, and are heavily iterated upon. "your contribution" is usually hundreds of little changes building upon other changes, not "this is the application I wrote".

I think it's assuming you've done something substantial on your own time, or worked on open source. I don't know exactly how common either of those is, but I'd guess pretty common.

Re: The Programming Interview Experiment

#17

Post by fishtoaster »

jasonpeacock wrote: post #13
fishtoaster wrote: post #8

To start, I think your interviewing practices are significantly better than the stock whiteboard-based version (and your criticisms thereof are spot-on). That said, some concerns: Leading with the source graph challenge seems a bit much. My experience has been that it’s necessary to have at least some filter for the unwashed masses before requiring that much work of someone. At my last company, we had a 30-minute non…

But what if the ops engineer can pass the coding challenge? He maybe trying to change roles. Or the dev that only knows pascal - if they can pass the challenge using pascal then I'd think they could easily learn whatever coding language your team uses. Learning a language is easier than learning coding. That's what I like about coding, and about these blind challenges - it's purely skill based. If they want to apply…

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 need for a dedicated developer.

Regarding the hypothetical pascal developer, it really depends on your need. I’ve been in the position to hire bright people who can learn our tool set on the job, and that’s great. I’ve also been in the position where we can’t afford a month or two while a new dev learns our language an framework before they become productive. When in the latter position, it makes sense to weed people you’re not interested in out early.

I would love it if a well-written job description would prevent unqualified people from applying, but my experience has been that it just doesn’t. That’s why some people use fizz buzz (http://www.codinghorror.com/blog/2007/02/why-cant-programmer...). That’s why we used a short phone screen.

Re: The Programming Interview Experiment

#18

Post by mamcx »

This part is the key, to me:

>The second thing is the strong focus on topics taken from >classroom algorithms and the lack of concern about >practical programming ability. A candidate might somehow >remember that the way to implement an optimal string >suffix matching function is to use a suffix tree, but >where is the question that gauges the ability to create, >test, and deploy a complete application in a reasonable >amount of time? Which skill is more important to you?

Re: The Programming Interview Experiment

#19

Post by danbruc »

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, database or operating system development or some other fancy stuff, no one will care to ask for trivial things like asymptotic runtimes. Personally I think most of the time people - interviewers and article-about-interviews writers - just mention Landau notation because they think it makes them look smart without realizing how trivial it actually is.

Re: The Programming Interview Experiment

#20

Post by fsk »

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.

Post reply on HN