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

121–130 of 570 posts

Re: How to Pass a Programming Interview

#121

Post by azakai »

silverdrake11 wrote: post #103
kelvin0 wrote: post #14

What if designers had to go through a similar interview process? Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? Why is red font on blue background bad, please justify? That would simply be hilarious.

Designers have portfolios where the interviewer can see the previous work they've done

Many developers do these days too, if they work on open source projects, or if they have significant side projects that are open source.

I definitely look at open source code of job applicants, and sometimes a part of the interview is asking them about it.

Of course that has downsides too, like anything.

Re: How to Pass a Programming Interview

#122

Post by jlarocco »

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…

> But the VAST majority of the programming work out there does not require any Big-O analysis. It just does not.

I just don't agree with this. Maybe it's true for people doing strictly front end web development (i.e. pure HTML and CSS), but basic algorithm analysis comes up all the time when writing any kind of real code.

I think your attitude is actually part of the reason software sucks so bad nowadays. People act like efficiency doesn't matter at all and Big-O is useless and then turn around and act surprised when browsing a website causes Firefox to use 800 Mb of RAM, or their top of the line server only handles 50 connections a second. There's a connection there.

Re: How to Pass a Programming Interview

#123

Post by sotojuan »

mtford wrote: post #105
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…

I feel ya buddy - come and join the wacky world of front end development where these things matter less ;)

I wish. I've been asked these kinds of questions for jobs that are just gluing libraries to JSON coming from a backend.

Re: How to Pass a Programming Interview

#125

Post by rhodysurf »

alistairSH wrote: post #82
jkarneges wrote: post #25

Earlier quoted context omitted.

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.

Ack. I'm not sure how I'd react to that. I interviewed quite a bit last year (on the hiring side). I was really surprised by the variation in pseudocode written by the candidates. Most wrote something JavaScript-like, a few stuck to mostly proper Java or C. But then one dumped a giant web of crazy on the board (but still made his point) and one wrote something that looked suspiciously like COBOL - still not sure if h…

I always write a weird mashup between python and C for some reason haha

Re: How to Pass a Programming Interview

#127

Post by ape4 »

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…

In Java this prints -4

    int [] nums = { 2, -2, 0, 0 };
    int dup = findDupe(nums);
    System.out.println("dup="+dup);

Re: How to Pass a Programming Interview

#128

Post by digler999 »

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 it makes absolutely no difference whether you use a list or a vector, or else you'll get the paradoxical "vector-is-always-faster" because of locality of reference.

In my (admittedly limited ) experience, most of the effort is spent simply making it work, not being bogged down because you used a map instead of a hashmap, or didn't know about some esoteric, bleeding-edge probabilistic data structure.

Re: How to Pass a Programming Interview

#129

Post by digler999 »

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

Re: How to Pass a Programming Interview

#130

Post by vonmoltke »

quanticle wrote: post #57
ammon wrote: post #13

Earlier quoted context omitted.

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…

But the VAST majority of the programming work out there does not require any Big-O analysis. Your point is simultaneously valid and irrelevant. The vast majority of programming doesn't involve any Big-O analysis. But if you can't do Big-O analysis, there are problems where you will be stuck. Your code will be running slowly and you won't know why, and all the micro-optimizations in the world can't make a O(n^2) algor…

> But if you can't do Big-O analysis, there are problems where you will be stuck. Your code will be running slowly and you won't know why, and all the micro-optimizations in the world can't make a O(n^2) algorithm run faster than an O(n) algorithm on even a moderately large data set.

This may be a result of the domains I have worked in, but I have never encountered a situation where I could change the order-of-growth on an algorithm. In fact, most algorithms I have worked with have been defined by non-computational performance.

I don't know formal complexity analysis, and personally think the resolution of Big-O is far too coarse for practical analysis anyway. I can still look at any piece of code and give you approximate polynomials for its runtime, memory requirements, and other computational features.

Post reply on HN