How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#151

Post by jerf » Tue, Mar 08, 2016, 8:09 PM UTC

bshlgrs wrote: post #34

ajeet_dhaliwal wrote: post #17

Earlier quoted context omitted.

Good point, I've encountered this. Some candidates unfamiliar with the process may not even realize they want you to ask that, I didn't know when I started out and used to think a good interviewer would specify what they want, that may not be true, although it would be a nice thing to remind a candidate they can ask for clarifications not just about the question but about testing and such. I know some interviewers ma…

I also think that it's not obvious that the interviewer is doing the wrong thing here. The claim "good programmers should always think to guard against invalid input" isn't ridiculous on the face of it: maybe checking for valid input is a sign that they're careful and methodical, and of course you want to hire careful and methodical people! Or the other way around: I can imagine someone thinking "this person spent ag…

If you think my code's checking carefully for the validity of the input makes it bloated and ugly, you just failed my interview.

Re: How to Pass a Programming Interview

#152

Post by ktRolster » Tue, Mar 08, 2016, 8:09 PM UTC

BoysenberryPi wrote: post #115

I've interviewed for a lot of YC companies and companies that frequently post in the "who's hiring" thread and the programming interviews they give are absolutely horrendous. I've had programming test where companies look at my resume and go "so you are very experienced in Ruby? Great, solve these algorithms in C++ for us. I've actually had someone give me a ACM-ICPC world finals question. I don't have a problem with…

I've actually had someone give me a ACM-ICPC world finals question.

What company, do you mind if I ask?

Re: How to Pass a Programming Interview

#153

Post by mech4bg » Tue, Mar 08, 2016, 8:09 PM UTC

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…

I've seen this plenty of times. I've worked both on a trading platform and a large website, and both times encountered many performance issues that were solved with a more appropriate algorithm or data structure. I've even seen this with a list as small as 10 items - a O(n^3) algorithm was making multiple network calls each time; changing it to O(N) alone made a huge improvement in speed.

Re: How to Pass a Programming Interview

#154

Post by brobinson » Tue, Mar 08, 2016, 8:09 PM UTC

zimbu668 wrote: post #55

h0w412d wrote: post #23

Earlier quoted context omitted.

I'd have to disagree. I think the interview process desperately needs an injection of pragmatism. If the actual job never requires Big-O analysis, then asking it during the interview is a waste of time. I've never had to do Big-O analysis in the real world, but I have had to fix N+1's. Ask about that.

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

Re: How to Pass a Programming Interview

#155

Post by ammon » Tue, Mar 08, 2016, 8:10 PM UTC

ape4 wrote: post #127

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);

This only works if the numbers are in a known range (say sequential from 1 to 100), and you XOR in the index (plus 1) as well. Then each number is XOR'd two times, except the duplicate, which is XOR'd 3 times (and thus remains at the end). The fact that the code is wrong shows why this question is a very bad interview question.

EDIT

The given code works to find the only non-duplicate item in a list (perhaps that was what was intended)

Re: How to Pass a Programming Interview

#156

Post by forgetsusername » Tue, Mar 08, 2016, 8:10 PM UTC

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…

>To make an analogy with driving

The whole point of the argument is the difference between what's on the test and reality, though. And simply "being on the test" doesn't make it valuable.

Needing to parallel park on the driving test has little relation to you being a good driver. In reality, your actual ability to park is hardly relevant, because you could avoid those parking spaces, or even half-ass it by driving in forward, or whatever.

Re: How to Pass a Programming Interview

#157

Post by Alex3917 » Tue, Mar 08, 2016, 8:11 PM UTC

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…

> Your code will be running slowly and you won't know why

Ever hear the expression "tools, not rules"? Using big-O analysis while coding is almost the textbook definition of what makes someone a bad developer.

That's of course not true if you're developing some foundational tool meant for other developers like Redis or whatever, but for the average developer doing complexity analysis at work is probably a red flag that they're prematurely optimizing their code, using company time to work on a side project, or otherwise doing something that's not contributing to the success of the business.

Re: How to Pass a Programming Interview

#158

Post by runT1ME » Tue, Mar 08, 2016, 8:11 PM UTC

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…

I don't know what other industry you have experience in, but this is fantastic compared to the rest of the world. In 'soft skill' jobs, I'd bet the house that credentials, prestige, and 'reputation' end up doing a lot more than a 30% higher acceptance rate.

Should we improve it further? Absolutely, but to pretend that this isn't better than other industries is silly.

Re: How to Pass a Programming Interview

#159

Post by skj » Tue, Mar 08, 2016, 8:11 PM UTC

zimbu668 wrote: post #55

h0w412d wrote: post #23

Earlier quoted context omitted.

I'd have to disagree. I think the interview process desperately needs an injection of pragmatism. If the actual job never requires Big-O analysis, then asking it during the interview is a waste of time. I've never had to do Big-O analysis in the real world, but I have had to fix N+1's. Ask about that.

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.

Re: How to Pass a Programming Interview

#160

Post by jorgecurio » Tue, Mar 08, 2016, 8:12 PM UTC

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…

> 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 as the investor.

yeah I figured this was how things happened :/

but this is just the reality when you let people feel free to choose and make their own decisions, they are going to find safety in numbers and people similar to them.

This explains the disproportionate lack of African American and Latino Americans in tech and the 'Bamboo Ceiling' that many Asian Americans experience in the corporate and academic world where they cap the number of Asian American applicants in Ivy league schools. Jewish Americans were also capped and barred from attending Ivy league hundred years ago but not anymore so this probably means that change will happen soon (even if it took a fucking century for racist ass mentality to change)