How to get hired (or, 'The silly story of interviewing in the valley') • Hacker News Board

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#171

Post by sedachv » Wed, Dec 21, 2011, 2:27 AM UTC

kamaal wrote: post #124

Evgeny wrote: post #54

Earlier quoted context omitted.

It's not really gaming the system. He solved the problems, himself. He asked questions, learned and then came up with more and more effective solutions. Aren't these exactly the traits an employer should be looking for? Didn't he put a lot of effort and time? Here's my own example. I've been recording some of the problems I have to deal with at work, and some of the things I come across in my spare time in the form o…

The definition of gaming the system is different here. These days unless you are implementing a library yourself. You are probably never ever going to even reverse a linked list ever in your life. Or deal sit down with a math text book when you code. Those days are probably gone in the 80's. That means asking these questions is akin to you taking an approach to judge an candidate on things which have nothing to do hi…

If you don't need to know how to solve algorithmic problems or use mathematics and you're programming, why the fuck is your job still not automated or outsourced?

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#172

Post by xiaoma » Wed, Dec 21, 2011, 6:50 PM UTC

patio11 wrote: post #69

zmj wrote: post #66

Earlier quoted context omitted.

I'm not sure I understood you correctly about FizzBuzz, but if you're saying that it isn't necessary then I'd have to disagree. I wish the world was such that FizzBuzz wasn't an effective filter, but it is. I really like the rest of your questions.

Thomas is saying that the hiring process for programmers is so comprehensively fubared that asking the FizzBuzz question to someone who has worked as a senior developer for 8 years at a well-regarded firm provides valuable signal and that if you fail to ask it you might hire people who are completely incapable of programming even with your fancy-dancy recruiting process, which shows that the pipeline and standard int…

At one Beijing-based start-up I've been working with full-time fewer than 30% of the senior iOS dev web dev applicants who have already passed the resume screen were able to complete FizzBuzz within an hour. Of those that could, only about half could code a fibonacci function.

On the other hand, there are lots of applicants and a few are very talented people who will work for under 2k USD per month. In your terminology, there's "a wee bit" of human capital here.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#173

Post by gordonguthrie » Thu, Dec 22, 2011, 11:28 AM UTC

eru wrote: post #161

gordonguthrie wrote: post #138

Earlier quoted context omitted.

As I read the article and the comments I thought "how would I reverse a linked list?" Turns out it is pretty straight-forward in Erlang: lists:reverse(List). Reading their contributions on github is a much better way to get a sense of someones capabilities.

You could just ask: How is lists:reverse(List) implemented in Erlang, or if you don't know it, how could it be implemented? What are the trade-off and limitations for different implementations? Since most abstractions are leaky, you can make a good argument, that learning how libraries tick, even if you are never going to rewrite them, is a useful skill.

But I want to find developers who will help me deliver the business objectives. Rewriting list reversal code doesn't do that.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#174

Post by eru » Thu, Dec 22, 2011, 11:57 AM UTC

gordonguthrie wrote: post #173

eru wrote: post #161

Earlier quoted context omitted.

You could just ask: How is lists:reverse(List) implemented in Erlang, or if you don't know it, how could it be implemented? What are the trade-off and limitations for different implementations? Since most abstractions are leaky, you can make a good argument, that learning how libraries tick, even if you are never going to rewrite them, is a useful skill.

But I want to find developers who will help me deliver the business objectives. Rewriting list reversal code doesn't do that.

Understanding the limitations of libraries might help you use those libraries better. Using libraries can be a part of delivering business objectives.

I don't think that list reversal is a good interview question. At least not as a positive discriminator. Though it might help you weed out people: I'd probably not want to hire people who can't figure out how to reverse a list. If they'll stumble upon such a simple problem, they might also stumble over the more complicated problems we have to solve to deliver business objectives.

I wrote `can't figure out' deliberately. Not knowing how to reverse a linked list, but being able to come up with an algorithm after a few minutes thought is perfectly adequate.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#175

Post by rhizome » Thu, Dec 22, 2011, 6:07 PM UTC

sgrove wrote: post #102

lancewiggs wrote: post #96

Earlier quoted context omitted.

I've done the same - keeping on pushing until the candidate is on uncertain ground. (I interview for consulting/ analytic /business/ senior management roles.) As most of a job is about doing things that haven't been done before, getting the candidate into unknown territory is when you really find out how effective they will be. Some people just stop, others switch seamlessly into problem solving mode and come up with…

This sounds like a great technique. It also gives both sides the chance to talk a problem through, bounce ideas off of one another, and see if there are any interesting insights to be had on the other side of the table. A candidate and interviewer both have to be fairly relaxed and comfortable to do it properly, but that's more of a problem for people new to the interviewing process (probably not senior management ro…

It also gives both sides the chance to talk a problem through, bounce ideas off of one another, and see if there are any interesting insights to be had on the other side of the table.

Some companies do this intentionally without hiring anybody in order to double-check their plans. It's basically free consulting.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#176

Post by gordonguthrie » Thu, Dec 22, 2011, 8:03 PM UTC

eru wrote: post #174

gordonguthrie wrote: post #173

Earlier quoted context omitted.

But I want to find developers who will help me deliver the business objectives. Rewriting list reversal code doesn't do that.

Understanding the limitations of libraries might help you use those libraries better. Using libraries can be a part of delivering business objectives. I don't think that list reversal is a good interview question. At least not as a positive discriminator. Though it might help you weed out people: I'd probably not want to hire people who can't figure out how to reverse a list. If they'll stumble upon such a simple pro…

I agree with you - it is a weeder-outer, but not an includer-inner - there are lots of people who can write code to reverse linked-lists that I don't want to hire.

In particular I don't want to hire the people who would rather write their own implementation than use a library (think Not-Invented-Here and Yak Shaving).

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#177

Post by andralex » Fri, Dec 23, 2011, 3:35 PM UTC

ajays wrote: post #97

timr wrote: post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

Tell me about it. I have nearly 20 years of experience in CS, and hold an advanced degree. I have 5 years of experience in a very niche field which is relatively hot. I was approached by Facebook for this specific purpose. They invited me in for just a "chat", asked me if I'd be interested in working with them. Obviously I said yeah, I'd be willing to talk. They set up an in-person interview. Just 45 minutes they sai…

As a Facebook employee who holds a PhD, I can say we are constantly preoccupied about improving the quality of our interview process. In particular, the topic of how to adapt the interview process advanced degree holders comes about quite often. For example, I recall we recently discussed that we should offer PhD candidates the option to give a talk about their research. (The option is indeed available.)

That being said, I think a dismissive or patronizing attitude towards a coding interview would be mistaken. Allow me to explain.

It is quite well known that the ability to code is poorly correlated with holding an advanced degree or other formal pieces of evidence. A candidate with strong credentials understands this and should, therefore, not be in the least offended by being asked coding questions. As a good professional, the strong candidate would handle the questions with panache and should be ready for more difficult questions, discussing advanced topics linked to the question at hand, or discussing her particular area of expertise. Either way, she must be able to code her way out of a paper bag, and I see nothing wrong with the interview process probing for that.

I've interviewed a few dozen engineers while at Facebook, many with advanced degrees (because recruiters pair as well as they can interviewers with interviewees for areas of expertise), some from top 10 universities. I ask 2-4 coding questions extracted from my daily job, starting from undergraduate level and on rare occasions ending with a difficult complexity question. Nobody has ever done perfectly well, and for a variety of reasons holding an advanced degree doesn't correlate strongly with doing well.

All in all, I think you'd be mistaken to believe two weeks of rote memorization would be enough to pass the Facebook interview, which is very difficult. Overall, an attitude of professionalism, modesty, and focus helps a lot in any interview.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#178

Post by eru » Fri, Dec 23, 2011, 5:12 PM UTC

gordonguthrie wrote: post #176

eru wrote: post #174

Earlier quoted context omitted.

Understanding the limitations of libraries might help you use those libraries better. Using libraries can be a part of delivering business objectives. I don't think that list reversal is a good interview question. At least not as a positive discriminator. Though it might help you weed out people: I'd probably not want to hire people who can't figure out how to reverse a list. If they'll stumble upon such a simple pro…

I agree with you - it is a weeder-outer, but not an includer-inner - there are lots of people who can write code to reverse linked-lists that I don't want to hire. In particular I don't want to hire the people who would rather write their own implementation than use a library (think Not-Invented-Here and Yak Shaving).

Indeed. By the way, in purely functional implementations of a list reversal there are non-trivial trade-offs to make. (See Janestreet's standard libraries for OCaml.)