Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Today's Coding Interview Game

shubharamani.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Today's Coding Interview Game

#101

Post by stcredzero »

aplusbi wrote: post #93
bmj wrote: post #91

Earlier quoted context omitted.

Good points, but, how many interviewers would severely penalize someone for not even knowing what a binary tree was? I think explaining the tree and asking for an implementation could be a fair question, but only if the question assumes that the implementation is the important bit.

Also a good point. I'd be surprised if a programmer didn't know what a binary tree was and would certainly consider it a warning sign. I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). However I'm willing to be proven wrong and if they were able to implement one I would be pleasantly surprised. Of course, I can only speak for myself. I'm sure many program…

I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything).

That's a pretty glaring assumption, especially since it's subject to empirical verification. It also contains an assumption of its own -- that all programming needs a heavyweight familiarity with algorithms. There's a lot of programming contexts where the productive programmer just uses a hash so the mental bandwidth can be devoted to something else.

(FWIW, I do sometimes wish those programmers knew a little more about algorithms.)

Re: Today's Coding Interview Game

#102

Post by aplusbi »

stcredzero wrote: post #101
aplusbi wrote: post #93

Earlier quoted context omitted.

Also a good point. I'd be surprised if a programmer didn't know what a binary tree was and would certainly consider it a warning sign. I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). However I'm willing to be proven wrong and if they were able to implement one I would be pleasantly surprised. Of course, I can only speak for myself. I'm sure many program…

I would assume that, given a description, they probably wouldn't be able to code one (or code much of anything). That's a pretty glaring assumption, especially since it's subject to empirical verification. It also contains an assumption of its own -- that all programming needs a heavyweight familiarity with algorithms. There's a lot of programming contexts where the productive programmer just uses a hash so the menta…

I agree that it is a glaring assumption, and perhaps is "culturally" biased. Someone programming in Perl or Python, would probably be very familiar with the built in data structures (hashmaps, dictionaries) but may not be familiar with others.

And this is exactly why I would give the programmer the benefit of the doubt. If they are able to implement a binary tree then I wouldn't hold it against them (and I hope most other programmers would extend the same courtesy).

However I have never met a programmer who did not know what a binary tree was.

Re: Today's Coding Interview Game

#103

Post by misterbwong »

aplusbi wrote: post #25

I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting. I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it. Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it. I do expect you to ask questions.…

I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job).

As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.

Re: Today's Coding Interview Game

#104

Post by davidjhall »

We've been interviewing MS-SQL dba's for months now. Each time, we ask them to rate their SQL experience on a scale from 1-10 and most candidates have said 7-8. When brought in and asked to do a simple SQL select with a group by, none of these candidates could write any SQL. Any SQL. That's what makes tests important.

Re: Today's Coding Interview Game

#105

Post by Xurinos »

varjag wrote: post #73
Revisor wrote: post #67

Earlier quoted context omitted.

I want to deliberately look for people like you. How do I tell it's you? The skilled but modest/unsociable/shy/... programmer.

Look at their hobby projects. And/or contributions to the public projects. Good programmers nearly inevitably leave some visible trace.

I mostly like this answer. It depends on the individual's time and how they balance against the needs of the rest of their life. I can judge a certain amount of motivation from outside contributions, but I understand it is not the only angle to learn about that.

I would add that you should hold an intelligent dialogue with your interviewee. This means doing more than just asking a question. Follow up. Not only find out if they have done something, but figure out if they understood what they were working on. Find some specific details in it. If you need a nice canned starter question for this: "What was the hardest problem you ran into when implementing X?"

In other words, interviewers should have filter dialogues, not filter questions. Genuinely learn about your interviewees. You must direct the conversation intelligently. That is how you can find the diamonds amongst the poor salesmen.

Re: Today's Coding Interview Game

#106

Post by btilly »

tgflynn wrote: post #99
sokoloff wrote: post #74

Earlier quoted context omitted.

Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits? Of the people actively applying for jobs at any given point in t…

If I were looking to hire a developer I would do the following : 1) Select a set of candidates based on their resumes making the assumption at this point that their resumes are honest. Good candidates should have at least worked on some interesting projects so their resumes should look interesting. Most lame candidates wouldn't even be able to invent a credible interesting project. 2) Do phone interviews where I woul…

I'm sorry, but this process would not work.

You are basically filtering for presentation ability. But 3/4 of programmers are introverts, and giving presentations is simply not part of their job. You're therefore selecting for the wrong skills until the contract step.

At the contract step you create another problem. Good programmers who want to be employees probably already have jobs and are somewhat risk adverse. That kind of person won't find the option of a short-term contract with no promises at all enticing.

Remember, as bad as the economy is, the economy for programmers right now is pretty good. And as annoying as the coding interviews may be, really good candidates don't have too much trouble with them.

Re: Today's Coding Interview Game

#107

Post by Xurinos »

Retric wrote: post #94
sokoloff wrote: post #74

Earlier quoted context omitted.

Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits? Of the people actively applying for jobs at any given point in t…

Remember the goal is to find high quality candidates not shift though all of the incoming resumes. So if you have 2 open positions and 10,000 resumes just stop when you find enough high quality candidates.

I agree. Resumes are not as useful as a lot of employers want to believe. They represent what the candidate wants you to see of their history, and you get only one thing from that: Talking Points. Resumes put you both on the same page, bringing up topics the candidate is interested in talking about.

A poor salesman will have a hard time coming up with good or enough talking points. This alone is a reason resumes are mis-filtered.

I want to say that you should avoid filtering candidates based on their resumes, thanks to the holes, but that would be wrong: Sometimes, based on what they write down, you can make a reasonable judgment. For example, if you are looking for a software developer and the resume mentions NOTHING about that field, that is an easy filter.

Not quite so easy a filter: "I know C/C#/C++." but I always find that one amusing.

Re: Today's Coding Interview Game

#108

Post by Xurinos »

btilly wrote: post #106
tgflynn wrote: post #99

Earlier quoted context omitted.

If I were looking to hire a developer I would do the following : 1) Select a set of candidates based on their resumes making the assumption at this point that their resumes are honest. Good candidates should have at least worked on some interesting projects so their resumes should look interesting. Most lame candidates wouldn't even be able to invent a credible interesting project. 2) Do phone interviews where I woul…

I'm sorry, but this process would not work. You are basically filtering for presentation ability. But 3/4 of programmers are introverts, and giving presentations is simply not part of their job. You're therefore selecting for the wrong skills until the contract step. At the contract step you create another problem. Good programmers who want to be employees probably already have jobs and are somewhat risk adverse. Tha…

You are basically filtering for presentation ability.

...unless you are looking to hire someone in sales or someone to represent you. :) But I agree with you.

For something like software development, I think the presentation process can be improved by talking to the candidate as part of the presentation, not just letting them starve in front of an audience. Let's not rule out the presentation mechanism; you can learn about the candidate's ability to give presentations and handle pressure.

Re: Today's Coding Interview Game

#109

Post by davidsiems »

sokoloff wrote: post #74
aristus wrote: post #26

I worry a lot about this. I don't think it's distrust so much as thoughtlessness. From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact.…

Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits? Of the people actively applying for jobs at any given point in t…

For game development at least I've found that a 10 minute phone interview with simple 'these are things you must know or I will not hire you' questions works wonders for screening. I like to think of it as a bounding volume check for the position you're interviewing for. It's simple, and if you're not intersecting at this level there's no way you'll be intersecting at the more detailed levels.

This works because game development is relatively specialized and there actually are things that I expect anyone claiming to be a game developer to know.

Stuff like basic linear algebra (What can you use a dot product for? What can you use a cross product for?) and simple data structure do's and don'ts (What's one advantage of using an array over using a linked list?). Throwing in a few simple domain specific questions for the position their applying for works well too (I wouldn't ask a network programmer to tell me something about shaders, but I would expect a graphics programmer to be able to talk about them for a few minutes)

Some of the questions are designed so that there are lots of right answers, and some of them impress me more than others. For instance, if you mention that an array is generally more cache-friendly than a linked list and you can explain why when I ask you, you get bonus points.

If they do well on most of the questions then follow up interviews (phone or in person) are in order. Occasionally someone will nail all the questions, I tend to get excited when this happens.

Re: Today's Coding Interview Game

#110

Post by tgflynn »

btilly wrote: post #106
tgflynn wrote: post #99

Earlier quoted context omitted.

If I were looking to hire a developer I would do the following : 1) Select a set of candidates based on their resumes making the assumption at this point that their resumes are honest. Good candidates should have at least worked on some interesting projects so their resumes should look interesting. Most lame candidates wouldn't even be able to invent a credible interesting project. 2) Do phone interviews where I woul…

I'm sorry, but this process would not work. You are basically filtering for presentation ability. But 3/4 of programmers are introverts, and giving presentations is simply not part of their job. You're therefore selecting for the wrong skills until the contract step. At the contract step you create another problem. Good programmers who want to be employees probably already have jobs and are somewhat risk adverse. Tha…

Being an introvert doesn't preclude one from giving a good technical presentation. It's common practice in the academic/research world which is certainly full of introverts.

The assumption I'm making here is that of hiring for someone to work on technically challenging problems (ie. machine learning, computer vision, data analytics, large-scale systems design, etc . . . - the list isn't meant to be exhaustive). For those problems you need people with strong general and/or mathematical reasoning ability. If I was looking for a very junior coder I might skip the presentation step.

At the contract step there doesn't need to be any risk for the candidate - there's no reason he would need to leave his current employer during this phase. Of course there would have to be an incentive of some kind if he was hired - better salary, more interesting work, etc.

Post reply on HN