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

131–140 of 178 posts

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

#131

Post by petercooper »

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.

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.

I think that, sadly, this is true of almost any well engineered data structure. MRI's overhead is so vast that even if you perform an operation at, say, O(n) with the logical solution, using a naive built-in or iterative technique with retrieval of O(n * n) will be faster up until the often rather distant point where the lines cross.

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

#132

Post by gaelian »

timr wrote: post #114
tedunangst wrote: post #111

Earlier quoted context omitted.

I've interviewed a few people who thought the elementary questions I was asking were beneath them. I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard. Some people are probably bullshitters, but my theory is that some are just people who used to code (a little) but have since moved on to making architectural diagrams for so long they've forgotten…

"I insisted, politely, that they humor me, because it's something we make everybody do, nothing personal. They failed. Hard." I'm sensitive to that argument, but I also think the parent has a point. Coding the solution to a toy problem on a whiteboard has only limited correlation with the ability of a candidate to solve real-world problems. We use the tool because it's one of the best we have, not because it's a grea…

I was talking to a friend of mine about just this issue recently. He and I have been on both sides of the interview table at different times. I have gotten interviewees to solve toy programming problems and I've asked them the funny little logic problems, just as I have been asked the same sort of things in the past. But eventually I too came to the realisation that these kinds of things had little if any real significance to the work that the interviewee was going to be doing. Is it usually going to be the case that the guy you hire will have to write his code with unusual speed, under the pressure of three or more people looking over his shoulder and judging his answer, without the benefit of Internet access or Intellisense or what have you?

My approach is to throw out the whiteboard coding and logic questions whenever I can and to look for examples of a prospective employee's real world work, namely contributions to open source (e.g. GitHub makes this easier) and if not that, then perhaps they can directly provide me with private real world examples of code they've written.

I realise that not everyone will necessarily be able to provide such examples of real world work and yes, looking over someone's pre-existing project will probably take more time than seeing if they can reverse a string. But maybe this is also part of the problem: hiring practices in some places have gotten lazy.

I can't think of a way to entirely, in 100% of cases get rid of FizzBuzz, and the guy who has to escape the fire spreading from one side of the island etc. but I really wish I could, because it just doesn't feel right.

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

#133

Post by [deleted] »

AdamTReineke wrote: post #128
kenjackson wrote: post #82

Earlier quoted context omitted.

I actually don't have an explicit set of core questions, but I'm sure there are clear themes that run through the problems. Probably my only real tip I can think of is not to have them code something related to stuff you're currently working on. You'll be far more likely to underestimate how hard the problem is. But the problems aren't that hard to think of. They're not like ACM programming contests. They're more lik…

Would the optimal solution be O(n*log(m)), where n is the number of IP addresses in list one and m is the number of IP addresses in list 2?

[deleted]

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

#134

Post by kenjackson »

AdamTReineke wrote: post #128
kenjackson wrote: post #82

Earlier quoted context omitted.

I actually don't have an explicit set of core questions, but I'm sure there are clear themes that run through the problems. Probably my only real tip I can think of is not to have them code something related to stuff you're currently working on. You'll be far more likely to underestimate how hard the problem is. But the problems aren't that hard to think of. They're not like ACM programming contests. They're more lik…

Would the optimal solution be O(n*log(m)), where n is the number of IP addresses in list one and m is the number of IP addresses in list 2?

I think O(n * 2^p) is also a possibility, where p is the number of slots in the address. For standard IP addresses p is 4. So for large m, this might be preferable. I'm basically just hashing values to get this. How do you get the log(m) factor?

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

#135

Post by jrockway »

jarek wrote: post #119
jrockway wrote: post #107

Earlier quoted context omitted.

Personally, I always have to wonder how often someone programs a computer if they don't know the asymptotic complexity of a merge sort. It seems like something someone would either pick up at some point in their career, or be able to figure out on their own at the interview. (Come to think of it, I never took an algorithms class in school, and I know the answer to this question.)

What's your definition of "programming a computer"? Personally, I always have to wonder how often someone programs a computer if they don't know how a four-state branch predictor helps their CPU.

The key insight that relates to the analysis of merge sort is that solving problems with computers always goes better if you divide them in half a few times. This comes up again and again; binary trees, binary search, and all the n log n sorts. Branch prediction is a little different; it's an optimization engineered into modern processors. Splitting problems into two is a fundamental property of the Universe. Therefore, it's less excusable to not realize that you do that a lot.

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

#136

Post by shard »

russell wrote: post #27

I use a similar approach. I spent 20 years as a consultant, so I did a lot of interviews. I would send out lots of emails. I didnt do many tailored emails, but I did a carefully tailored cover letter designed to be amusing to the HR ladies. You have to get by them first. I figured the first few interviews were throw-aways, just to get my interviewing skills back up to speed and to find what this years interview quest…

What did you do in your cover letter to amuse the HR ladies? Please share.

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

#137

Post by jimbobimbo »

bialecki wrote: post #71
kenjackson wrote: post #14

Earlier quoted context omitted.

I have some simple baseline questions I ask everyone. Getting it right just means we continue the rest of the interview, but doesn't get you a job. I almost always have a programming question I just made up 30 minutes before the interview. I make sure that I can easily do it in 10 minutes and then ask it. It really isn't important to me if they get they answer, but I want to see what questions they have, and how they…

>> I almost always have a programming question I just made up 30 minutes before the interview. I make sure that I can easily do it in 10 minutes and then ask it. This is a lot easier said than done. Do you really do this and, if so, any tips on how? (I'm guessing variations on a core set of questions.) I usually don't mind asking a questions someone may have already heard because there's not really a right answer, bu…

My usual question on the interview is to implement an atoi() function. All I care is that a person doesn't do stupid shit like switch case for characters or a strlen() for iterating through the input. It really is a 10 to 15 minutes task and boy it shows whether a person can write code. Usually then I continue with "how'd you test it?" question, then move on to multithreading and a quick design question. All in all I spend maybe 30 minutes to tell if I'd make a hire.

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

#138

Post by gordonguthrie »

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…

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.

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

#139

Post by gordonguthrie »

AdamTReineke wrote: post #128
kenjackson wrote: post #82

Earlier quoted context omitted.

I actually don't have an explicit set of core questions, but I'm sure there are clear themes that run through the problems. Probably my only real tip I can think of is not to have them code something related to stuff you're currently working on. You'll be far more likely to underestimate how hard the problem is. But the problems aren't that hard to think of. They're not like ACM programming contests. They're more lik…

Would the optimal solution be O(n*log(m)), where n is the number of IP addresses in list one and m is the number of IP addresses in list 2?

If it is a long list then the O of the algorithm matters a lot.

If its a short list, who cares?

If you care about it all the time then you a premature optimiser - basically a hand-grenade with the pin out.

(by you I mean 'one' here - not you AdamT)

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

#140

Post by paganel »

zem wrote: post #117
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…

as someone who successfully built a great dev team at a startup, i can say that this is a sign of sheer laziness on the interviewers' parts. which is sad, because in a small company, hiring is one of the most important things you can do. there is no real excuse for having an interview so generic that someone can game it in this manner unless you're so large that you can afford the odd charlatan.

> there is no real excuse for having an interview so generic that someone can game it in this manner unless you're so large that you can afford the odd charlatan.

I'm also part of a small start-up (as an employee), and I can certainly vouch for that. I for one put a very high emphasis on the personal/professional projects the guy/dudette in front of me has been involved in, on how best s/he can explain them to me, on how passionate the person seems when explaining all this (and no, I'm not talking about the enthusiastic approach that can be easily faked, I just think that when you're a programmer you can feel what the other programmer in front of you is very interested in).

Also, this mania a lot of interviewers have with the interviewees "always ticking the right boxes and giving the correct answers" sort of scares me. It's probably because I work in a start-up, but I can assure everyone that at least half of the time we ourselves don't know the answers (assuming that we even know the correct questions), and there are lots of times when we seem to be knowing in what direction we're going but truly speaking we don't.

Post reply on HN