How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#251

Post by rqebmm » Tue, Mar 08, 2016, 9:13 PM UTC

Bahamut wrote: post #239

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…

Whiteboard coding doesn't necessarily have to involve guessing the algorithm - any whiteboard questions I've asked avoided doing so. On the flip side, my experience with take home projects is that they are much more of a hazing/pressure cooker ritual - at the least, the time pressure of a Google/FB/etc. interview lasts only a half hour. Most will expect candidates to spend a huge amount of time, which many won't have…

> I prefer to pour that extra time into open source work, since at the least it benefits others

As someone who pushed his company to adopt a "take home" assignment for our interview process, it should be perfectly reasonable to reply with "here's my commit history on a project relevant to what you're hiring for."

I much prefer giving (and taking) take home assignments because it lets the interviewer see _what someone will actually produce on the job_. If you can do that without jumping through our specific hoops, great. If not, that's why we have the assignment.

It also at least somewhat ameliorates the pressure cooker of an interview, which many people cope with poorly. It can be hard enough to communicate clearly when all eyes are on you, let alone get your thoughts together and solve a logic problem. If that's actually analogous to your work environment, well...

Re: How to Pass a Programming Interview

#252

Post by tobz » Tue, Mar 08, 2016, 9:17 PM UTC

dbcurtis wrote: post #234

When the the job interview become a quiz show? I've spent plenty of time on both sides of the interview table. Sure, I've asked problem-solving questions. It was never to pay stump-the-candidate or to see if they could come up with some CS proof on the fly. It was to examine their approach to problem solving, and the way they interacted (back-and-forth questions). The right answer never entered into it, and if the in…

Is that not a quiz unto itself? The whole thing of "just trying to understand how the candidate thinks" is yet another pseudo-psychological analysis by someone who is almost certainly not a psychologist.

The whole approach is ruined by the simple premise of someone being caught off-guard, or introverted. It feels a lot like self-masturbation to pretend to be able to objectively measure the quality of someone's day-to-day value by examining how they approach a problem.

Re: How to Pass a Programming Interview

#253

Post by BinaryIdiot » Tue, Mar 08, 2016, 9:17 PM UTC

cema wrote: post #241

BinaryIdiot wrote: post #114

> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte. Thank you! This is a good write up and just like it concludes it's far from ide…

Honestly though my biggest issue with interviews is the lack of response with a negative result. Exactly mine too. However: If something is wrong with a candidate and they don't fit that's perfectly fine. But please give them accurate and detailed feedback where possible. Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decisio…

> Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decision is a matter of balancing so many different points.

You're right but if a candidate is going to spend hours or days working with your company I think it's the least they deserve. If there is a legitimate reason for not hiring them I'd like to think litigation would be rare.

I mean when you work with a sales guy to buy something and ultimately don't buy you usually tell them why especially if you've been working with them for days. The inverse is true as well if you decide not to sell a product to someone. It just seems weird to me that a person can spend so much time with a company and possibly not even get a good learning experience out of it (when you're left with the impression that everything went as smooth as statistically possible and then you're declined without any useful data how do you know how to improve if at all? Hell maybe someone was just better than you or they decided they needed something else for the job; telling the person could save them so much trouble).

If you want someone to spend hours or days trying to join your company I feel like you should be able to give them feedback. I don't like the trend of big companies not giving anything. Interviewing is a two way street but there is just a weird stigma or legal worry preventing feedback.

Re: How to Pass a Programming Interview

#254

Post by rhinoceraptor » Tue, Mar 08, 2016, 9:17 PM 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…

> there's very little left to discourage interviewers from issuing ridiculously time-consuming projects

There's also no disincentive for interviewees to spend an unreasonable amount of time on the project. So the test is biased against employed people and/or people with kids.

This can be easily countered though. Send out the assignment at a predetermined, convenient time and require it be returned an hour or two later.

Re: How to Pass a Programming Interview

#255

Post by soham » Tue, Mar 08, 2016, 9:18 PM UTC

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…

Homework projects could work well if the hiring requirements are small, but won't work well when a company has to hire say 25 engineers a quarter, which we had to. At that point, the process becomes too long, and it's easy to lose good candidates to a long process.

This method of interviewing has been around ever since, and is going to be around for the foreseeable future. Nobody loves it, including the interviewers, but there just isn't a better way to do it at any sort of scale. Especially when there are much bigger problems to solve when you're running a business.

It's best to take the bull by the horns. I run http://InterviewKickstart.com, which is a bootcamp for preparing for such technical interviews. We do almost exactly what is in the blog post. It works. Spectacularly.

Re: How to Pass a Programming Interview

#256

Post by [deleted] » Tue, Mar 08, 2016, 9:20 PM 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…

[deleted]

Re: How to Pass a Programming Interview

#257

Post by anon4 » Tue, Mar 08, 2016, 9:21 PM UTC

garrettgrimsley wrote: post #164

esses wrote: post #131

Earlier quoted context omitted.

i often just refer to it as waterboarding.

Have you ever been waterboarded? Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.

Have you ever minimized a horrific experience? Putting an innocent metaphoric hyperbole on the same level as denying the holocaust makes you literally Hitler.

Re: How to Pass a Programming Interview

#258

Post by xsmasher » Tue, Mar 08, 2016, 9:22 PM UTC

nilkn wrote: post #62

ionforce wrote: post #30

Earlier quoted context omitted.

I've had people interview claiming to know X and then not code in X correctly. So... that's a red flag. We allow interviewees to pick their strongest language. But if you end up picking something that doesn't exist, well, you aren't earning yourself any points.

> But if you end up picking something that doesn't exist, well, you aren't earning yourself any points. I don't know about your personal interviews, but I'd find this reasoning slightly strange if I were being asked to write computer code on a whiteboard. I'd find it much less strange if I were actually handed a laptop to write a functioning program on. Expecting perfectly correct code on a whiteboard seems to me to…

To "not code in X correctly" is ambiguous, but I assume/hope the parent poster means that someone makes fundamental, non-syntax errors in their code - in C++ this would be something like returning a pointer to an object that's on the local stack.

If you're trying to filter for people can be productive in a particular language from anyone else, that's what you need to look for.

If you let the candidate pick their strongest language and they still make fundamental errors, you know they're not going to be immediately productive in any language.

Re: How to Pass a Programming Interview

#259

Post by entitycontext » Tue, Mar 08, 2016, 9:22 PM UTC

cableshaft wrote: post #211

entitycontext wrote: post #165

It seems like there is a large middle area of concepts in between low-level algorithms/data structures and high-level system architecture that are left out of many of these interview prep guides: * Principles and patterns of object-oriented (or functional) design * Relational (or NoSQL or analytics) database design * Unit, integration and system testing * Logging, profiling and debugging * Source control (e.g. branch…

From my experience, if they do come up, it's only because I was asking them what they used. I don't think I've ever been asked about any of these topics, with the exception of database design.

It's a shame, since these topics could make for a rich conversational interview that probably has more to do with the actual job than whiteboarding an algorithm. Just taking source control as an example, a hypothetical interview question could be something like:

"You've been assigned to implement feature X in our product. Assume that the specs are clear and you have a pretty good idea what code you are going to write. Also, assume that your teammates Joe and Jane have been assigned features Y and Z respectively with roughly the same due date as your feature. Ideally, describe how you would make your changes, test them and coordinate with your teammates to get all three features merged into the master source code."

Obviously a lot of details are missing, but they can be fleshed out in conversation (during which the interviewer should also describe the current process used on the team the candidate is being hired for). This would give both parties some insight into experience and expectations.

Re: How to Pass a Programming Interview

#260

Post by thenewwazoo » Tue, Mar 08, 2016, 9:24 PM UTC

richardwhiuk wrote: post #199

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…

Doesn't that support the fact that it is a meritocracy? Is it not reasonable to expect that top companies and top schools are more likely to employ people who have more applicable talent and skill? At the end of the day, going to a top university or working at an impressive company is always going to be a huge and relevant signal. It's difficult to see a problem with that.

No, because

> for a given level of performance on our credential-blind screen