

How to: Pass a Silicon Valley Software Engineering Interview - zengr
http://paultyma.blogspot.com/2007/03/howto-pass-silicon-valley-software.html

======
pjscott
Incidentally, the sorting algorithm described here is a counting sort:

<http://en.wikipedia.org/wiki/Counting_sort>

When you're trying to get nice low asymptotic time bounds on things, it can
really help to remember counting sort, radix sort, and tries. Counting and
radix sort are O(n), and tries are a really handy data structure with the same
worst-case asymptotic time as the expected amortized time of hash tables. They
also support in-order key traversal and prefix/range queries.

~~~
thurn
It's probably worth noting that Radix sort is actually O(nk) with keys of
length k, and that k is O(lg n) for many reasonable key representations (e.g.
integers), giving an actual bound no better than a standard merge sort.

~~~
bartonfink
In reasonable key representations, k would be constant and hence ignored in
algorithmic analysis. In 32 bit integers, for example, 0 takes just as many
bits as 2^32 - 1 and you have to compare them all each time.

~~~
jacobolus
Since you sort by digit, if you're going to make your radix be the size of an
integer, you'll to construct that many empty lists; in actual practical
implementations of radix sort, the radix is some relatively small number, and
so you end up with O(nk). I guess if you want you can say that k is actually
O(log(maxint)), if all of your integers are < maxint. But that ends up being
quite a sizable constant term if you really want to consider it constant. If
you're going to do algorithmic analysis that entirely ignores large constants,
it's a bit strange to simultaneously declare that all your integers will be
bounded by some particular cutoff.

------
ares2012
Very good advice. This is the best suggestion: "As I've said before - the
interview is very very honest. Its about you, the whiteboard, and what you can
do."

In the interviews we do we include a written exercise you have to complete
before you come in the door so that we can sit and talk about a problem you've
been able to solve at your own pace - instead of seeing how well you think on
your feet. Even then people try to come up with the fastest solution instead
of something that represents them well.

Remember that the interviewer is always more impressed with a right answer
than a fast answer.

------
gaius
_Also - forget technical religion._

Hah! When I interviewed at Google, I turned down the invite to the next round
because it felt more like a cult than an engineering organization.

 _if Google stopped paying me tomorrow, I'd still come to work_

Exactly.

------
dschobel
An old but good article. Might be worth amending the title to reflect that
this is from 2007.

------
georgieporgie
_They do that stuff in their spare time - its not just a job, its what they do
because they love it._

Is there any other professional career where it's common practice to expect
candidates to practice their profession in their spare time? My CPA ex never
came home and crunched numbers for fun. My doctor never mentioned diagnosing
his neighbors to relax.

This seems like a self-deluded way to weed out people who have families,
physical limitations or injuries that prompt them to get away from their
computer, etc.

~~~
wikyd
I bet that expectation applies to writers, designers, and other creative jobs.
I'm not sure what you consider the line is for "professional career."

The test probably does weed out good engineers, but I would rather have a test
for employees that yields more false negatives than false positives. I know
plenty of people with families that also code in their spare time as a hobby.

~~~
Retric
And I bet it's simply another form of age discrimination.

People like to pretend that keeping up with the latest trends in computing
takes a lot of time. But, mostly it's new people falling in love with old
ideas. Consider, from a C background Ruby would seem extremely innovative,
less so if you know C and python, and if you know C, python, and Lisp it's
just not that novel.

PS: Sometimes people are not exceeded about bulb because they have never heard
of it. Other times they know more about it than you do and are simply not
impressed by yet another remix of really old ideas.

~~~
mkramlich
You nailed why I for one am not impressed/excited by Ruby. If the only
language I had/knew before Ruby was say COBOL, Ruby would look like an
orgasmic programming utopia. But if you have more experience under your belt,
both with other languages, and with readability and long-term maintenance,
then Ruby looks much less interesting. Not completely without interest/merits,
just much less so.

------
NY_USA_Hacker
His grandmother knew radix sort. It's well known that, on sufficiently short
keys and sufficiently many records, radix sort beats the (n)ln(n) sort
algorithms such as heap sort and, thus, beats the Gleason bound. How? The
Gleason bound is only for sorting by comparing pairs of keys, and radix sort
doesn't do that. Maybe his grandmother had a job with punch cards: The old
punch card sorter used radix sort. Of course Knuth covers radix sort in TACP.
However I've always thought that his claim that radix sort was especially good
for a pipelined processor was wrong.

The whole column and its approach and values are wrong. If Silicon Valley and
Google are recruiting that way, and I suspect that they are, then GOOD because
it means that competing with them should be easy. Basically the author just
nearly totally fails to understand what's important in computing or what
qualifications are important.

It's an old story: In a well run technology company, HR is absolutely,
positively forbidden to engage job candidates in any meaningful sense
whatsoever on threat of immediate reassignment to the toilet squad. All HR can
do is push paper and keep records, smile, bring coffee, tea, soda, or donuts,
make travel arrangements, etc.

~~~
bnoordhuis
> His grandmother knew radix sort.

Radix sort? I read it as a trick question where the answer is 'hash table with
numberOfYearsOld as the key'.

I suggested that as the solution to an almost identical question when
interviewing with Google - and it got rejected by the interviewer. Ah, the
arbitrariness of it all!

~~~
anonymoushn
First, 'hash table' isn't a sorting algorithm. If you apply 'hash table' to an
array the result is not a sorted array.

Second, assuming that numberOfYearsOld takes on at most 100 unique values
(which I think is reasonable), the best you can hope for is for every hash
table insertion and lookup to require you to traverse an average of 5000
students (because on average you will have to look through half of a list of
10,000 students). If you used this as an intermediate step in a real sorting
algorithm, your sort would take O(n^2) time.

~~~
anxrn
Using a hash table as auxiliary storage is a perfectly reasonable 'sorting
algorithm'. He's not asking you to name one of the common sorting algorithms.
He's asking you to solve a sorting problem, with a loosening of the usual
limited memory constraint.

Once you've scanned the list, why do you have to traverse the 100 lists at all
(unless you want to further sort them on 'name')? You just need to merge all
the lists (In the mom case, simple concatenate all the stacks). This is a
constant time operation.

The 'trick' here is to think about how would you implement a sort if you had
no memory constraints. As the blogger rightly says, engineers will usually
pick one of the standard ones without thinking (I would surely do the same).

~~~
anonymoushn
I guess a candidate could say "I would solve this problem by making a hash
table keyed on the number of years, except that unlike the hash table that
ships with my language, this hash table will expose its constituent linked
lists to me directly, guarantee that each unique key maps to a different
bucket, and not enforce uniqueness of elements (so as to avoid performing a
linear scan of the element's bucket upon insertion)." I probably wouldn't
reject someone who said that, but I would wonder what prompted such a complex
answer.

~~~
anxrn
\- Which programming language 'complicates' storing list objects in a hash
map? Downright trivial in all languages I can think in (Java, C++, Perl, Ruby,
Python)

\- What do you mean by uniqueness of elements? There's no mention of sorting
by a secondary criterion, if that's what you mean. Which 'standard' sorting
algorithm removes duplicates?

\- What do you mean by 'unique key maps to a different bucket'? You'd only
have to worry about this if you're designing a hashing algorithm, clearly
that's not the problem here. You're hashing on age (hence guaranteeing
partition on age), and simply adding objects to a list in the hash. Are you
implying we'll have to invent a new hash map to solve this problem?

This is literally less than 10 LoC in any high-level language. That
'complexity' surely seems worth O(n) running time?

~~~
anonymoushn
My understanding of bnoordhuis' proposed was that the elements of the hash
table would be students, rather than lists of students.

~~~
bnoordhuis
The language was C and my solution (adapted to the article) was something like
this:

    
    
        // TODO enforce! see also: soylent green
        #define MAX_AGE 100
    
        struct student {
            const char *name;
            int age;
        };
    
        struct students {
            long n_students;
            struct student *students[10e6];
        };
    
        struct students all_students[MAX_AGE];
    
        void insert(struct student *s) {
            struct students *ss = &all_students[s->age];
            ss->students[ss->n_students++] = s;
        }
    

So O(1) insertion and O(n) post-processing to stitch the arrays together
again. Seems like pretty acceptable performance to me but the Google guy
thought otherwise, the answer he was looking for was (probably) a counting
sort.

I tried to argue that my solution was a fair bit faster and simpler to boot.
That's probably why I didn't get a follow-up interview - no-one likes a smart
arse. :-)

~~~
anonymoushn
Thanks, I'm sorry I misunderstood your brief description.

There's no hash table here, this is just bucket sort. I don't think anyone
should care about the difference between counting sort and bucket sort,
though. The only thing I would mind about this is that it allocates 100x the
necessary memory, but I'm sure you wouldn't actually do that when it matters.

