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

141–150 of 178 posts

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

#141

Post by rmc »

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…

If you interview people, this article should terrify you.

If you're interviewing for programming jobs, the (low) calibre of existing applicants has probably already terrified you.

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

#142

Post by rmc »

pfedor wrote: post #120
tptacek wrote: post #68

Earlier quoted context omitted.

I'm saying that the fact that FizzBuzz actually works should be an indication of how crappy programming interviews tend to be.

I think this conclusion is wrong. The fact that FizzBuzz exists actually means that programming interviews are awesome: with most other professions, you would end up hiring a candidate equally as incompetent as the programmer that failed FizzBuzz.

No. You do not have to ask doctors or lawyers or taxi drivers fizzbuzz levels of questions. If applicants for doctors jobs were as incompetant as programming interviews, you'd have to ask applicants to location the ear on the human body. Doctor applicants aren't that incompetant, programmer applicants are.

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

#143

Post by dunk010 »

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

If you interview people, this article should terrify you. If you're interviewing for programming jobs, the (low) calibre of existing applicants has probably already terrified you.

True dat.

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

#144

Post by mattmanser »

kenjackson wrote: post #34
tptacek wrote: post #26

Earlier quoted context omitted.

That's a sensible point, but interpreter and runtime overhead crushes any cost savings you might get from adjusting links instead of the whole array backing store. (Ruby arrays, at least in MRI, are basically STL vectors). 1000 inserts to the middle of a 1,000,000 element Ruby array happens so quickly you can barely perceive the delay. The same insert pattern to a basic Ruby linked list sets my machine on fire.

Wow, that sounds painful. So do people not use things like graphs or trees in Ruby due to perf? I actually used to do Python development -- about 13 or so years ago, but had to quit due to perf just being abysmal for applications intended for customers (and started focusing on C++). Is Ruby today similarly bad for apps that make heavy use of data structures like trees/graphs as Python more than a decade ago? EDIT: Up…

13 years ago. When the Pentium II was around. This is what I don't get about questions about linked lists.

They're so utterly irrelevant in 99% of startups today, where knowing how to lay out your classes and methods for maintainability is so much more important than any trivial and pointless performance gain.

The complexity of solutions is at such a higher level now than it's ever been and yet we're still worrying about structures that shaves less than a ms off something that's called once every 10 seconds.

The reason why ruby and python have grown in dominance in the last few years is because you don't actually have to worry about this any more.

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

#145

Post by bigbird »

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

Unless the end result is a completely incompetent applicant getting an offer, I wouldn't call the system "horribly broken". Very few companies are in the business of reversing linked lists, and hence make binary decisions depending on the outcome of just that one question. I don't think gaming the system is that trivial - an interview is a conversation, so things like computational complexity, runtime restrictions, d…

I also don't think that what the article describes is "gaming" the system, except maybe for the part about pretending to have not heard the questions before.

Generally, the reason I ask such questions of candidates is to make sure I'm dealing with someone who can actually analyze a problem and get a reasonable result. So if they nail the questions because they took time to study and get good at interview-style brain teasers, that's actually fine with me - it proves the person can execute a plan to get correct results.

I'm not sure I'd call anyone who successfully "games" the system incompetent.

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

#146

Post by lallysingh »

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

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

Not from anywhere I've worked.

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

#147

Post by carlio »

gaelian wrote: post #132
timr wrote: post #114

Earlier quoted context omitted.

"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 signif…

I'm constantly surprised when I read articles like this one, or when I take interviews myself, that noone considers how the employee deals with a "project as a whole". Toy logic problems or algorithm optimisation tell you nothing about how good that person is at actually working as a software engineer. Do they care about code unit tests and code coverage? If they find a process missing - no continuous integration or something - do they just mumble and make do or do they find out why and, if necessary, implement it? Are they capable of delivering quality software, or can they merely write neat, optimised algorithms?

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

#148

Post by dsolomon »

kamaal wrote: post #121
ajays wrote: post #97

Earlier quoted context omitted.

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

Show me a quality company to work for and I'll show you people who will spend more than a year working there.

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

#150

Post by adam-a »

tptacek wrote: post #130
barrkel wrote: post #122

Earlier quoted context omitted.

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.

I'm reading this thread and kind of tearing my hair out.

One theoretical case where lists beat arrays is seeking to the middle (once) and inserting 1000000 items in that one spot.

If you want to test if lists can ever be useful in Ruby then you want to test the case that they are theoretically useful. Your test is a theoretical dead heat as arrays and lists both perform O(n) in it. All you learn is that arrays are faster in Ruby for the same complexity, which we knew already.

Post reply on HN