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

81–90 of 178 posts

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

#81

Post by overgryphon »

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

Sure, if you're looking for someone who is hard working and willing to learn, then this type of candidate is perfect for you.

But if you're screening for candidates with development experience who you can rely on for technical knowledge, the idea that someone can game your interview process in less than two weeks without previous knowledge is horrifying. But I'm guessing that people looking to hire experienced candidates aren't basing hiring decisions on questions about reversing linked-lists.

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

#82

Post by kenjackson »

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…

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 like:

You have two lists. One is a list of IP addresses. The other list contains IP addresses or IP addresses with wildcards. E.g., 192.168.$.1 or $.255.255.255. Return the set of IP addresses from list 1 that are matched in list 2. Additionally return the index from list 2 that matched -- I want the index that is most specific (as defined by having the fewest wildcards, or wildcard furthest to the right when there is a tie).

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

#83

Post by overgryphon »

Aqua_Geek wrote: post #2

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…

Few of these types of questions ask anything beyond the first year of a decent CS curriculum. If interviewers wanted to limit themselves to CS students, they would ask about virtual memory and require candidates to write proofs of algorithms concepts on the whiteboard.

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

#84

Post by kakuri »

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…

It sounds like in this case, this guy might be a good candidate - look at all the effort he put in and his ability to remember things, think critically, and learn.

On the other hand, there are plenty of competent programmers not willing to put up with this nonsense, and the companies are going to miss out on them.

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

#85

Post by overgryphon »

abahgat wrote: post #25
Aqua_Geek wrote: post #2

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 guess that one of the advantages of such an approach is standardization, in particular if your company is big. Once you get a significant number of candidates, it may become more important to have some "objective" and quantitative way to rank your candidates by performance than to get a true understanding about how likely they are to get things done (how would you "measure" that?). At that point, it becomes more im…

I'm not sure standardization of interviews is desirable in a large company. My experience is that large companies hire by team, so interview candidates get widely varying experiences depending on what team interviews them. This way candidates can be considered not solely based on technical knowledge but also on how well they fit with a particular team.

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

#86

Post by tedunangst »

tptacek wrote: post #80
tedunangst wrote: post #73

Earlier quoted context omitted.

Why do I get the sinking feeling I'm about to embarrass myself by implementing a linked list wrong? Anyway, here's the test case I used, where I'm emulating a FIFO. class Link attr_accessor :next, :v end i = 2000 j = 10000 k = 100 if true p "linked list" j.times { head = Link.new tail = head i.times { n = Link.new n.v = 12 tail.next = n tail = n } (i-k).times { n = head head = head.next } } else p "array" j.times { a…

My test was: 1. Make a 1,000,000 node linked list of integers (I used doubly linked lists but I don't think it matters). 2. 1,000 times, insert into the middle of the list; I wrote a trivial O(n) stateless insert and called it with an offset of 500,000 1,000 times. 3. Make a 1,000,000 element Array of integers --- I just did "1000000.times.map". 4. 1,000 times call "insert" with an index of 500,000. Step (2) takes so…

If you have to seek into the list, of course it's going to suck, that's not a good application for a list. Your test would blow just as bad in C. I'm not sure that says anything interesting about lists vs arrays in ruby in particular.

I am using the same data structure, I guess it would be a little smaller without the next attr. Still seems fair. Building an array of objects is going to require allocating them. I build hand rolled linked lists by directly linking the objects of interest. Calling the class Link may have been a misnomer, it could have been called AnyClass.

It's easy to insert at the tail of an array (I'm actually inserting at the tail of the list, btw), but popping from the front means having to shift everything down. That's what makes the FIFO case interesting. If we're going to prove that ruby is too slow for linked lists to be viable, we need to be testing a scenario where linked lists generally are viable.

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

#87

Post by nadam »

I don't understand why is there such a strong emphasis on these kind of interview questions. I think showing a piece of nontrivial code which the candidate have created in the past tells a lot more about the candidate.

For example this tells more about me than the interview questions I usually got: http://codeclamp.com/ccui.js , because it tells about how I think long-term, how I solve relatively hard and relatively complex problems, not how I survive a quick interview (solving relatively easy algorithmical problems but under very high time pressure.). (By the way, if you have an interesting well paying job for me, I might be interested...)

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

#88

Post by tptacek »

tedunangst wrote: post #86
tptacek wrote: post #80

Earlier quoted context omitted.

My test was: 1. Make a 1,000,000 node linked list of integers (I used doubly linked lists but I don't think it matters). 2. 1,000 times, insert into the middle of the list; I wrote a trivial O(n) stateless insert and called it with an offset of 500,000 1,000 times. 3. Make a 1,000,000 element Array of integers --- I just did "1000000.times.map". 4. 1,000 times call "insert" with an index of 500,000. Step (2) takes so…

If you have to seek into the list, of course it's going to suck, that's not a good application for a list. Your test would blow just as bad in C. I'm not sure that says anything interesting about lists vs arrays in ruby in particular. I am using the same data structure, I guess it would be a little smaller without the next attr. Still seems fair. Building an array of objects is going to require allocating them. I bui…

The most naive possible C implementation takes 2.5 seconds to run this same test. I just tried it.

The point of a list is "insert and delete from the middle", so I don't know how to respond to the idea that actually inserting and deleting from the middle of the list is a bad benchmark.

It's difficult to respond to your last point about FIFOs for a different reason. Popping 1000 times from a 1,000,000 Array is so fast that I'd have to write code to benchmark it. And Ruby doesn't even optimize for that case; in real code, I'd use a ring buffer so that pops are just pointer adds. Ruby is, to the best of my knowledge, actually copying every single time. Copies are just way way way faster than you seem to expect them to be.

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

#89

Post by pnathan »

This article really indicates to me the fatuousness of this sorts of problem/solution interview approach.

I agree with timr in that a more more intelligent approach is to throw a problem at the candidate, then drill down into their thinking about the problem.

It's a bit silly if you're hiring based on regurgitation of algorithms in my opinion.

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

#90

Post by r00fus »

anonymoushn wrote: post #43
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.

or Total Cost of Ownership... I guess I'm hopelessly "enterprisey".
Post reply on HN