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

341–350 of 570 posts

Re: How to Pass a Programming Interview

#341

Post by captain_trips »

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

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 a big line in the sand on that one...

Re: How to Pass a Programming Interview

#342

Post by gaza3g »

Joky wrote: post #320
ammon wrote: post #309

Earlier quoted context omitted.

I am sorry that you had a bad experience with us. Evaluation is a really complicated thing. The bar that we use for evaluating the take-home project is to treat it as real work, e.g. would a teammate feel good if you were working with them on this task, and you came back after half a day with this. Because we can't see process, all we can do on the take-home track is judge of the finished result is professional-level…

Just curious: are you making sure your interviewer are actually first trying to code the project in 3 hours before judging candidates? I mean, it seems to me that most of my colleagues (and myself) are always very optimistic with respect to "how long it will take". So if you are judging someone based on your expectation without having went through it yourself, it can lead to a perception gap.

This is a good question because I find that my colleagues from previous companies spent a lot of time thinking of 'good ' interview questions and leave it at that.

None of them actually tried solving it within the constrains that a candidate is put through.

Re: How to Pass a Programming Interview

#343

Post by digler999 »

EpicEng wrote: post #220
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…

That's fine, as long as you _never_ need to trust said dev to do anything complex. It's fine to have mediocre developers perform mediocre tasks, but if you want more from them someday you may be in trouble.

to me, complex, and complex-ITY are entirely different matters. I want a smart programmer who can figure out really complex bugs (something you cant figure out from google/wikipedia). Not someone who memorized the big-O performance tables of 8 different data structures (something you CAN look up on wikipedia ).

Re: How to Pass a Programming Interview

#344

Post by captain_trips »

akhilcacharya wrote: post #146
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…

Gotta say, this is incredibly discouraging for someone like me.

Naw - places that hire like that are myopic are shitty and doomed, so you don't want to work there anyway. If you're a good coder and not a complete dick, you can build a nice career for yourself.

Re: How to Pass a Programming Interview

#345

Post by buzzdenver »

megablast wrote: post #323
thearn4 wrote: post #193

Earlier quoted context omitted.

> I much prefer "homework" projects I helped a group within my organization with their hiring process recently, and we had pretty good success with assigning a short "take-home" exercise, vs. trying to haze them with a programming problem over a google hangout interview. A problem focusing on a small part of what that group does, but scoped to be doable with 1-2 hours of work.

I guess it works well for people unemployed with nothing else to do, no family, lots of time. Everyone else, this sucks!

Interviewing does take time. Most people will be able to spare an hour to find a new job.

Re: How to Pass a Programming Interview

#346

Post by digler999 »

pessimizer wrote: post #200
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…

Honestly, I consider an instinct for complexity analysis the most important thing I learned in school, and the thing that I've gotten the most use out of. I don't know what case you're making here: are you saying that high-level architecture is so hard that choosing a map or a hashmap should be a coinflip, or the one you see first? Having had some criteria for making the choice makes my life a lot better when everybo…

To me it was a bunch of rote memorization, just like a biology course. I never - never - have needed to know how bubblesort/heapsort/mergesort actually work, except to appease interviewers.

I'm not saying I'm pro writing-inefficient-code, but if you want to talk big-O during an interview, I"m going to roll my eyes about as much as you asking me who the 19th president was.

Re: How to Pass a Programming Interview

#347

Post by krackers »

eranation wrote: post #33

If you have an unbounded abundance of good candidates, it is a different story then when you are a new startup fighting for talent. At highly targeted companies such as Google, Facebook et al, I'm sure that if they have a dryspell of good candidates in a given month (can't think of a reason why), then they revert to things like: "We don't care if you don't get the 'trick' immediately, we'll give you hints" and "we ju…

>But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps)

Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions?

> finding if an unsorted list of numbers is an arithmetic series with just O(1) memory

Is the strategy to solve this to first find the common difference `d` with one pass through the array (by finding the largest and smallest) and then sweeping through one more time xor-ing each element a[i] with a[i] + d and checking if the result is equal to the (minimum) xor (maximum + d)?

Re: How to Pass a Programming Interview

#348

Post by plasticchris »

digler999 wrote: post #128
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…

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

This can happen even on small systems. I once replaced a O(n^4) with O(n^2*ln(n)) on an embedded target which made a minutes long user facing process take seconds. The catch is that the original used a good algorithm, but made an implementation error which I caught in profiling. So complexity analysis is good, but the only way to get better at something is to measure it.

Re: How to Pass a Programming Interview

#349

Post by Can_Not »

vkjv wrote: post #10

> "That’s exactly the point. These are concepts that are far more common in interviews than they are in production web programming." The list includes things like Big-O analysis. While, formal analysis is certainly not a day to day occurrence of most programming, knowing what the runtime complexity of the code you are writing is almost always important. While, I generally don't care for most algorithmic problems, I a…

I strongly agree here. I wouldn't want someone to implement the "get it done version" of a request, where I am expecting a rushed implementation to be O(n^2), then somehow this dev produces an unmaintainable mess that performs in O(n^2n+api.Google.com*n).

Re: How to Pass a Programming Interview

#350

Post by gerbilly »

I was saying to someone the other day that timed programming tests (codility seems popular) are really just youth tests.

They are meant to weed out older programmers, in favour of younger cannon fodder...I mean candidates.

Post reply on HN