How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#431

Post by jroseattle » Wed, Mar 09, 2016, 5:41 AM UTC

"They eat large sprawling problems for breakfast, but they balk at 45-min algorithm challenges."

Care to guess what we're looking for in screens and interviews?

Some of our best performers were poor interviewers. Likewise, we've had interview aces not pan out. Rather than expecting the world to become interview clones (and make our hiring decisions even more difficult), we're learning how to be better interpreters of people to get to the answer of our real question -- is this person an engineer we'd like to have on our team?

It's still a work-in-progress and we're nowhere near perfect, but we're simply not going to outsource our decision-making to the status quo of technical interviewing in 2016.

Re: How to Pass a Programming Interview

#432

Post by progproprog » Wed, Mar 09, 2016, 5:43 AM UTC

If you can't talk about design implications quantitatively, nor have a rigorous understanding of how to build data structures - not memorize anything - you can't get mad that I make $100,000 more than you do and work half as much.

If you're a career programmer, and you've never bothered to hone these skills, don't be surprised when you can't easily find work in 10 years. The cheaper guy or girl who comes with less risk will beat you.

Re: How to Pass a Programming Interview

#433

Post by jroseattle » Wed, Mar 09, 2016, 5:48 AM UTC

staunch wrote: post #108

> candidates who have worked at a top company or studied at a top school go on to pass interviews at a 30% higher rate than programmers who don’t have these credentials (for a given level of performance on our credential-blind screen). Welcome to Silicon Valley meritocracy. And it's much worse for founders seeking investment, where there are no hard skills to test at all. It's almost purely about being the same class…

We flat-out ignore credentials in hiring decisions.

If an elite school is intended to signal competence and brilliance in someone, then those qualities should shine through in a candidate without us having to know where they attended college.

Simply stated: we're hiring you, not your certificate.

Re: How to Pass a Programming Interview

#434

Post by rockshassa » Wed, Mar 09, 2016, 5:58 AM UTC

lewisl9029 wrote: post #144

quanticle wrote: post #72

Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…

I personally also prefer take-home projects over being grilled on my ability to solve obscure algorithms problems under pressure. However, this second route also comes with a number of issues. The most annoying of which in my experience is the amount of time investment each interview requires from the candidate. At least in the traditional technical interview, interviewers and candidates tend to be roughly equally in…

Take-home projects can be a double edged sword... for a given project that is estimated to take 4 hrs, i will typically spend about 16 hours on it. working straight through the night, chugging coffee and/or beer. I work by banging out an ugly PoC, and then I refine it drastically over several iterations. My final versions are award-worthy, but the early ones are really bad and sloppy. I am the type that is great at simplifying, but bad at coming up with the initial statement.

Re: How to Pass a Programming Interview

#435

Post by progproprog » Wed, Mar 09, 2016, 6:02 AM UTC

If you're given a take home project and you take a lot of time on it, it's usually a signal that we shouldn't hire you. We're not using you for free work, and if you think your take home project is assigned in that vain, then you're probably not qualified for the job. It's great personal work ethic when you tell us you worked super hard and spent a week on it, but we give you the expected time so you can filter yourself out. Also, shame on you because it makes us feel shitty to have to reject you after that.

Re: How to Pass a Programming Interview

#436

Post by tedmiston » Wed, Mar 09, 2016, 6:13 AM UTC

methodover wrote: post #219

Interesting article. For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them. We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonde…

Take-home projects are just a more complete and accurate representation of the development experience someone would have on the job. You have much more data about them than a 30-60 minute live coding session.

Though my current company doesn't do them, I was hired for a previous position from a take-home project and generally support them. As an engineer, I'd rather put more effort into a smaller number of take-home projects than a larger number of live coding sessions...

Re: How to Pass a Programming Interview

#437

Post by tedmiston » Wed, Mar 09, 2016, 6:16 AM UTC

BoysenberryPi wrote: post #115

I've interviewed for a lot of YC companies and companies that frequently post in the "who's hiring" thread and the programming interviews they give are absolutely horrendous. I've had programming test where companies look at my resume and go "so you are very experienced in Ruby? Great, solve these algorithms in C++ for us. I've actually had someone give me a ACM-ICPC world finals question. I don't have a problem with…

I think the interview questions and process they choose has more to do with the founders' backgrounds than anything about YC itself.

Re: How to Pass a Programming Interview

#438

Post by autarch » Wed, Mar 09, 2016, 6:20 AM UTC

bogomipz wrote: post #430

autarch wrote: post #376

Earlier quoted context omitted.

> Which can be easily countered by having one of their own team members sit down and take the test first. But of course, none of these places ever do that. At my employer we send out homework exercises, and I personally did the backend developer exercise before we sent it to anyone. I did this specifically to test how long it took. (For the frontend exercise, we didn't have anyone skilled enough on staff to do it, wh…

It took a few hours and "it really was an easy piece of work?" How considerate of you. Who was it an an easy piece of work for, someone with unlimited free time. An unemployed person. What a joke. Any problem is easy when you yourself contrive it. Here's an idea, how about you pay someone for the 3 hours or work you are giving them. Say a lot about you.

I would prefer that we pay people to do this, but unfortunately that's not my call. That said, no one seems to complain so bitterly about the all day interviews that places like Google do (and insist you fly out for in person).

Isn't asking people to fly out for 6-8 hours of interviews (which effectively takes 3 days minimum out of your life) a much greater burden than spending 2-3 hours on some coding which you can do at a time of your choosing? (Followed by 2-3 hours of video chat interviews spread across multiple days, no flying required).

Also, just to clarify, the homework problem is _not_ something related to our business. The solutions are of no business value to the company.

Re: How to Pass a Programming Interview

#439

Post by tedmiston » Wed, Mar 09, 2016, 6:21 AM UTC

gurgus wrote: post #228

Late to the party but I'll just add in my $0.02 I remember the best interview I had was at a company offering open source software. For the coding components of the interview they give applicants a task (they cherry pick one of the easier ones) from their JIRA backlog and told applicants they've got two weeks to come up with a patch. It didn't matter if the applicant could fully solve the bug/feature, since it's not…

This is interesting because without knowing how their system is architected or designed, it allows you to state assumptions and you can use that time to assert knowledge of best practices of a given framework. Sort of an implicit test for depth though.

Edit: I missed where you said open source company. Though I still think this thought for a closed source company that uses open source pieces (like a web framework) could be useful.

Re: How to Pass a Programming Interview

#440

Post by nevon » Wed, Mar 09, 2016, 6:23 AM UTC

kylequest wrote: post #419

lewisl9029 wrote: post #144

Earlier quoted context omitted.

I personally also prefer take-home projects over being grilled on my ability to solve obscure algorithms problems under pressure. However, this second route also comes with a number of issues. The most annoying of which in my experience is the amount of time investment each interview requires from the candidate. At least in the traditional technical interview, interviewers and candidates tend to be roughly equally in…

> At least in the traditional technical interview, interviewers and candidates tend to be roughly equally invested in the interview process in terms of time spent Not really true unless you go to your interviews completely unprepared :-)

As the interviewer, I'm not going to show up unprepared either. Typically, having an interview means learning about the candidate and what would be interesting to talk to them about, learning what team they might be a good fit for and what they need, and syncing with the other interviewers to make sure we're on the same page. And then afterwards, we'll meet up to discuss how the interviewee did and whether or not we should hire them.

All in all, it's at least an hour of prep time needed, and that's only counting my time, not the time of the other interviewers, managers and recruiters.