Live data from Hacker News

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

trapm.com

51–60 of 178 posts

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

#51

Earlier quoted context omitted.

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.

You just have to make the problems so diverse (not necessarily hard), that genuinely understanding the solutions is the easier strategy than rote learning.

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

#52

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

I think this is more typical of positions being filled in Silicon Valley, where it appears that more programmers tend to have CS degrees. Or there are enough people with CS degrees that the rest of the community feels compelled to know and understand at least second year level CS theory (Big O and Data Structures).

I work in Texas, where this is not the case, and I've never been asked to implement a Linked List in any language. I have a CS degree from 10 years ago, and I can count on one hand the number of CS graduates that I've worked with in the past 6 years.

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

#53
I call complete and utter bullshit.

Each "technical interview" I've been to is about 3-6 hrs. I've yet to see a Silicon Valley technical interview where it's not at least 3 hrs, meeting with 3 people. So right there, fitting 25 "next stage" interviews in 1.5 weeks is bullshit.

Where is he going to find the time for 40 initial phone interviews? That requires talking with the recruiter, and then the recruiter scheduling time with a developer. Anyone who has realistically interviewed in Silicon Valley knows that recruiters are very slow, and things tend to get muddled up very easily.

In 1.5 weeks, assuming they don't interview on weekends, that's 6 1-hr phone screens, plus 3 on-site interviews per day. The logistics simply don't work. It's a complete lie. If he had said 1 month, then it still would have been impossible with 1.5 phone screens and 1 on-sites per day, but it would have been slightly more believable than 1.5 weeks.

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

#54
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…

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 of a blog, for the last 3 years (with some gaps here and there). I recently started looking for a better place to work. I included the link to my blog in my resume. I got an offer recently, it will be a substantial increase in salary. I only interviewed with ~5 companies to get an offer, that's my easiest offer and shortest job search ever.

Now, would you say that I 'gamed the system' because I had a blog, and most don't? I guess you can say so, because when I started my blog, I had that in mind - it may be useful next time I look for a job. But I did not mindlessly type stuff in - I made sure I understood it as much as I can, and quite often writing the solution down helped my understanding. Same with this guy - he did not just memorize how to do it.

I had one YC company ask me to create a linked-list structure in ruby, and then reverse it. I did it recursively, mentioned that it would blow the call stack, and then re-implemented it iteratively. I also remember there was some problem where I used symbols rather than strings and that would cause some bad memory leaks over time in a long-running process. - From this passage, he might not be the "top 1 percent" everyone tries to hire, but at least top 5%, that I'm sure of. Or maybe he gamed my impression too.

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

#55
post #40

Earlier quoted context omitted.

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.

Can you show me your list implementation? I just installed rbx and tried this; the Array implementation ran in single-digit seconds, but I gave up and CTR-C'd the list one (which works fine for smaller lists).

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

#56

Are these kinds of interview questions really that prevalent? From the hiring side of the table, I can understand wanting to quickly know whether somebody knows some of the "basics" like data structures and whatnot. But I can't help feeling that you're needlessly limiting your applicant pool to only those who got a CS degree (and paid attention during the process). Why is so much emphasis placed on the theory of how…

It's legal ageism. Asking questions whose answers will be fresh in the minds of recent CS graduates is a way to legally screen out everyone else, no matter how irrelevant the Big-O runtime of merge sort is to the job.

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

#57
I can't post to the site, could somebody who can (or can contact the author in some other way), leave a note to the author, notifying him of a typo in "For people hiring, remember that anyway can pass yours tests with enough experience interviewing, even someone as bad at coding as myself." (It should be `anyone' not `anyway'.) Thanks!

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

#58
People talking about how he "hacked the interview process" are missing the point: as a hiring manager I'd gladly hire this guy even knowing that so much of what he did was not entire genuine. He took a problem (I need a job), implemented a solution (applied and interviewed at a TON of places in that short of a timeframe), and successfully iterated on that solution until he had completely mastered it! In a very short time period he went from being unable to solve a variety of programming problems (or doing so poorly) to internalizing the how & why of the optimal solutions - this is what good software development is about!

I care a lot more about initiative and problem-solving skills than I do reversing linked-lists - this guy has the former two in spades.

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

#59

I call complete and utter bullshit. Each "technical interview" I've been to is about 3-6 hrs. I've yet to see a Silicon Valley technical interview where it's not at least 3 hrs, meeting with 3 people. So right there, fitting 25 "next stage" interviews in 1.5 weeks is bullshit. Where is he going to find the time for 40 initial phone interviews? That requires talking with the recruiter, and then the recruiter schedulin…

Rough. But you're free not believe, I don't have a problem with that.

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

#60
post #51

Earlier quoted context omitted.

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.

You just have to make the problems so diverse (not necessarily hard), that genuinely understanding the solutions is the easier strategy than rote learning.

Can you give me an example of a question that isn't located in glassdoor.com and is "diverse but not hard". As far as I'm concerned, the bar is already ridiculously high to the point where I feel like the only people that get jobs are the ones who randomly get lucky enough to get 3 or 4 interviewees that ask easy questions.

There are people I know personally that have gone through every single one of the 1000+ Google interview writeups in glassdoor in order to prepare for interviews. One of my former co-workers showed me 10 pages of questions he distilled from glassdoor of various questions that were reported, and he memorized the answers to all of them, ranging from "find the common descendant of two nodes of a directed graph", to programming an AVL tree on the spot, to pure dynamic programming questions.

If they asked these types of questions 15+ years ago when I started, there's no way I could have gotten into programming. Even now, the caliber of those questions are simply too hard for me unless I sit down days before the interview to get the answer. There's no way I would be able to figure those out within 45 mins let alone 2 hrs, and I'm not dumb. It's ridiculous the level of expectations people have these days.

Post reply on HN