How to Crack the Toughest Coding Interviews • Hacker News Board

Re: How to Crack the Toughest Coding Interviews

#51

Post by glaak » Fri, Oct 26, 2012, 10:10 PM UTC

glaak wrote: post #21

jsnk wrote: post #13

I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

"whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit."

Agreed. That would be bullshit. And those are bad interviewers if they do any of that. Companies like Microsoft, Google, Amazon, and Facebook don't do that, as a general rule. I'm sure you could find bad interviewers at any company though.

Re: How to Crack the Toughest Coding Interviews

#52

Post by Symbol » Fri, Oct 26, 2012, 10:11 PM UTC

jsolson wrote: post #32

haberman wrote: post #17

> Given a cube with sides length n, write code to print all possible paths from the center to the surface. What is a path through a cube? This seems like some weird combination of graph theory and geometry.

Perhaps they're assuming that the cube is a set of integral points and they want you to count lattice paths. This is trivial in 2-space (e.g., give me the number of paths that go from (0,0) to (5,5) by going only up or right one point with each move (that is, each move is either (0,1) or (1,0))). However, I vaguely recall counting lattice paths in 3-space being a wickedly hard problem with no known polynomial time so…

Glad I'm not the only one who thought this problem statement must be missing constraints if they expect a code solution on a whiteboard.

Re: How to Crack the Toughest Coding Interviews

#53

Post by suyash » Fri, Oct 26, 2012, 10:12 PM UTC

ionwake wrote: post #19

Am in the only 30 year old coder here, who earns around £300 a day coding, but would fucking die in one of these interviews?

you get paid daily..what kind of company is this?

Re: How to Crack the Toughest Coding Interviews

#54

Post by JoshTriplett » Fri, Oct 26, 2012, 10:13 PM UTC

abecedarius wrote: post #27

Swizec wrote: post #8

I shared my experience in a blogpost: http://swizec.com/blog/inside-a-google-onsite-interview/swiz... A few days ago I finally realized why they said I'm not good enough at big-O to play with them (despite saying my coding was excellent). For some reason I had a mental block that day and wanted to implement hash tables as prefix trees every single fucking time . I have no idea why. Of course I know a hash table is O(…

Hm? Hashing is O(N) unless it's oblivious to some bits. Though the prefix tree part is optional, yes. :-) Better luck next time. (For some reason programmers really love tries / prefix trees when answering on stackoverflow and such. I'd like to understand why -- tries are neat, but you don't see them nearly as much in actual use.)

> Hashing is O(N) unless it's oblivious to some bits.

O(N) only makes sense when you agree on what N means. When using big-O notation, always make sure you agree on the base N values you want to work with. In this case, it sounds like you interpreted N as the number of bits to hash, in which case yes, any sensible hash algorithm has to look at all the bits so it'll use an O(N) algorithm. However, the post you replied to talked about hash tables, a structure used to implement (among other things) maps from keys to values. For such a structure, N refers to the number of items stored in the table; hash tables have the rather unique property of supporting O(1) insertion, removal, and lookups (modulo amortization arguments about the size of the table).

Re: How to Crack the Toughest Coding Interviews

#55

Post by j_baker » Fri, Oct 26, 2012, 10:14 PM UTC

Zenst wrote: post #5

Interviews work both ways - what questions do you ask them? One I used to ask was do you have IS9002/BS5750, but that was 15 years ago and there are better questions to ask. A good question is also sometimes better than a good answear as it shows you understand things from another perspective and have the ability to ask questions instead of blindly accepting what you are told all the time if your unsure. So what are…

A good way to ask questions is to use them conversationally. For example:

interviewer: What is Cassandra useful for?

interviewee: It's useful as a highly-available database if you can denormalize your data. What are you guys using Cassandra for?

interviewer: Well, we're using it to...

interviewee: Interesting. How's that working for you guys?

This not only can get you some valuable information to make your decision, but also looks confident as you're exercising some control over the interview. You just have to be careful not to derail the interview with this technique, or you'll come off cocky and arrogant.

Re: How to Crack the Toughest Coding Interviews

#56

Post by timr » Fri, Oct 26, 2012, 10:15 PM UTC

Swizec wrote: post #8

I shared my experience in a blogpost: http://swizec.com/blog/inside-a-google-onsite-interview/swiz... A few days ago I finally realized why they said I'm not good enough at big-O to play with them (despite saying my coding was excellent). For some reason I had a mental block that day and wanted to implement hash tables as prefix trees every single fucking time . I have no idea why. Of course I know a hash table is O(…

A hash table lookup is O(n), where n is the number of elements in the table. They have amortized constant time lookup (i.e. constant time in the average case).

Re: How to Crack the Toughest Coding Interviews

#57

Post by rhizome » Fri, Oct 26, 2012, 10:15 PM UTC

glaak wrote: post #21

jsnk wrote: post #13

I feel like developer interviews are a cover for conducting an IQ test in a manner that is politically passable. And only people like developers would put up with being tested like lab mice in this manner for a job.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

Should the writer be asked about semiotics, the actor camera techniques?

Re: How to Crack the Toughest Coding Interviews

#58

Post by [deleted] » Fri, Oct 26, 2012, 10:23 PM UTC

jsolson wrote: post #32

haberman wrote: post #17

> Given a cube with sides length n, write code to print all possible paths from the center to the surface. What is a path through a cube? This seems like some weird combination of graph theory and geometry.

Perhaps they're assuming that the cube is a set of integral points and they want you to count lattice paths. This is trivial in 2-space (e.g., give me the number of paths that go from (0,0) to (5,5) by going only up or right one point with each move (that is, each move is either (0,1) or (1,0))). However, I vaguely recall counting lattice paths in 3-space being a wickedly hard problem with no known polynomial time so…

[deleted]

Re: How to Crack the Toughest Coding Interviews

#59

Post by danielweber » Fri, Oct 26, 2012, 10:24 PM UTC

stcredzero wrote: post #37

I think I've been a victim of ageism here in the SF bay area. One member of a group met me in person, and we had a positive experience during the coding interview. (I look young for my age.) I gave him some Python code that solved his problem, as well as a version optimized for common prefixes and another that gave the same tally by user as well as the total aggregate. Note I am not primarily a Python coder, and it's…

Why were you typing while doing a phone interview? Was it related to the interview?

Re: How to Crack the Toughest Coding Interviews

#60

Post by shrughes » Fri, Oct 26, 2012, 10:24 PM UTC

timr wrote: post #56

Swizec wrote: post #8

I shared my experience in a blogpost: http://swizec.com/blog/inside-a-google-onsite-interview/swiz... A few days ago I finally realized why they said I'm not good enough at big-O to play with them (despite saying my coding was excellent). For some reason I had a mental block that day and wanted to implement hash tables as prefix trees every single fucking time . I have no idea why. Of course I know a hash table is O(…

A hash table lookup is O(n), where n is the number of elements in the table. They have amortized constant time lookup (i.e. constant time in the average case).

Or it's O(log n). Depends on how collisions are handled.