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

How to Pass a Programming Interview

blog.triplebyte.com

Post reply on HN
Print view View original

371–380 of 570 posts

Re: How to Pass a Programming Interview

#371

Post by [deleted] »

rhinoceraptor wrote: post #278
draw_down wrote: post #269

Earlier quoted context omitted.

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

Right, but workaday programers with two kids and a full time job won't be willing or won't be able to spend, say more than two hours on something like this.

[deleted]

Re: How to Pass a Programming Interview

#372

Post by nathanaldensr »

soham wrote: post #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 t…

You've copy-pasted the exact same text several times in this thread already. Your worry about repeating yourself is justified. This seems like blatant advertising to me.

Re: How to Pass a Programming Interview

#373

Post by lewisl9029 »

nsxwolf wrote: post #302
lewisl9029 wrote: post #268

Earlier quoted context omitted.

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

A day or two should honestly be fine. Have them talk about the solution after turning it in. It's a lot easier and more interesting to talk about code you just wrote than it is to make someone whiteboard something on the spot. It doesn't need to be a time trial. If you're impressed with the code and hire the candidate, worst case is you get someone who takes a little more time but writes great code.

The time requirement doesn't just set a limit for the candidate though, it also serves as a limit to consider for the interviewer when speccing out the project.

Having a time limit of a day or two is fine if the actual project should reasonably take a couple of hours, but if the project actually takes more than a whole work day to complete, then that's a different story (in my humble opinion, anything that would take more than a couple of hours is an unreasonable demand on the candidates time unless you offer some kind of compensation).

Re: How to Pass a Programming Interview

#374

Post by Buttons840 »

jkarneges wrote: post #25
alistairSH wrote: post #20

Earlier quoted context omitted.

Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.

This happened to a friend. He confirmed that pseudocode would be acceptable, but then as he was writing it out the interviewer got on him about not terminating lines with semicolons (I suppose the pseudocode looked C-ish). So yeah I'd say make this clear.

"Shame! You're not terminating your pseudo-code with semicolons!!!"

I'd respond to that by drawing one huge semi-colon that spanned all 20 lines of pseudo-code.

Re: How to Pass a Programming Interview

#375

Post by RogerL »

jerf wrote: post #139
digler999 wrote: post #128

Earlier quoted context omitted.

> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…

"Or had to find the O(x^n) and replace it with O(x^2)" The other thing that really seals the deal for me as an inferior interview question is that you don't need to have a clue what O(x^n) is to wrap some code in a simple time call, see that the code you think ought to run in microseconds is running in seconds, by visual inspection notice stupid nested loops, and fix it. Self-taught programmers may not be able to say…

Big O took about 15 minutes to teach. Sure, it went on and on a bit because a rigorous class will introduce proofs, but you are absolutely right - it's a trivial concept, and often flawed in practice (list is supposed to be faster for random inserts/deletions according to big O, but in practice they are almost always slower).

Re: How to Pass a Programming Interview

#376

Post by autarch »

kafkaesq wrote: post #273
rhinoceraptor wrote: post #254

Earlier quoted context omitted.

> 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. Except that these places very frequently tend to either (1) misstate the problem in some major or minor way, or (2) wildly underestimate the time required to produce a professional quality, bug-free, bulletproof-tested solution. Which can be easily countered by having one of their own team members sit down and…

> 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, which is why we were hiring a frontend dev).

Re: How to Pass a Programming Interview

#377

Post by Someone »

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…

"But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm"

No, but it may be a good question, anyways. A good interviewer probes you about things you might encounter in the job to find the point where you cannot recite things, and looks how you handle that.

Having said that, I don't understand the focus on coding interviews I read on HN. I don't know whether it is cultural difference between the USA and Europe, whether I just haven't noticed how you are supposed to prepare for interviews, or whether I am too smart to need to bother, but when I apply for a job, I look up what the company does, try to figure out what its culture is, but do not prepare for the technical side of things. An interview isn't a one-sided affair of you being quizzed, it is two parties figuring out whether they fit together,

Re: How to Pass a Programming Interview

#378

Post by sk5t »

fortpoint wrote: post #271
VLM wrote: post #245

Earlier quoted context omitted.

My shipping boxes hold an even number of widgets, but I "have to" sell odd quantities and those need expensive mil spec styrofoam peanuts added to fill the hole. Here, have an array of possible shipment sizes. Given that array, if its shipping an odd number of widgets I wanna add an additional half widget shipping charge. newshipping = oldshipping.select{|i| i % 2 == 1 }.map{|i| i + 0.5 } My ridiculous fictional writ…

In Java it would look like this: List newshipping = oldshipping.stream().filter(i -> i % 2 == 1).map(i -> i + 0.5d).collect(Collectors.toList()); a bit more verbose but the essential chaining idea is there...

The above, only if you want to discard (filter) orders with an even number of things.

Also I'm not sure about the use of floating point here...

Re: How to Pass a Programming Interview

#379

Post by soham »

captain_trips wrote: post #341
soham wrote: post #261

Earlier quoted context omitted.

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…

I dunno - part of leading an eng group is taking heat to do the right thing. I've been in the growth phase a few times now, been under tremendous pressure rapidly build a team. Taking the time to find the right people is absolutely key - better to hold off then get the wrong people in. Maybe it's because I've seen complete dipsh?t Stanford and MIT grads or maybe it's because I didn't go to a marquee school, but I put…

Taking the time to find the right people is absolutely the key, but the unwritten part of the rule, is not to do that at the cost of business. Better to hire engineers who are good enough, than to miss the holiday season.

The process of DS/Algos doesn't necessarily find wrong people. It's just the fastest way to find engineers who are good enough.

In some sense, they almost secretly WANT you to succeed, by "standardizing" the process.

Post reply on HN