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

141–150 of 570 posts

Re: How to Pass a Programming Interview

#141

Post by ktRolster »

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…

Most likely you think about it, though. When you're coding, and you have a triple loop, do you think, "Oh, this is O(n^3). Is n going to be too big here?"

It may be something that's so intuitively obvious to you, that you don't even think about it. So you naturally use the hashmap, where someone else might try a list and then start doing a lookup in a loop. Then while that particular instance might not break things, it'll slow things down, so overall the application feels sluggish instead of snappy.

Re: How to Pass a Programming Interview

#142

Post by mech4bg »

jenscow wrote: post #133
mech4bg wrote: post #101

Earlier quoted context omitted.

Take out any of that old stuff. It's not necessary. Your resume should fit on one page, two at absolute most, and only include things that you would expect to be grilled on. If you are annoyed about being tested on something on your resume, take it out.

There's no need to be "grilled" on something you did 10+ years ago (unless it's a requirement of the job, of course). Perhaps a "have you used Pascal since leaving ...?" would suffice.

A resume should reflect your current skills and abilities. You should feel free to leave in old positions, and the interviewer can ask about it if they want, but you should not leave in technical things you don't want to be asked about.

Re: How to Pass a Programming Interview

#143

Post by riazrizvi »

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 have come to believe it is part of an industry-wide negging style to keep people in their place.

Re: How to Pass a Programming Interview

#144

Post by lewisl9029 »

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 invested in the interview process in terms of time spent, so interviewers have to value candidates' time because failure to do so will end up wasting their own time as well. In take-home projects, this balance in time investment completely breaks down, and thus there's very little left to discourage interviewers from issuing ridiculously time-consuming projects.

I've done a few of these in the past, mostly to get some practical experience with a new framework & ecosystem I'm not too familiar with yet, but I think in the future I'll likely just politely decline any projects that looks unreasonably time-consuming, or at least try asking for certain adjustments to the spec first.

Re: How to Pass a Programming Interview

#146

Post by akhilcacharya »

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.

Re: How to Pass a Programming Interview

#147

Post by yarrel »

digler999 wrote: post #129
gedy wrote: post #126

"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.

Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".

Social performance stress is not technical performance stress. You can weed out a lot of undesirable work environments by seeing which potential employers confuse them.

Re: How to Pass a Programming Interview

#148

Post by ktRolster »

jdhawk wrote: post #137
steven777400 wrote: post #85

Earlier quoted context omitted.

As a candidate, I feel that it is fair to stand up for this as well. If the interviewer wants psuedocode, I'm happy to whiteboard it. But I've been whiteboarding before and had the interviewer say, "that code wouldn't compile, you're missing a bracket." So I said, "If you want code that compiles, bring in a laptop and I'd be happy to put it in to Visual Studio [it was a .NET position] and have it be syntactically cor…

"This organization uses whiteboards as their Code Editor?" - did not get the job.

But be honest....by that point did you really want it?

Re: How to Pass a Programming Interview

#149

Post by ArtDev »

digler999 wrote: post #129
gedy wrote: post #126

"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.

Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".

This is not how to find people you actually want to work with.

Re: How to Pass a Programming Interview

#150

Post by gedy »

digler999 wrote: post #129
gedy wrote: post #126

"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.

Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".

Maybe - but I've also seen folks who ace that sort of thing be the worst engineers for getting real work done "under pressure", and fiddle around with reinventing the wheel and academic debates about trivial details too.
Post reply on HN