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

61–70 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#61

Post by softbuilder »

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

>And programmers are asked to program

Programmers are almost never asked to program. They are asked to solve 50-year old CS problems on a whiteboard.

Re: How to Crack the Toughest Coding Interviews

#62

Post by glaak »

nandemo wrote: post #46
drivebyacct2 wrote: post #33

Earlier quoted context omitted.

>And if you cannot come up with an optimal algorithm for a given problem, all of the items mentioned in the article (communication, clear coding, testing) don't really matter. That's just not true and if any company is only interested in whether or not I can generate a correct answer under pressure in 20 minutes, then I'm not interested in working for you.

You seem to be disagreeing with something I haven't said. I'm simply describing my experience interviewing at Google: I didn't give an optimal solution to a couple of problems, and didn't get an offer. So I infer that the other items mentioned in the article don't matter as much for getting a job at Google .

You also did not wear a pink and blue striped hat, and did not get an offer. And yet, you seem to not connect your failure to wear a pink and blue striped hat with your failure to get an offer.

I'd suggest you read the section in the article about how you're evaluated. Yes, how optimal your solution is matters -- of course it does. This doesn't mean that you have to get an optimal answer though. You have to do better than the majority of candidates (maybe ~80% of candidates).

For some problems, being in the top 20% of candidate will mean getting the optimal solution. In other cases, it may not. The optimal algorithm might be trivial, and it might be more about coding skills. In another problem, it might be totally unrealistic to expect that a candidate needs to get the optimal algorithm.

Additionally, you seem to assume that since (according to you) getting the optimal answer is necessary, that it must also be a sufficient condition. That's obviously false. It's entirely possible that a candidate needs to get the optimal answer AND implement it well, in which case these other factors come into play.

Re: How to Crack the Toughest Coding Interviews

#63

Post by mech4bg »

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…

As an interviewer, it always surprised me how little people would prepare for an interview.

For every interview I have done as an interviewee I have studied what I am likely to be asked, what their interview technique is, boned up on the language(s) in question, and tried to think of some interesting questions to ask the interviewer (the last one also includes learning as much as I can about the company and its history). I think these are the basics any interviewee should do - that's just the bare minimum for the big guys. For Google I was pulling out dusty old CS books and revising CS theory and that was still just barely enough preparation.

Meanwhile I've given interviews for a C++ position where the candidate hasn't even had a quick brush up on C++ recently. I've had candidates who do C++ as their JOB and not know how to initialize memory, someone describe "polyformic" behavior, and had a good 75% not know at all how virtual functions work. It blows me away.

Re: How to Crack the Toughest Coding Interviews

#64

Post by jules »

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…

In n-space the problem is almost as easy as in 2-space if you can only go in forward in each dimension. If you can go in both directions and you want to find the number of non self intersecting paths, the problem is hard even in 2-space (as far as I can tell). If you allow paths to be self-intersecting, then the count is obviously infinite. Note that the actual interview question asks you to list all paths, not count them.

To count paths in 2-space from (0,0) to (5,6), you have the operations "X++" and "Y++" which go right and up, respectively. Each increasing path from (0,0) to (5,6) has to be some permutation of 5 times X++ and 6 times Y++. So the count is (5+6)!/(5!6!) where the exclamation mark denotes factorial. This extends to higher dimensions by adding an additional operation "Z++". Then the count to go from (0,0,0) to (5,6,7) is (5+6+7)!/(5!6!7!).

Re: How to Crack the Toughest Coding Interviews

#65

Post by stcredzero »

danielweber wrote: post #59
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?

It was one of those interviews using collabedit.com.

Re: How to Crack the Toughest Coding Interviews

#66

Post by Bakkot »

Symbol wrote: post #52
jsolson wrote: post #32

Earlier quoted context omitted.

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.

I assumed it was intentionally ambiguous (like a lot of problem statements in practice), to see how the interviewees respond. There are a few interesting interpretations, some of which are obviously exponential time, infinite time, or impossible (ie uncountably many solutions).

Re: How to Crack the Toughest Coding Interviews

#67

Post by danielweber »

dabent wrote: post #6

A few other links for those wishing to get familiar with the process: From Google: http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ From MIT: http://courses.csail.mit.edu/iap/interview/materials.php Steve Yegge's well-known advice: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... Essentially it seems to build down to knowledge of data structures and the ability to use them in concert to dev…

> Steve Yegge's well-known advice:

He says:

Don't say "choo choo choo" when you're "thinking".

God damn it. Now I'm going to have to fight the urge to do that during interviews!

Re: How to Crack the Toughest Coding Interviews

#69

Post by Swizec »

jhartmann wrote: post #38
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(…

Just my two cents, Well hash tables might be O(1), but depending on the circumstance they are used in, how they handle collisions, implementation details and the quality of the hashing algorithm they can see real world performance that is not O(1). Inserting into a hash table can cause the hash table to expand, if the hash table is too small you will get collisions, etc. etc. Some choices of hash functions are actual…

Yes yes, of course.

But the answer most certainly isn't "Well I don't know _exactly_ how python does dictionaries, but I would implement them with a prefix tree and there is nothing better". Which is roughly the answer I gave, in different settings. To five interviewers.

Re: How to Crack the Toughest Coding Interviews

#70

Post by account_taken »

Man, I wouldn't do well in these interviews except for the tinyurl.com question. Who thinks at the level of binary tree implementations? I know what they are and how to use them and I had to could remember and implement one, but I don't remember having ever needed to implement one from scratch.

The interview questions I ask are more around problem solving and thinking out of the box but I deal at the web application level not building compilers, databases, etc.

Post reply on HN