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

401–410 of 570 posts

Re: How to Pass a Programming Interview

#401

Post by blakecaldwell »

platform wrote: post #397
blakecaldwell wrote: post #394

Earlier quoted context omitted.

Coding interviews are very stressful, and churn through a lot of really awesome potential hires. I imagine there are tons of false negatives, but it's nearly impossible for a terrible programmer to get through a gauntlet of programming interviews. However, I agree. They don't give a full picture of a developer's abilities. As a developer, I prefer take-home projects. As an interviewer, I prefer a few coding interview…

I have not tried it. But in my next business venture, I plan to actually do peer programming with the candidate. This is will allow members of my team (or myself) to get to know the candidate, evaluate the 'wave lengths', and how effective he/she is at finding patterns on the internet/books -- rather than thinking things up. It also demonstrates to the candidate commitment on our side, and it naturally forces us to f…

Yeah. You can save a lot of your time, and the candidates' time with a simple coding interview - even FizzBuzz will knock out half of the candidates. Then pair up and/or give a take-home, then discuss the solution in a one-on-one session.

Re: How to Pass a Programming Interview

#402

Post by nsxwolf »

robryan wrote: post #388
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…

You should have an intuitive idea around complexity and when it makes sense to optimise. I don't think though you need to know that for example fastsortx is n log n in the best case off the top of your head in an interview situation. You should be able to reason your way through why it is faster than some other sort though.

What the heck is fastsortx? This is another problem I have. I study all these algorithm books then when I get to the interview they ask something that either isn't in the books or they've come up with some nickname for it and expect me to know it.

Re: How to Pass a Programming Interview

#403

Post by vadym909 »

Recruiting is F*&^%$ No matter what you do to the interview process Hiring managers are looking for @#$#% and they may be #%@%@ and their company maybe $@%@ and their team dynamics are ##%# Candidates are looking for $@#!@ and they may be $@@$ and their personal situation is $$@@ and their salary expectation is ##%@@

Re: How to Pass a Programming Interview

#404

Post by democracy »

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…

That's how I failed my Google interview - they said they expect programmers for any position to have good knowledge of algorithms, yeah, well... :) Frankly I don't like trivia-style interviews.

Re: How to Pass a Programming Interview

#405

Post by democracy »

nsxwolf wrote: post #402
robryan wrote: post #388

Earlier quoted context omitted.

You should have an intuitive idea around complexity and when it makes sense to optimise. I don't think though you need to know that for example fastsortx is n log n in the best case off the top of your head in an interview situation. You should be able to reason your way through why it is faster than some other sort though.

What the heck is fastsortx? This is another problem I have. I study all these algorithm books then when I get to the interview they ask something that either isn't in the books or they've come up with some nickname for it and expect me to know it.

Even Google doesn't know...

Re: How to Pass a Programming Interview

#406

Post by julie1 »

balls187 wrote: post #279

> The good news is that interviewing is a skill that can be learned. When I hear folks complain about programming interviews, I point to that. The month I spend gearing up for coding interviews usually guarantees me a job, that offers at minimum a $10k raise. I consider that a very good use of my time.

There is a problem. (job interview are selecting incompetent people)

Ho, but there is a solution to walk around the problem of job interviews being unable to select good developers: so let's avoid investing in being a good developer and fix the problem at hand and just be good at interviews.

Problem solved.

Brilliant!

Are not interviews kind of de facto selecting scammers by giving them an unfair advantage, then?

Is it not causing a problem of credibility of the profession, hence the of the value of our earnings?

Growth is shrinking, recession is coming. Will they keep people whose values are uncertain when time will come to get rid of the fat?

Re: How to Pass a Programming Interview

#407

Post by elliotec »

akhilcacharya wrote: post #296
staunch wrote: post #162

Earlier quoted context omitted.

On the positive side, no one can stop you from making lots of money using the internet. And if you have something that really takes off, those same investors will line up at your door.

Right, but it's still discouraging to be forever branded a "2nd tier engineer/human/etc" because of where I went to school (unless I get into a good grad school).

This is very specifically the case in Silicon Valley, the insular center of the world, and not the case elsewhere. Most companies I've interviewed at couldn't care less about where I went to school as long as I could build their stuff.

Re: How to Pass a Programming Interview

#408

Post by aidenn0 »

ammon wrote: post #60
aidenn0 wrote: post #26

Earlier quoted context omitted.

I have more than once in my professional career run into programmers who tested on small inputs and assumed the timing would scale at least close to linearly.

Fair point. But is it not much more common to encounter a programer who cannot break a complex system into loosely coupled components? Or who does not use consistent naming conventions? Or who is smart but lazy? I'd rate all of these as equally important things to try to evaluate in an interview. I am a strong believer in looking for strength in an interview. Someone really rocking complexity analysis is a strong pos…

Oh, I'd never disqualify an interviewee purely for not knowing this stuff, but it is useful to know.

[edit]

Also, I care far less about whether they can solve some problem on paper about asymptotic complexity than if they have some sense of what it means. Someone with little formal training who discovered the classic python "Add to the end of string" algorithm is N^2 and figured out a working knowledge of N^2 vs. N is better than someone who memorized a bunch of math but can't apply it because it went in the "math box"[1]

1: http://zenoferox.blogspot.com/2009/10/deep-inside-math-box.h...

Re: How to Pass a Programming Interview

#409

Post by was_boring »

digler999 wrote: post #343
EpicEng wrote: post #220

Earlier quoted context omitted.

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

Exactly. I once identified memory leaks in a managed runtime implementation, worked around them, and showed that third party networking libraries from the hardware vendor were causing irrecoverable crashes but I can't spout off runtime complexity of algos. The former saved a multi million dollar contract and my company's reputation, the latter is something I look up when I need it.

Re: How to Pass a Programming Interview

#410

Post by aidenn0 »

davorb wrote: post #65
aidenn0 wrote: post #26

Earlier quoted context omitted.

I have more than once in my professional career run into programmers who tested on small inputs and assumed the timing would scale at least close to linearly.

There are a lot of situations where a "worse" algorithm will be significantly faster that another algorithm that's faster in theory, due to memory locality. In practice, it is very hard to know beforehand what parts of your program will scale and what parts won't.

This is categorically untrue if you are talking about large numbers and asymptotic complexity. It is true that algorithms with a constant factor larger number of operations may have such properties, but O(n) will always beat O(n^2) eventually, and in nearly all real-world cases at a fairly small n (1000 L1 cache accesses is slower than 1 memory access so n=1000 will be enough to counter any locality issues).
Post reply on HN