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

101–110 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#101

Post by pacaro »

malyk wrote: post #97
mech4bg wrote: post #63

Earlier quoted context omitted.

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

I've never studied for an interview. I guess I have some internal feeling that you should hire me based on what I know...not what I crammed for the night(s) before an interview. Or maybe it's confidence? I don't know. I've been programming professionally for over 10 years. I think I should be able to sit down and work out almost any problem in an interview. I've definitely been to interviews where I ran into issues a…

I think this is an interesting one, I might make a distinction between studying and preparing. Working through some interview questions as an exercise in intentional practice provides a different type of preparedness from trying to cram CS theory that you don't truly grok. I think that the former helps you manage the unfamiliar interview scenario better, the latter can lead to you digging huge holes when you start talking about something that you don't know much about.

There is also a difference between an experienced industry hire - as you say, if you've been doing this for 10 years you can go into an interview and show them a pretty good picture of what they are getting - and a less experienced or campus hire, where what is important might be an expression of potential - the practice helps with letting the interviewer see that, if your interview is the first time you've tried to code at a whiteboard, or solve a problem with someone trying to push you to the edge of your comfort zone, then you are doing yourself a disservice.

I have, however, encountered candidates who just didn't know, they didn't go to a top school (or indeed any school), they haven't worked in this environment, they don't have any understanding of what to expect - even the simple web-search that would have warned them requires some level of a priori knowledge - not every candidate has that - I suspect most of these candidates do badly, but just watching how someone learns through a day of interviews tells you something, that higher level bit about learning when in over your head is one of the most valuable.

Re: How to Crack the Toughest Coding Interviews

#102

Post by wting »

barbs wrote: post #92
wting wrote: post #91

Earlier quoted context omitted.

Her "Crack the Coding Interview" book basically is an expansion of that blog post, goes into more details, includes a lot of problem sets of different types and various strategies for attacking each one. I like using it to study for interviews. It's not sufficient by itself, but will get you 75% of the way there. *Disclaimer: I'm 3 degrees of separation away from the author. :p

Sounds a like a good recommendation to me, thanks :). What would you recommend for the remaining 25% of the way?

It's probably personally dependent to shore up your own weaknesses.

Mine would probably more practice with recursion, dynamic programming, graph theory.

Re: How to Crack the Toughest Coding Interviews

#103

Post by pjscott »

JoshTriplett wrote: post #54
abecedarius wrote: post #27

Earlier quoted context omitted.

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…

Well put. I'd like to add that, while hashing time is proportional to the key length, in practice it's very, very fast for all non-enormous keys, at least on modern processors. Compare with the cost of pointer-chasing in a tree, and hashing time starts to look pretty constant-ish.

(Yes I'm handwaving around the details. So is everyone who talks about big-O notation in connection with real software.)

Re: How to Crack the Toughest Coding Interviews

#104

Post by maeon3 »

danielweber wrote: post #67
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!

The "choo choo choo" people make my skin crawl. Not sure why. It could be subconscious because everyone I've met in life who did that was not good for my career to associate with them.

Re: How to Crack the Toughest Coding Interviews

#106

Post by seiko55 »

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…

ok, one question: certainly you guys are great coders to be in working in these companies, but is every single person there for sure going to give the best possible answer to these questions every single time if asked?

Thanks

Re: How to Crack the Toughest Coding Interviews

#107

Post by seiko55 »

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.

you are a googler, right? i think we've seen your posts.

Re: How to Crack the Toughest Coding Interviews

#108

Post by pjscott »

Someone wrote: post #72
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…

"I vaguely recall counting lattice paths in 3-space being a wickedly hard problem with no known polynomial time solution." I think you can easily write the recursion: p(x,y,z) = p(x-1,y,z) + p(x,y-1,z) + p(x,y,z-1) Leave out the term with x-1, y-1, or z-1 for the edge cases for x, y, and/or z equal to zero. With that in hand, it is easy to compute all values bottom up, starting with those where x+y+z = 0, 1, 2, etc.…

You're assuming that all movement must be in one of three directions, but in general, you can go in six directions -- forward or backward along the x, y, and z axes. Your cubic-time DP algorithm doesn't solve the self-avoiding walk problem, which I think is what jsolson vagely recalls.

http://en.wikipedia.org/wiki/Self-avoiding_walk

Re: How to Crack the Toughest Coding Interviews

#109

Post by maeon3 »

Jach wrote: post #36
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…

Here's a list of 100 questions applicants should consider asking a subset of during the interview: http://www.basilv.com/psd/blog/2009/100-interview-questions-...

Joel test is far more revealing: http://www.joelonsoftware.com/articles/fog0000000043.html

Re: How to Crack the Toughest Coding Interviews

#110

Post by famousactress »

icelancer wrote: post #93
famousactress wrote: post #79

Earlier quoted context omitted.

I ask some questions about test coverage, coding standards, code reviews.. I'm sometimes more interested in whether I get the same answers from different people or not than the particulars. I always ask for an example of a technical or tools decision that was made. I'm usually looking to see whether decision-making is well distributed or things get bottlenecked by a manage or lead. Probably most of all I pick at how…

I don't agree with: >Do you have a sales team? If customers need to call in and speak to engineers or other non-business people to negotiate sales, that sucks. Having inbound sales people is a vital part of any good mid-sized company.

If you need humans to sell things, then of course I agree that you ought to have a sales team. I would just rather work somewhere that doesn't need humans to sell things.

The problem I have with sales is that they're often very good at what they do. Once you have sales, you have two products. Your sales folks, and the thing people think they're paying you for. It gets hard to know which one is failing, or worse.. succeeding.

Post reply on HN