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

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

trapm.com

Post reply on HN
Print view View original

41–50 of 178 posts

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

#41

Post by gcp »

langsamer wrote: post #20

I think a much better indicator of how valuable a person will be in your company is not if he can solve puzzles on the fly but how munch time he puts into coding. If a person is coding in his free time and keeping up with technology and experimenting even though his current job doesn't require it, that person is more likely to have a breadth of knowledge that will pay dividends over time. Something like that cannot b…

In my experience interviewing candidates, the two are very strongly correlated. A person coding in a lot, including in his free time is more likely to have implemented a wide variety of things, and will be much more hands-on to solve these kind of riddles/exercises, than a person with only book knowledge who coded the same kind of stuff for years on an end.

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

#42

Post by skybrian »

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…

All that is true, but there's a simpler fix. If they're not reusing each others' questions then it should be significantly harder. Nobody should be using "reverse a linked list" anymore - that's a really old one.

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

#43

Post by anonymoushn »

brown9-2 wrote: post #37

I started asking if I could assume TCO - usually knowing they would say no, but it would set them back a bit because that's an unusual question. What does TCO here mean? Tail-call optimization?

Yes. For a moment I wondered why he wanted to use TopCoder Open in the middle of an interview.

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

#46

Post by tptacek »

kenjackson wrote: post #39
tptacek wrote: post #35

Earlier quoted context omitted.

I'd respond to this, but the "toy apps" wording makes me think this conversation will be unproductive.

Updated to remove the term.

Well, to start with, the issue here isn't that Ruby doesn't efficiently support the "modify-in-the-middle" access pattern. It's just that Ruby does this with the Array class. Similarly, even if you intend to insert into the middle, you still probably still want to use NSMutableArray in Objective C.

Even on fairly large graphs --- say, graphs at the scale of basic blocks in a program, but (obviously) not on the scale of "recommendation graph at Amazon" --- you shouldn't be burning huge numbers of cycles seeking through reference links. In naive reference-link implementations, Ruby sorely increases the constant factors for graph analysis, but computing a minimum cost spanning tree isn't going to kill you (especially because the intermediate data structures you'd use to do it would be native-code Arrays and Hashes). On the other hand, linked lists more or less pessimize Ruby, forcing it to do nothing but expensive interpreter looping, pointer chasing, and object management.

Having said all that, for serious work, I'd keep my data structures outboard, probably in Redis.

Other people would probably answer "just write a graph library in C; for instance, you could write a C wrapper around void-star-specialized boost::graph", then bridge it to Ruby with FFI.

Ruby is as good at C for I/O bound problem subsets. This is a lot of problems, and so having a language as pleasant to write in as Ruby is a win (you could say the same for Node.js and maybe even Python). It is obviously not the only language you'll ever need, though.

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

#47

Post by sgrove »

codenerdz wrote: post #24

I had a similar experience interviewing after being off the job market for a quiet a few years: You will be rusty initially, but then you will pick up steam. Just like in your "real life", solving interview problems is not about reinventing the wheel with 100% custom solution, its about pattern recognition where the pattern is a problem you know a solution for. The more problems you solve(and possibly fail) the more…

Yeah, it's a positive signal that someone was able to pick up from past failed interviews. It's a weak filter, but it's fine to have. From there, it's best to work with the person on short projects, and then hire them as a contractor to find out if they're a culture match and can solve the problems you're facing at an acceptable rate and in a maintainable way before hiring them on as an employee.

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

#48

Post by steve8918 »

skybrian wrote: post #42
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…

All that is true, but there's a simpler fix. If they're not reusing each others' questions then it should be significantly harder. Nobody should be using "reverse a linked list" anymore - that's a really old one.

That's not a simple fix. If you don't use "reverse a linked list" anymore, then you start asking increasingly harder and harder questions, and the bar gets ridiculously high, to the point where everyone needs to know how to solve NP-class problems within 45 mins. And even then the system still can be gamed by simply memorizing more and more questions. It's a lose-lose situation.

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

#49

Post by tedunangst »

tptacek wrote: post #40
tedunangst wrote: post #38

Earlier quoted context omitted.

Looks like you're right, interpreter time dominates unless I use rbx, and it's still not a big win for linked lists. But the meaning of your last sentence escapes. Linked lists are tractable compared to intractable linked lists? Antecedent mismatch?

Probably. All I meant to say is that on MRI, you might as well give up on reference-based linked lists; they just don't work at scale. In rbx, you're saying 1000.times { list.insert(500000, 666) } actually beats 1000.times { array.insert(500000, 666) } I really should be taking rbx way more seriously.

Something like that. rbx takes about 0.5 secs to start up, but after that it generally runs in the neighborhood of 10x faster, assuming you're spending enough time in actual ruby code to make that possible.

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

#50

Post by tptacek »

Programmer interviews are famously terrible. Take a second to think about FizzBuzz, why anyone ever thought we'd need something like it, and how it actually continues to serve a purpose.

Everyone thinks they're better at interviewing than they are. They often have a survivorship bias. In clueful companies, it's not that dead weight doesn't get hired. It just gets washed out. Interviewers tend to remember the people they end up working alongside.

There are dev questions that are harder to study for. They tend to be open ended. A few of my favorites:

* Describe some code that tends to follow you from project to project (I mostly interview C devs, so I tend to ask this as, "what's in libyou.a?"). What's in your bag of utility functions?

* What's the worst library you've ever worked with and why did you hate it?

* Estimate the amount of time it will take you to complete system X. Drill down, both by forcing the candidate to specify components (do an informal design exercise) and then cost each of those components. Estimation is an extremely important skill regardless.

* What's a piece of functionality that tends to crop up on lots of projects that you'd never implement yourself if you had the option of using a library? (Usually, I'm trying to get C programmers to tell me that they would not in fact hand-hack doubly linked lists out of structs with nested struct pointers).

* Describe the last system you contributed significantly to; how did those contributions break down structurally (did you write libraries for X, Y, Z; did you write plugins for X, Y, Z; did you extend the engine in X, Y, Z ways). Now describe the trickiest bug you ran into on that project.

For C devs, I always used to ask, "You're testing a component you just wrote and finding that it crashes in malloc. Diagnose the problem." This is less relevant now, but there are probably surgical questions you can ask e.g. a Python dev that verify that they actually have the experience of working professionally in the language.

Post reply on HN