Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

261–270 of 570 posts

Re: How to Pass a Programming Interview

#261

> 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…

Problem is, that there just isn't enough time to evaluate everyone who applies.

In my last job, I was a Director of Engineering at Box. Every job post we put up, had hundreds of applicants (thanks to job-boards which let candidates apply to jobs like putting in a shopping cart). What do you think we, as hiring managers, are going to do at that point? We'll have to start forming biases. And if we have to start forming one, it's better to start with good schools and good companies. (I'm sure VCs have a more severe problem).

Problem gets worse when you're hiring at scale, and you want to hire before the holiday season nears, because if you miss the season, the company is doomed. At that point, there is almost panic. A resume with brand names on it, naturally gets higher preference.

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

#262

> 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…

Which is why you get only upper class people funding upper class people

In my experience it's even narrower than that. In many cases, there is a pre-existing relationship between the investor/founders.

I once met (in a restaurant, because we had kids the same age that were making eyes at each other!) a serial entrepreneur. When we got to know each other he confided that his investors were friends from school (some Ivy league school, don't remember which) that would give him money for some idea, he'd start the company then they'd find a buyer. He'd done this 3-4 times already, and he was about 40.

I know this example is one data point, but I've run across it in other situations, too.

Re: How to Pass a Programming Interview

#263

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…

I remember hearing about take-home projects that amounted to free work for a company rather than a test of the programmer's skills, which is pretty smarmy. Anything can be abused or misused. Anyhow, the disincentive would probably be a decrease in applications if they start piling on the homework. Unless you're offering some amazing compensation and perks, or you're hiring for a project that could make a person's career, fewer people will bother when there are so many other companies out there hiring.

Maybe the least worst answer is to have people who have been through the hoops before, and can empathize with candidates, running the hiring processes.

Re: How to Pass a Programming Interview

#264
At the risk of repeating myself what I've said elsewhere on the page:

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. And a lot of other reasons.

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

Re: How to Pass a Programming Interview

#265
I've been interviewing in the past month as I need to find a new role and it is just crazy.

It is SO random, a lot of useless questions, small startups having a long hiring process harder than the big 4.

Just one example: I've received an offer from one of the big 4 after going through their process. I was lucky in the questions - things I had studied.

I also applied for around 40 start ups / small companies. I made through the final on-site interview in only 5 of them. Lots of white boarding, silly technical questions that don't proxy to day-to-day work and etc.

I really think that passing in a process in a company like Facebook and not passing in other companies working in a much less complex environment says a lot.

Another thing that annoyed me a lot was that in some companies, when I froze upon a problem and was in a dead end, instead of them trying to help me or give constructive advice they would just keep adding pressure. It's craaazy. You're in a white board in a position of someone judging you in a on-the-fly-absurd-problem and the guys is trying to talk you down instead of help.

Crazy stuff.

Re: How to Pass a Programming Interview

#266

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…

Ironically enough, Triplebyte's own take-home projects were some of the worst I've ever had, and did a horrible job of respecting the candidate's time. When I went through the their take-home interview process, there were 4 projects to choose from, with only one having anything remotely to do with my area of expertise (it was a multiplayer game, and I was looking to work as a web front-end/full-stack developer). For…

Now they also tell you that it's OK if you don't finish the project.

Yeah, they always say that -- but it's never really true.

They should just be honest and say "If you don't finish the project in time -- then don't feel bad, but perhaps the test isn't right for you, at this time. Feel free to apply again in 6 months."

Re: How to Pass a Programming Interview

#267
post #213

I hated this article. A good technical interview reveals an aptitude for programming or a lack of same, and can distinguish a true aptitude from an ability to fake it. I've been interviewing programmers for a very long time and I'm pretty good at avoiding "false positive" results with a few straightforward questions. If you have aptitude and talent, brush up on your algorithms and try to have fun with the interview.…

So, you may be right. Perhaps you're great at telling good programmers from bad. But almost no one does the analysis to really know if this is true (false negatives are the huge unknown). And most interviewers are not as good as you. The consistency between interviewers at the same company is low (we measure this). The consistency between different companies is low. We (interviewers) can do better than this!

I make no claims about false negative results. But I know that people that I've recommended hiring have basic analytical skills, can correctly code a Boolean predicate with a few connectives in it, and aren't confused by linked data structures. It's not a high bar that I set, and that's kind of my point: ask at least some low-bar questions! You can debate all day about how well candidates have done with the hard questions, but it's pretty easy to know what to do with those who can't cope with something like "do two (x,y,width,height) rectangles intersect or not?".

Re: How to Pass a Programming Interview

#268

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…

> 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 late…

> Send out the assignment at a predetermined, convenient time and require it be returned an hour or two later.

This honestly sounds like a great idea to me, except maybe with a slightly longer time allowance to remove some of the pressure. Definitely hoping more interviewers will start to adopt this method for take-home interviews.

But this method also hinges on the interviewer's ability to design projects that can be completed in a reasonable amount of time and still give good insight into a candidate's skills. I think it's safe to say this will be a difficult task for most interviewers.

Re: How to Pass a Programming Interview

#269

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…

> 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 late…

> There's also no disincentive for interviewees to spend an unreasonable amount of time on the project.

I don't see any problem with this, as an interviewer. The take-home is supposed to be an example of the work the candidate does, they should take however long to do it. I want to see the best-case scenario of the code they write (given the problem at hand, etc, of course). The entire idea is removing the time pressure.

Post reply on HN