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

171–180 of 570 posts

Re: How to Pass a Programming Interview

#171

Post by drakenot »

osagatisop wrote: post #49

I really wish that at some point during my CS education I would have realized how typical programming interviews worked and just how impossible they are for me. None of my internships had this sort of stuff and after a long string of failures interviewing after graduating, I can openly admit that being able to solve algorithm stuff just isn't in my blood. It doesn't matter how many books I read or questions I practic…

Don't get discouraged. Many companies don't do these kinds of interviews.

I've been in almost a dozen programming interviews and maybe only 1/3 of them have taken the shape of programming whiteboard problems.

Many just asked general technical questions or questions about my particular stack with no whiteboard problems.

The remainder of them hardly asked any technical questions at all beyond asking about my experience and background.

I'm not saying that those companies gave good interviews, but there is a lot of work out there for people who can't pass whiteboard interviews.

Re: How to Pass a Programming Interview

#172

Post by kafkaesq »

mech4bg wrote: post #101
kafkaesq wrote: post #56

Earlier quoted context omitted.

I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.

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.

I see what you're getting at.

I still think that in general, people who can't be bothered to read important documents, and instead just eyeball them for keywords (and start shooting off questions accordingly) -- aren't my cup of tea to work with, anyway.

Re: How to Pass a Programming Interview

#173

Post by zimbu668 »

brobinson wrote: post #154
zimbu668 wrote: post #55

Earlier quoted context omitted.

Maybe I'm missing something but isn't N+1 the difference between O(1) and O(n)? Edit: Anyone want to explain how I'm wrong rather than just downvoting? Edit 2: Understanding a N+1 problem is the equivalent of understanding the difference between O(1), i.e. fetch all data with a constant number of queries, versus O(n), i.e. the number of queries scales linearly with the number of elements.

It's this: https://secure.phabricator.com/book/phabcontrib/article/n_pl...

Yes, and when you solve your N+1 problem, you've replaced a O(n) algorithm with a O(1) algorithm.

Re: How to Pass a Programming Interview

#174

Post by zimbu668 »

skj wrote: post #159
zimbu668 wrote: post #55

Earlier quoted context omitted.

Maybe I'm missing something but isn't N+1 the difference between O(1) and O(n)? Edit: Anyone want to explain how I'm wrong rather than just downvoting? Edit 2: Understanding a N+1 problem is the equivalent of understanding the difference between O(1), i.e. fetch all data with a constant number of queries, versus O(n), i.e. the number of queries scales linearly with the number of elements.

Because your question makes so little sense that it seems sort of like a joke.

Thanks for your comment, I've tried to clarify things.

Re: How to Pass a Programming Interview

#175

Post by skj »

forgetsusername wrote: post #134
pklausler wrote: post #78

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

> I'm pretty good at avoiding "false positive" results And you know that...how exactly?

Because a false positive is very visible - you've got a terrible engineer bringing everyone down.

It's the false negatives that are harder to detect...

Re: How to Pass a Programming Interview

#176

Post by nsxwolf »

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.

Not many people have been waterboarded, and most were terrorists, so it's not the same as a holocaust joke. In a world where we're not allowed to laugh at anything connected to some kind of injustice, then yes, that wasn't funny.

But I laughed.

Re: How to Pass a Programming Interview

#177

Post by [deleted] »

ammon wrote: post #13
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…

So, I see where you are coming from (I actually love academic CS). But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not. It's used as a tool in interviews to (essentially) look for rigor. The problem is that this harms people who are rigorous as hell in low-level details of JS and V8 (something I'd posit is actually more useful to many more companies), but neve…

[deleted]

Re: How to Pass a Programming Interview

#178

Post by seanp2k2 »

mech4bg wrote: post #101
kafkaesq wrote: post #56

Earlier quoted context omitted.

I've had interviewers look at an unweighted keyword digest from my resume, apparently without reading said resume (which clearly states my current skill focus on the top, which has evolved quite substantially over time). And then start "grilling" me on a language that appeared on a job description from 10+ years ago.

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.

It's interesting that different companies will want different things on a resume. This is why no two jobs I've applied for get the same resume. If they want lots of experience in a lot of different things, sometimes they DO want the laundry list of acronyms (make sure you know what they all stand for). You might not even get through the first selection if they use XSLT heavily and you didn't think it was relevant that you had worked with it before on a project.

I've also had interviewers rip the other pages out of my resume in front of me, but everyone is different. At the end of the day, don't feel too bad about not getting an offer. A lot of it is luck.

Re: How to Pass a Programming Interview

#179

Post by SilasX »

ionforce wrote: post #30
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.

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.

It depends on what "not code in X correctly" means. If they missed a few syntactical things, it's fine. If they're obviously still "thinking in a different language", then no. For example, if you ask them to loop over a list of items in Python, they shouldn't write:

    for i in range(len(items)):
        do_stuff_to(items[i]))
Post reply on HN