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

71–80 of 178 posts

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

#71

Post by bialecki »

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

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, but I just want to discuss a problem to see how you think through it.

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

#72

Post by sgrove »

steve8918 wrote: post #70
sgrove wrote: post #65

Earlier quoted context omitted.

I didn't have a car actually. I just scheduled all the interviews as close to possible every day, and walked around SOMA/FiDi from morning until evening going through different stages of different interviews - initial chat (morning coffee/lunch/dinner/drinks), whiteboarding session, meet with the team, build a mini-project, discuss final offer. Each successive stage is more time intensive, but there were also fewer o…

Even more interesting then, because you just lost 2 hrs every day commuting back and forth on Caltrain. "Each successive stage is more time intensive, but there were also fewer of them." You just said you had 25 onsites. Unless you knew beforehand that you were going to cut out of them early, there's no way you could have scheduled 3 per day. And at 6 phone screens per day, the last 2-3 days worth of phone screens oc…

All good points. This is just what I remember, and I don't dispute it could be wrong.

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

#73

Post by tedunangst »

tptacek wrote: post #55
tedunangst wrote: post #49

Earlier quoted context omitted.

Something like that. rbx takes about 0.5 secs to start up, but after that it generally runs in the neighborhood of 10x faster, assuming you're spending enough time in actual ruby code to make that possible.

Can you show me your list implementation? I just installed rbx and tried this; the Array implementation ran in single-digit seconds, but I gave up and CTR-C'd the list one (which works fine for smaller lists).

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 {
    arr = []
    i.times {
        n = Link.new
        n.v = 13
        arr

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

#74

Post by zmj »

tptacek wrote: post #68
zmj wrote: post #66

Earlier quoted context omitted.

I'm not sure I understood you correctly about FizzBuzz, but if you're saying that it isn't necessary then I'd have to disagree. I wish the world was such that FizzBuzz wasn't an effective filter, but it is. I really like the rest of your questions.

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

Gotcha. Agreed.

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

#75

Post by chc »

patio11 wrote: post #69
zmj wrote: post #66

Earlier quoted context omitted.

I'm not sure I understood you correctly about FizzBuzz, but if you're saying that it isn't necessary then I'd have to disagree. I wish the world was such that FizzBuzz wasn't an effective filter, but it is. I really like the rest of your questions.

Thomas is saying that the hiring process for programmers is so comprehensively fubared that asking the FizzBuzz question to someone who has worked as a senior developer for 8 years at a well-regarded firm provides valuable signal and that if you fail to ask it you might hire people who are completely incapable of programming even with your fancy-dancy recruiting process, which shows that the pipeline and standard int…

Essentially: It is not common for doctors to be asked to locate the interviewer's mouth, ears and thumbs. If an interviewer asked that kind of thing, you'd really have to suspect that he couldn't tell a good doctor from a bad one.

But programming interviewers do need to ask this kind of thing. So you really have to suspect…

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

#76

Post by krupan »

A lot of discussion here about memorizing the programming questions, but I think the most interesting part of this is when he turned the tables at the Do You Have Any Questions For Me stage and really interviewed them.

I haven't asked anyone a programming questions like he did, but I did ask some tough questions about the team, work environment, management style, company goals (looking for a quick exit? in for the long haul? etc.) at my last job interview (after some good friends gave me the advice) and it both gave me a lot of insight into the company and team that I was considering working for, and I think it impressed them that I was thinking about those things.

In short, know what you want from a team, manager, and company, and take time to interview the people interviewing you to make sure they have what you are looking for.

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

#77

Post by [deleted] »

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…

[deleted]

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

#78

Post by [deleted] »

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…

[deleted]

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

#79

Post by systemizer »

I had a similar experience. This past Fall, I was interviewing with multiple companies, and I received questions that were very similar.... some being the same exact thing. I was nice, however, and told them out front that I had seen the problem before and asked for another.

I don't regret doing that; some may have passed the interview by keeping quiet even though they had seen the problem, but those people won't go far in the world because they cheat. They will eventually get called out for it and lose their reputation.

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

#80

Post by tptacek »

tedunangst wrote: post #73
tptacek wrote: post #55

Earlier quoted context omitted.

Can you show me your list implementation? I just installed rbx and tried this; the Array implementation ran in single-digit seconds, but I gave up and CTR-C'd the list one (which works fine for smaller lists).

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 long I kill the process. Step (4) takes a barely perceptible amount of time. (Both in Rubinius).

It looks to me like:

* You're using much smaller data structures than I am

* Your "Array" case is still building Link objects, so still incurs the object management overhead

* You're inserting at the head of the list every time, which doesn't incur seek time. But inserts at the head or tail of a contiguous array don't need to seek or reallocate either.

Post reply on HN