How to Crack the Toughest Coding Interviews

There's a lot of information in tones of voice.

Your right about the canned marketing responses, most of those forget the interview is a two-way process sadly and deem any question you ask as a waste of there time, that is a sign you should take note of.

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

Always a good one. I also like a variant on this if they profess to practice agile development:

>How do you implement the agile process?

More times than not, it's a waterfallesque implementation.

Every big company uses Remedy. Some just dress it up a little.

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

And did you miss a negative in your last question?

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

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.

I think you're getting your n's confused. O(n) in the context of a collection applies to the size of the collection, not the size of the keys. Nearly all hash functions for strings are O(n) in the size of the string. This doesn't mean the hash table is O(n) for lookups.

An amortized bound is a bound on the total cost of a sequence of operations. Loosely speaking, it guarantees that you can't keep hitting the worst case indefinitely. An average bound is averaged over all possible inputs, but doesn't protect you against hitting the worst case over and over.

so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your code base. you'll learn a hell of a lot more about what i know, how i communicate, steps i take when i do when i don't know something, and what my processes are. this soft, inter-engineer-social stuff is overlooked over far too often; i wan't to work with people who will amplify my process and abilities, and in turn i'll amplify theirs. smarts don't count for enough.

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.

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

Programmers, however, must take a test. It's not an interview, it's a test. Pass or fail (regardless of what people say), it's a test. It's a test of which you have little preparation for. You hope that what they are looking for is what you can provide. What they are asking for is what they will test for (this is fairly often not the case).

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.

But, yes, I could have been more extensive in my credentials. Unfortunately, "How to Crack the Toughest Coding Interviews by ex-Google engineer, ex-Google hiring committee member who showed up every week, ex-Apple dev, ex-Microsoft dev, author of Cracking the Coding Interview, and author of The Google Resume" was a bit too long :).

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

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)

With that in hand, it is easy to compute all values bottom up, starting with those where x+y+z = 0, 1, 2, etc.

Definitely fewer than (x+y+z)^3 values to compute, all of them in O(1) (disregarding cases where the numbers become bignums)

Generalization to any number of dimensions seems easy, too.

A closed form solution, that might be harder.

Alot of people who fall into the boat of being good coders with social skills of dead fish often have a hard time. One appraoch is to create some wonderous application and get broaght out, recruitment that way. Or in the process, end up refining there social skills to the stage that not only can they interview ok but are running there own company.

Coding interviews should be done via a shared terminal/IDE screen and chat windows, that approach would be more realistic to some. But I'm one of those people who don't socialise too well at times, interviews/exams, that type of thing.

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 to background, some candidates didn't seem to know that they should prepare for an interview - this can be excusable, but in a world where advice about this is one web-search away is increasingly tough. Usually (but not always) this is a barrier to recommending hire.

The chronically nervous - This is always at least 50% my fault. I believe in asymmetric responsibility, as the person with more "power" in the situation, I feel part of my job is to help a candidate past their nerves; if this means my interview is entirely spent putting them at their ease to (potentially) do better with the next person in line, so be it. This has rarely been a barrier to recommending a hire.

The arrogant - "I can't believe you asked me such a demeaning coding question when I'm applying for a senior role, clearly my resume tells you all you need to know about my coding chops" - sorry, if I can't pierce this, no hire.

The inarticulate - often in this case the code speaks, even if the candidate can't, I usually associate this with nerves, sometimes it is language issues, sometimes stress sensitive speech impediments. I'm pretty sympathetic to this if the code speaks, but communication is part of the role so this is always a judgement call.

Can't code on a whiteboard - I'm inclined to call this ill-prepared, you should expect to have to do this coming into the interview, but I do get that this is equivalent and opposite from "inarticulate" - I will take a coherent and detailed description of a solution as being nearly as good as the whiteboard code, but there is a bottom line, you have to be able to show me your ability - sometimes one really insightful question or observation is all that it takes...