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')

#121

Post by kamaal » Tue, Dec 20, 2011, 4:40 AM 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…

I can waste a couple of weeks of my life, go to Glassdoor etc. and basically memorize these questions. I'll probably stand a good chance of blowing the interviewer away by pretending to solve them on the spot. But what does that tell you about how I am at real-life problems?

Most of the so-called algorithm experts I've seen fit into this knows-theory-but-no-practical-stuff category. The fact there are some list of questions and their standards variants. All you need to do is just crawl over interview forums. I assume they even have books, as in pdf ready made for these purposes. Just ensure you read all those questions before hand. May be spend an hour a day to get familiar with them.

Go to the interview, when the interviewer asks the question act as though you've never heard the question. Act like you've been having it tough. But then suddenly like a hero emerging from a crisis present the solution to the interviewer.

You have not clue how many people do this. I've seen candidates, whose only job is this. They change a company every year. Spend half their day everyday studying and collecting salary and interview trends. Apply to a big brand, game the interview collect the x% hike stay for an year and then move on.

These kind of people are an online club. And they tend to hire only their kind.

No regards for the guy's actual work knowledge, his ability to solve real world problems. His knowledge of a programming language, tools, techniques. His productivity all that is irrelevant.

All that matters in these large web companies is a Ivy league brand and theoretical knowledge and some arcane facts memorized at college. Close to 98% of the so called algorithm experts fit into this category.

The genuine 2% are at places they like to work at and surely they pick the place they want to work at and not the other way around.

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

#122

Post by barrkel » Tue, Dec 20, 2011, 4:42 AM UTC

tptacek wrote: post #88

tedunangst wrote: post #86

Earlier quoted context omitted.

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…

The reason manipulating linked lists in the middle is faster than arrays is so you can save the O(n) work of moving elements. But you lose that if you still do O(n) worth of seeking. There is no big-O difference between inserting and deleting in the middle of an array and a plain linked list, if the linked list is forced to seek.

I'm sure this is as obvious to you as it is to me, but perhaps the perspective it comes from explains why people are thinking that your described operations on the list are a dodgy benchmark for judging linked lists vs arrays; absent constant factors, they should perform the same. (And yes, for reasonable input on modern machines, the constant factors will dominate.)

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

#123

Post by Retric » Tue, Dec 20, 2011, 4:51 AM UTC

tptacek wrote: post #88

tedunangst wrote: post #86

Earlier quoted context omitted.

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…

If your want to insert and delete in the middle use a binary tree. Linked lists are reasonable for queues and that's about it.

PS: Slip lists are not bad though.

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

#124

Post by kamaal » Tue, Dec 20, 2011, 4:52 AM UTC

Evgeny wrote: post #54

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'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 his job. That's why so many programmers don't about all this. The reason is for 99% of the work they are likely to do they don't need to know it.

Under such circumstances when you ask these sort of questions the only way candidate can deal with them is not by actually learning how to solve them. But learn them just for the interview sake.

So you end up hiring some one on a criteria doesn't matter. And the candidate manages to beat you by system of work which defeated your original means of judging him.

I think this is what gaming the system means.

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

#125

Post by kamaal » Tue, Dec 20, 2011, 5:02 AM UTC

overgryphon wrote: post #81

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 candid…

I think the point he was trying to make was. If you are productive enough and serious with a little skills you are can be hired.

The reason being you work hard your way towards success. This is far better than the person who knows merely facts.

Knowing doesn't always doing. But in most cases if you are doing something you are likely to know what it is.

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

#126

Post by kamaal » Tue, Dec 20, 2011, 5:05 AM UTC

brown9-2 wrote: post #36

rauljara wrote: post #17

I was flabbergasted that someone was asked implement a linked list in Ruby. My initial reaction was 'That is an incredibly stupid thing to do.' My slightly more in depth reaction was "Isn't that what mutable arrays are for?" And my final reaction was, "Maybe I'm missing something." At which point I tried to figure out the benefits of a linked list over a ruby array. I wasn't able to come up with a good reason to use…

I think you are looking at this from the wrong angle. Just because it made a good interview question (for the interviewer) doesn't mean it's something you'd actually want to use in everyday practice.

Why would you ask questions to a candidate which have nothing to do with his job?

Will you ask a marathon runner to prove his worth by asking him how quickly he can sprint?

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

#127

Post by hboon » Tue, Dec 20, 2011, 5:06 AM UTC

Evgeny wrote: post #54

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'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…

Would that be considered top 5% already? I thought it's pretty obvious. Honest question.

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

#128

Post by AdamTReineke » Tue, Dec 20, 2011, 5:12 AM UTC

kenjackson wrote: post #82

bialecki wrote: post #71

Earlier quoted context omitted.

>> 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 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?

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

#129

Post by AdamTReineke » Tue, Dec 20, 2011, 5:22 AM UTC

r00fus wrote: post #90

anonymoushn wrote: post #43

Earlier quoted context omitted.

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".

That's two of us.

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

#130

Post by tptacek » Tue, Dec 20, 2011, 5:34 AM UTC

barrkel wrote: post #122

tptacek wrote: post #88

Earlier quoted context omitted.

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…

The reason manipulating linked lists in the middle is faster than arrays is so you can save the O(n) work of moving elements. But you lose that if you still do O(n) worth of seeking. There is no big-O difference between inserting and deleting in the middle of an array and a plain linked list, if the linked list is forced to seek. I'm sure this is as obvious to you as it is to me, but perhaps the perspective it comes…

I'm sure I agree with everything you're saying here, but it carries a whiff of tautology. You lose the benefit of middle-insertion in a list if you have to seek, but part of the point of using an array is not having to seek ever.

Anyways the only thing that moved me to comment is the general inferiority of linked list data structures compared to arrays, which are what Ruby (sensibly) uses.