Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Crack the Toughest Coding Interviews

gklst.tumblr.com

Post reply on HN
Print view View original

21–30 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#21

Post by glaak »

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

Re: How to Crack the Toughest Coding Interviews

#22

Post by kami8845 »

Swizec wrote: post #9
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…

In order: Do you use git? How do you do ticketing? What's it like working here? In my experience engineers at big companies will not give you an answer to those, but canned marketing responses. I don't know why.

You have to be more sneaky. Rather than asking something as generic as

>What's it like working here?

ask them

>What do you like the most about working here?

If they give you something like "the stability" or "the high pay" those are generally bad signs. Better signs would for example be "the great people I get to work with every day" or "the autonomy to get to choose what I work on".

Re: How to Crack the Toughest Coding Interviews

#24

Post by MetalMASK »

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…

"How stable is the team (meaning, how frequently does the team change members)"

Re: How to Crack the Toughest Coding Interviews

#25

Post by DannyBee »

glaak wrote: post #14
DannyBee wrote: post #2

Google does not have just one hiring committee, and anyone can be on hiring committees if they want to and one of the committees has a need of new members (IE it's not invite only). So this is like saying "ex-Python-dev mailing list member".

Actually, it was invite-only when I was there. But that's sort of besides the point. It's irrelevant whether or not it's an "honor" to be on the hiring committee. The point is that being on the hiring committee does give you some insight as to why people tend to get rejected. Without being on the hiring committee, you really only see why you're rejecting people -- smaller sample size, biased, less diversity of questi…

I'm on 3 of our hiring committees, and i've been at google for over 6 years. It hasn't been invite only for as long i've been here, AFAIK. Either that, or I was secretly invited!

It is irrelevant whether it's an honor, but as to whether it gives you insight, you are generally right but you did miss an important point:

The vast majority of people who are "members" of a given hiring committee often don't show up every week. A lot, in fact, show up never, but are still members. (for example, they were part of it years ago and nobody removed them, they got asked, said yes, never actually did anything, etc)

So while you are correct that it does give you some insight if you actively participated, simply being a "member" of a hiring committee is a necessary but not sufficient condition to say that you have that insight.

Re: How to Crack the Toughest Coding Interviews

#26

Post by theorique »

pacaro wrote: post #16
alanctgardner2 wrote: post #4

Earlier quoted context omitted.

You can be an excellent coder and suck at interviews. This post has nothing to do with hard skills about algorithms, and everything to do with how you present your work. A lot of good coders might miss out on jobs they want because this is an unusual situation they werent prepared for.

I've interviewed a lot of people (at Microsoft). I don't claim to be good at it, I think that I do OK, but that's why one interviewers opinion should never be the be all. I've definitely encountered people who were clearly good, and equally clearly sucked at interviewing, as an interviewer I had to ask myself the question "why?" I encountered the following cases (among others)... The ill-prepared - This may come down…

In more recent interviews, companies I've worked at have had the candidate sit at a laptop and essentially pair program with the interviewer.

This avoids avoid that artificial write code as fast as you can with a whiteboard marker situation. Granted, it's not their regular dev setup and it's probably an unfamiliar keyboard and trackpad, but it seems to be better than the alternative.

Re: How to Crack the Toughest Coding Interviews

#27

Post by abecedarius »

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

Re: How to Crack the Toughest Coding Interviews

#28

Post by [deleted] »

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

[deleted]

Re: How to Crack the Toughest Coding Interviews

#29

Post by Zenst »

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.

Indeed, sometimes the question is silly and you should not be afriad to question it. I was once asked about video conferencing in detail for some task and explained that recording via VCR and sending the output via tape would be more suitable and cost effective for what they were trying to use it for. You have to look at the initial question and peel of the layers until you find the reason for the question and then you can address the true problem. Sometimes somebody will ask how to computerise this and you will ook at it and sometimes find yourself asking how does it work now and again sometimes saying that what they have is already better or as good as a computerised system to that problem.

In this cube land question you can answear, how are you defining the centre and just revering that process will already give you the code you require. What they are doing you don't know so you have to ask, may be they are trying to reinvent a wheel and with that the best answear may be how to draw a circle as there question is flawed. This is the problem with made up interview questions, if they are based upon real world experience then you get a good question that you can truely answear. You may have a better answear or approach which with them having lived it, makes enough sence to know you would of saved them 2 days debugging that problem and thats from a quick chat walking of the street. If it is a made up question then your approach and alternative answear can be missed and ignored and your genius is not appreicieated.

Post reply on HN