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

91–100 of 178 posts

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

#91

Post by huhtenberg »

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…

Going through the details is the way to estimate candidate's true knowledge of a subject. Ask an easy question, then ask a very hard one, repeat depending on answers, i.e. basically do a binary search:

  - Do you know what SSL/TLS is?                       general
  - What's the maximum size of SSL protocol record?    specific
  - What's a cipher suite?                             general
  - How is DH-anon suite is set up?                    specific
  ...

  - What is a linked list?
  - What is offsetof (and how is it relevant)?
  ...

  - What is TCP?                                       general
  - What is TCP/Vegas?                                 specific
  ...
This is the quickest way to converge to an actual level of expertise, and it really helps with filtering out people with bullshit resumes and those who cheated their way through an offline problem solving. We would say something like "You are not expected to answer all questions, we are just trying to understand what you know and what you don't know."

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

#92

Post by anonymoushn »

Stwerner wrote: post #11
robobenjie wrote: post #6

Earlier quoted context omitted.

We use these types of questions to allow an applicant to show us that they can, in fact, write a simple program (see http://www.codinghorror.com/blog/2007/02/why-cant-programmer... ) and we use programming puzzles to make it more interesting for the bright candidates.

Are there any good sites out there that have a lot of these types of problems that are asked in interviews? Sites like http://spoj.pl seem to have problems that are more longer form. But it would be fun to start practicing solving the shorter ones that are asked without the hassle of interviewing to get them.

Other programming contest sites are good sources of problems similar to the ones that come up in interviews.

http://train.usaco.org/usacogate

http://community.topcoder.com/tc

http://uva.onlinejudge.org/

http://www.facebook.com/hackercup

http://code.google.com/codejam/

http://codeforces.com/

http://www.interviewstreet.com/recruit/challenges/

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

#93

Post by nadam »

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…

"you need to know the subject better than the person that you're interviewing. If you don't, you have no hope of screening for good people."

I think it is not necessary and not possible that the interviewer know more about every subtopic than every candidate. It is enough that they have comparable knowledge in most topics. Good candidates can very easily know more about some parts of the subject (and maybe less about other parts). Being a good interviewer is a really tricky business, because good interviewers should see the strength of candidates and should see if the candidate know even more than them about some subtopics. I've seen some bad interviewers who asked only the very narrow topics they knew well, and basically wanted exact copies of themselves.

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

#94

Post by anonymoushn »

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…

Of course blitting half of an array will be much faster than dereferencing an equal number of list nodes. I don't think you would want to use a linked list in a situation that resembles your benchmark. If you were going to insert many more elements at a time than 1 (like, say, all 1,000), or if you had to traverse the entire list and also update some parts of it, then I would expect it to do significantly better.

Probably not in Ruby, though.

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

#95

Post by jaylevitt »

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

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 linked lists work (for example) instead of the practical application of where they'd be used? Edit: Big O notation is great and all, but shouldn't the emphasis be more on shipping than optimizing? You can optimize yo…

And I take issue with "If you're going to work in the CS field." You're assuming that all programming/coding/software engineering/whatever jobs are in the CS field. There's a lot more out there.

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

#96

Post by lancewiggs »

groby_b wrote: post #13
sgrove wrote: post #9

Earlier quoted context omitted.

Yeah, that was more or less the point of the post. For applicants, don't feel nervous, it's a silly game just to see if you know some of the puzzles. For people hiring, go ahead and use this as a first-pass filter, but realize that it's easy to game (by someone who's trying hard and learning, so there is a positive signal in that). It's going to be important to go through and work with them for a period of time in a…

In all my history of interviewing people, I've always found there's almost no info to be had in correct answers to any kind of question. You learn about a candidate once you guide them into territory where the fail. Both where that line is, and how they handle the failure tells you a lot. (Caveat: Make sure you're keeping it on the fail/no-fail edge, and you treat the candidate with respect. The point is not to show…

I've done the same - keeping on pushing until the candidate is on uncertain ground. (I interview for consulting/ analytic /business/ senior management roles.)

As most of a job is about doing things that haven't been done before, getting the candidate into unknown territory is when you really find out how effective they will be. Some people just stop, others switch seamlessly into problem solving mode and come up with an answer that may or may not work, and also with a plan to test whether it does.

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

#97

Post by ajays »

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

So I show up, fully expecting a discussion about that area, my background, etc.

Instead, I get a random coder who wasn't even making eye contact when asking questions. And the questions? Elementary CS stuff that any undergrad would know.

Now, obviously I know them too; heck, I taught Algorithms courses in grad school.

But why waste my time with this crap? You can hire almost any fresh graduate from a top-40 school who would do a halfway decent job at answering those questions. What does asking a PhD "how to print the levels of a binary tree, one per line" tell you about his work? (That wasn't the question, but that was the level of questioning).

The sad part is: 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?

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

#98

Post by arghnoname »

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

Going through the details is the way to estimate candidate's true knowledge of a subject. Ask an easy question, then ask a very hard one, repeat depending on answers, i.e. basically do a binary search: - Do you know what SSL/TLS is? general - What's the maximum size of SSL protocol record? specific - What's a cipher suite? general - How is DH-anon suite is set up? specific ... - What is a linked list? - What is offse…

There's always a downside to every approach though. Some people get flustered if they have to say "I don't know" too often, so instead of bouncing from tough to easy, I'd probably prefer to progress from easy to tough.

People will feel confident until they hit their limits. Their limits are what you are looking for (presumably), not their ability to think clearly when they are scared they just blew the interview on a question you didn't really expect them to answer.

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

#99

Post by jrockway »

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

There is a spectrum. The elite companies have all-day interviews (Google). Middle-tier tech companies have half-day interviews (Amazon). Big non-tech companies have a couple-hour interview (Bank of America). Small companies can vary, but I've gotten hired off a quick IRC chat. I have no idea what the average startup's culture is like, but they probably don't have 5 hours of developer time to waste on each candidate. So instead, they have a short interview instead of a long one.

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

#100

Post by Timothee »

observer1 wrote: post #16

"....this process, starting from ~50+ raw leads whittled down into ~40 initial phone interviews/coding challenges, which went to ~25 next stage interviews, eventually down to ~6 really good offers, all in about ~1.5 weeks." Does this timeframe seem a little dubious to anyone else? I count 65 technical interviews plus interviews with hiring managers, etc., followed by receiving offers. And all of this happening in abo…

Besides the apparent mismatch between hours in a day and hours necessary for all that to happen in 1.5 weeks (well, it's technically possible), what surprised me was just even that 40 companies out of 50 were responsive enough to schedule phone interviews in that time. And next stage interviews after that. And make a decision to hire him. Especially for a self-proclaimed bad coder.

So, I agree with you, but this is not really the point of the post. The point is that interviewing is a game that you can master with practice.

Post reply on HN