
Ask HN: Can engineers from Google or Facebook solve whiteboard questions easily? - franzwong
I don&#x27;t know any people from those companies. I am just curious.
======
dekhn
I work for Google and have never been good at the "Here's an NP-hard problem
you haven't heard of, write correct code for nlogn solution on whiteboard in
language of choice" question. I had to train extensively (reading CLR,
practicing) to be able to pass.

However, large numbers of engineers at Google are very good at solving
whiteboard questions. A lot of it comes from practice, a lot comes from
knowing the common problems and solutions, and a lot comes from knowing the
algorithmic primitives from which modern algorithms are born.

For many, whiteboard questions are "fun"\- in the same way my parents like to
do crossword puzzles for the intellectual exercise, Googlers like to discuss
challenging, abstract-but-related-to-ads-or-search questions.

~~~
amelius
> Here's an NP-hard problem you haven't heard of, write correct code for nlogn
> solution on whiteboard in language of choice

I guess that would be a trick-question then, as nobody ever solved an NP-hard
problem in linearithmic time.

~~~
dekhn
I should have said "n log n heuristic approximate solution" (my defense: I'm
actually a biologist pretending to be a computer scientist).

Many problem solutions at Google are effectively heuristic approximate
solutions to NP-hard problems (or less hard but interesting problems).

There's no trick, they just want to know you can figure out how to compute
things quickly so they can run online in a server or a batch job. And the
things that need to be computed are often problems with high time or space
complexity and the exact answer doesn't need to be known.

~~~
amelius
But I suppose appropriate heuristic solutions are typically only "pondered
about" and not "found" at the whiteboard, because they require extensive
testing with real-world data to see if they are actually efficient in
practice.

~~~
edanm
No, that's not necessarily how it works.

Often (most?) of the time, heuristic solutions are also found by Complexity
Theorists, and they usually can prove that their solution is efficient for
problems with certain characteristics, e.g. random data, not random data in a
particular way, etc. These are then applied by the industry when they come
across problems with these characteristics.

~~~
amelius
Yes, that's simplifying the problem by making assumptions about the data.
Except you often don't know what assumptions you can make. Better to check the
assumptions using the data before devising an algorithm for the given type of
data.

~~~
edanm
I agree in principle. But imo in reality, what actually happens is:

1\. Most data sets are roughly similar (or at least fall into one of a few
cases).

2\. Most algorithms are designed beforehand, on ideas of what data could be,
not necessarily for actual data.

Take for example sort algs. Sure, you could look at your data and devise a
sort that exactly matches it most effectively. But in reality, in most cases,
people just use quick sort, which is proven to be efficient on most data sets.

------
habosa
I work at Google and no it's not easy for us either. I've heard many of my
coworkers joke that if they went through the interview process again they'd
probably fail.

That said I see two kinds of interviewers. One kind (the good kind) takes a
medium difficulty question and uses it to explore the candidate's coding,
algorithms, communication, and problem solving skills.

The other kind has a super hard question with a single algorithmic solution
that tells you nothing about what kind of engineer the person would be. This
kind of interviewer takes too much pleasure in being a gatekeeper to Google.

~~~
jfasi
I also work at Google and what mystifies me when I do interviews is just how
consistently people manage to screw up even the medium difficulty questions. I
used to love asking this question until it was banned:

[https://programmingpraxis.com/2012/01/20/knights-on-a-
keypad...](https://programmingpraxis.com/2012/01/20/knights-on-a-keypad/)

This is a great question because it has several levels of solutions:

1\. A recursive solution that iterates over all sequences, exponential time
and logarithmic in space. Interviewing for T3 (entry level, think college
grad), getting only this far in 45 minutes earns a "leaning no hire" in my
book.

2\. The above solution except with memoization, which reduces the runtime to
linear but requires linear space. This one earns a "leaning hire" from me.

3\. A dynamic programming solution that takes linear time and constant space.
This one gets a "hire" to a "strong hire," depending on the elegance of the
implementation and the strength of the discussion we have around it.

4\. A logarithmic time solution involving adjacency matrices, matrix
multiplication, and binary decomposition of numbers. I've never seen anyone
get this and I only learned about it after months of asking this question.

It's shocking how few candidates actually got as far as solution 1. I kinda
want to open this up to the HN comments section, because this does not strike
me as a brutally difficult problem, but the rate at which people fell on their
faces when presented with this question suggests either something about our
interview process or about the candidates we interview.

EDIT: A clarification about “getting as far as” a particular solution: I’m not
sitting there stone faced taking notes, I provide hints and prods and
suggestions to push candidates toward more optimal solutions. I _want_ the
candidate to get as far as possible because it feels good to watch someone
succeed, but oftentimes they run out of steam or take forever to implement
their solution. In particular with respect to solution 1, if that’s as far as
a candidate can get despite my recommendations, that’s not a good sign for
their algorithmic ability.

~~~
jarsin
> t's shocking how few candidates actually got as far as solution

How many people in the real world sit around and practice dynamic programming
questions all day?? The answer is ZERO!

~~~
kamaal
>>How many people in the real world sit around and practice dynamic
programming questions all day??

You will surprised how many people as a matter of fact actually do this.

In fact for a lot of people the whole purpose of a day job is to pay them
salaries so that practice interview questions to hop on the next jobs.

The bad news is many companies think these sort of puzzle solving skills are
penultimate level of software engineering skills and pay top salaries, so
these people don't even worry about being bad at their current jobs.

Do these for a few years, and pad big brands to your resume and then you are
automatically considered something special and qualified for big title
promotions.

~~~
jarsin
Oh trust me I know. I was being a smart ass and pointing out that only people
that don't live in reality do this stupid shit. Dynamic programming interview
questions, in particular, are the epitome of the absurdity of technical
interviews.

------
jfasi
I often do, both for fun and to prepare myself to give a question I'd like to
use in an interview. The thing about interview questions at Google is there's
a _very_ fine line they need to walk: if they're too easy they give no useful
information about the candidate, and if they're too hard they can never be
solved in 45 minutes, again yielding no useful information. You also need to
be able to provide some hints, because the vast majority of candidates need a
prod in the right direction now and then.

As someone with access to the entire canon of Google interview questions, I've
gone through the 20 or 30 with the highest rating, and none of them are
ridiculously hard. The general pattern is either 1. a coding problem, meaning
a relatively easy algorithm with plenty of opportunities to screw up the
implementation so we can see how well you code and how well you catch your own
errors, test your code, etc and 2. an algorithms problem that's really just a
dressed-up version of some basic algorithm like BFS or dynamic programming so
we can see if you can make the leap from theory to application.

Obviously I'm at an advantage here because I've seen most of the questions in
use today, but whenever I encounter a new one I can intuit what's being asked
and what it'll take to solve. I'm sure other companies have different sorts of
questions that optimize for different things, but for our questions once you
do enough of them you can sort of do any of them.

\--

By the way, in my experience, those seem to be the biggest pitfalls for both
job candidates at Google and programmers I meet in the real world. Sure, you
crammed algorithms before you came here, but can you apply them in any real-
world way? Sure you know your web/mobile app framework back to front, but will
you hit a wall when asked to do something novel? Sure you can write a for loop
to iterate over a data set, but will you fall on your face when that data set
is petabytes in size?

I've become good at Google's questions because they generally test for those
two things: nitty-gritty coding skills and an ability to generalize basic
algorithms. The best candidates are those who know their algorithms inside and
out, have the ability to break down and transform a problem until they can
apply something in their toolkit, and have the coding chops to translate their
concept into an implementation. All skills which, you may notice, make for a
good engineer.

If you've ever wondered why we still do whiteboard interviews, that's why.
Except you can use a chromebook now if you prefer, but you get the point.

~~~
jasondclinton
I kinda agree but think that you are overselling the signal generated. We have
internal data that we can't discuss here that throws some doubt on the signal
from whiteboard interviews of the type described above.

~~~
thewarrior
What CAN you tell us about the internal data ? Why does the process persist if
there's data showing its flawed ?

~~~
jasondclinton
Cribbing from a famous quote: this interview methodology is the worst except
for all of the others. We don't know what a systemic, better interviewing
system would be.

~~~
vonmoltke
I don't agree with your Winnie hijack unless you add "systematic" to that as
well, like you did in the next sentence.

Perhaps the answer is that there _is_ no systematic interviewing system that
actually works well. It seems like trying to create one was the origin of all
this pain, and the cargo-culting by companies that don't need a systematic
process has amplified it.

Interviewing is an inherently social, inherently subjective process. Such
things are highly resistant to systematic approaches.

------
gerbercj
I currently work for Google, and enjoy whiteboard interview questions. When
the questions are well designed there should be a relatively trivial, brute-
force solution. As that solution is explored, it should highlight a bottleneck
(time, space, etc.) that leads naturally to a more elegant solution. I really
enjoy the excitement of finding the inflection point between the two. In
addition, be aware that Google now offers Chromebooks for interviews at many
locations, in case folks are more comfortable typing than writing. A recruiter
can confirm if that option will be available. (See
[https://careers.google.com/how-we-hire/interview/#onsite-
int...](https://careers.google.com/how-we-hire/interview/#onsite-interviews))

------
Aardappel
From the average skill level of Google engineers I know, I would say yes, most
would do a very solid job on the average interview question.

However, you probably wanted to know if that means that they would all get
back in if re-interviewed, and the answer is no. Google is famous for
tolerating huge numbers of false negatives in exchange for a small reduction
in false positives. So, by definition, many would fail, even if they are
capable Google engineers.

When I interviewed, I knew nothing of this process. Which was probably good,
it would have made me a lot more nervous if I had know what lottery I was
about to enter. In fact, I was pretty arrogant, seeing that typical questions
were "just CS", and thinking my CS knowledge was pretty solid, I didn't even
do any prep work. So I was probably pretty lucky to get in.

My own assessment of the 5 interviews I had were that 3 of them went very
well. 1 went so-so (the interviewer assumed I was a webdev and ask me all
sorts of specific server balancing questions, whereas I have worked mostly on
compilers and game engines.. I managed to do ok-ish since I do know
distributed systems). The final one I felt went badly since there I actually
didn't manage to solve the problem the interviewer asked (it was one of those
more puzzle-y questions), but I guess I somehow did ok, since I did what
you're supposed to do in such a situation: show that you're a good
communicator and problem solver even when you don't know the answer.

I was dissapointed in all these interviews since I was hoping for interesting
questions specific to me (how did you implement this type inference
algorithm?) which never came.

Of all the interviews I've conducted for Google since, I've only had a 1:40
ratio of seeing people being accepted, even though plenty seemed highly
capable to me. Usually some other interviewer didn't have quite as good a time
with them as I did. You really need to make all of them happy to pass.

To other answers that joke that these interviews are the hardest thing you'll
do at Google, I'd like to disagree. At least in the teams I've worked, I've
done things that thoroughly stretched my abilities, way beyond the level of
interview questions. Of course they're of a very different nature, but that is
the point: interview questions are very distilled, idealized, and problem
solving in the real world is very messy, and to my mind at least, much more
interesting.

------
pdpi
What do you mean by "whiteboard questions"?

The ones I had at my FB interviews are questions I would describe as "any
competent engineer should be able to solve most of these in an interview slot"
sort of questions — Simple data structures (sometimes explicit, sometimes
implicit as part of the problem statement), simple strategies (breadth first,
depth first), and a basic understanding of time (and space!) complexity.

Of course, you can hike up the difficulty a tonne (e.g. by replacing plain
binary trees with red/black trees) and progressively fewer people will be able
to solve those, but in my experience that's not common in an interview
environment at FB.

Ultimately, the fact that the interview process includes whiteboard questions
means that people at those companies _do_ perform decently (for some
definition of decently) at those problems — that's how people are selected.

~~~
sadamznintern
That’s because the FB process explicitly optimizes for speed. I recently
finished a loop where I solved 2 problems optimally in 2 interviews and 1 in
the last one and I was rejected.

The speed required makes me skeptical many people can solve these problems in
the required time without luck of having seen similar problems before.

~~~
UncleMeat
Did they tell you this? I feel like a lot of candidates think they nailed it
when really they missed important things. I'm not sure I've ever had a
candidate solve my question fully and optimally. This of course is nowhere
near necessary to get a good score but I think that thinking "yep this is as
good as it gets" is a common error.

The hire rate is also super low at the majors so it could have also been
noise.

~~~
sadamznintern
Are you at FB?

One of them did tell me this after his round (said we got further than he
thought we would), the other one explicitly said my solution was optimal and
what he was looking for.

The 2 questions per interview "rule" is an open secret now among people that
have interviewed there. I've never heard of someone who only answered 1 per
round get a follow up or an offer.

*Also, they generally don't move onto a second question if they don't think the first one was good enough.

------
kjeetgill
The question I recently got that I found annoying was this: Given input (4, 2,
3, -1, 5) and output (-30, -60, -40, 120, -24) what's the function between
them?

I don't actually mind doing whiteboard interviews even on minimal prep. I've
gotten a few of the "flagship" company offers and failed a few. I think part
of it is internalising that nothing is going to guarantee you anything. You
can always hit a question you bomb on and have an interviewer that will move
on or bury you for it.

Phone screens are 2-4 questions and on-sites can add another 6-10. A 5% bomb
rate for an on-site question will put you into the 60-70% pass rate.

I'm confident that if I do all the interviews I'll land atleast one offer but
if you're putting all your eggs in one basket you're going to have a rough go
of it.

~~~
newusertoday
what is the answer y = -120/x ?

~~~
awareBrah
product of all elements except self. usually a follow up to this question is
to dissalow the divide operator

~~~
kjeetgill
Yep, so I take it you've seen it. Did you feel it was a good/fair question? I
thought the follow-up was but the original a little arbitrary.

~~~
awareBrah
i dont like the way it was phrased. its better in the original format of just,
given a list of ints, return a list where each elem is product of all except
that elem.

I cant really judge, I would be hapy to have received this on an interview
cause I've seen a variation of the problem on leetcode.

I just went through the interview loops at several FANGS, firs time doing this
and got several offers, including G. I used to be super scared of even
applying for fear of rejection because I thought I wasn't smart enough. I am
self taught with lib arts degree from an average school, low gpa.

but I actually enjoyed learning these problems and figuring out solutions, and
as time went on it got easier and easier. I enjoyed the interview process and
had a good experience everywhere except FB.

my suggestion to those who are striving for FANG is just to keep practicing
the questions and try to have fun with it, and go into the interviews with a
positive, collaborative attitude.

------
hzay
I worked for FB. I like the whiteboard problems and many other engineers like
them too, and I enjoyed discussing or solving similar problems over lunch.
That's probably why they're so prevalent in interviews -- I don't believe they
actually predict a candidate's success in a company. Btw in college, I used to
compete on websites like topcoder, spoj, etc for fun. The interview processes
of many companies drastically favor ppl who did that in college, at least
while hiring in the <10 year experience range.

edit: also worked for google, same story

edit2: I believe most people can learn to solve these problems because a lot
of it is mixing and matching algorithms/techniques that you've practiced. It
just takes time and practice and exposure to a wide variety of problems and
crucially, confidence. I've seen people who somehow strongly believe that
they're not the "algorithmic type" and will never be able to solve these even
if they spend months working on it. :( I've tried and failed multiple times to
convince those ppl that this is a very learnable skill.

~~~
sadamznintern
How do I force myself to find doing those problems to be fun? To me they just
seem painful because they really expose how stupid I am even if I know he
basics.

~~~
jsolson
Start simple: find a list (with answers). Don't try to "solve" them, just read
the questions and try within a minute or so to name a data structure or
algorithm -- something you'd expect most undergraduate intro classes to cover
-- that seems likely to be part of the solution. Check your work, keep track
of which ones you got right/wrong, and move onto the next question.

Re-visit the ones you got wrong first. Try them again, repeat until you've
gotten them all right (this might just be because you remember the solution
from looking it up, that's fine, you'll have plenty of time to forget by the
time we get back to it :).

Now, revisit the ones where you had the right data structure on the first go.
HOW would that data structure help? Go a level deeper on actually trying to
solve it.

I can't guarantee this will be fun, but it should be _fast_. A few minutes
here on there on any given problem, going one level deeper each time you visit
it.

Eventually you'll have the whole algorithm for one of the problems, likely
using some common data structure like a hash map, tree, or heap.

Code it in a language with a good set of algorithmic primitives, use every
tool the library gives you (don't worry about remembering how the data
structures work on this pass). Hopefully with the whole algorithm in mind and
all of the tools at your disposal, this is "just plumbing".

Rinse, repeat.

Somewhere in there, do the same with the complexity analysis (time and
space!).

Next time, try it where you have to build the data structure by hand.

Then one day you'll see a problem not on your original list, and you'll
immediately think "red-black tree with a hash table lookaside buffer, but I
wouldn't want to have to build the RB tree by hand if they asked me to, so AVL
tree because the complexity is the same and I can bang out the code like it's
what I do every morning before breakfast".

Like I said, it might not be fun (at least at first), but it is a way to break
up the practice into digestible chunks. Also it builds on the strategy that
I've seen work best in interviews -- if you treat each step of iterative
deepening of the solution as a point where you'd talk with the interviewer
about what you're thinking and why, you give them a lot to go on about your
thought process and a chance to course correct if you misunderstood the
question or your heuristic for how to approach it simply came up wrong.

~~~
shreyanshd
For someone who is preparing for interviews, this is really good advice. Thank
you.

------
tinderliker
I am a SWE at Google, and yes, most Googlers are pretty good at solving
whiteboard problems. It's not like we are born with those solutions in our
heads, but we enjoy solving those questions especially with other people. It's
a lot of fun to "explore" answers to these questions, and that's what I think
interviews are all about.

I know HN hates whiteboard problems, but just like anything, you get good with
it if you're having fun solving them.

~~~
franzwong
I also want to see how you guys solve these problems. People on youtube videos
already know the answer. They just told you how to solve it. But I can't see
how they approach to get the answer. I think that part is the most interesting
and valuable part for non-talent like me.

~~~
wsy
In my experience, you can't learn that skill by watching others. It is a
practice, like playing chess, or writing Math proofs. So IMHO the only way is
to train. Start with simple problems, and continue from there. Bang your head
against problems for a few hours before looking up the solution. Over time,
you will get better.

Disclaimer: I'm myself not very good at algorithmic puzzles. For a job
application I took a vacation to train solving coding tasks, and was getting
better every day. I got that job, but guess that for a Google application I'd
rather have to train for 3 months.

------
mattm
I came across a guy on Reddit a while back who was currently employed at
Facebook. He thought he'd try making a video of him doing one of Facebook's
interview questions thinking it'd be easy for him to do. He stumbled through
the problem and didn't end up solving it in the timeframe that would have been
allowed.

It was good of him to still post it but it showed that someone currently
employed at Facebook would have been screened out at the phone call stage had
he applied again without any preparation.

~~~
sadamznintern
I remember that video. I thought it was hilarious because the question was so
easy anybody that has done leetcode would be able to identify it and code it
in like 5 minutes. I've gotten it at 4 different companies!

~~~
fspear
would love to watch this, can you share the link?

------
plasticchris
There is a great video lecture where a guy talks about how tough his committee
was, and they denied a series of packets only to be told that the packets were
theirs! Very reassuring.

~~~
morazow
[https://youtu.be/r8RxkpUvxK0?t=536](https://youtu.be/r8RxkpUvxK0?t=536)

------
HillaryBriss
I have no info about whether Google/Facebook programmers can solve whiteboard
questions easily so I expect this comment to be down voted but ...

I'm consistently surprised by the fact that, despite hiring programmers who
are the world's most elite, Google's products and services are just kind of
... plain/average/boring. The products and services are far less amazing than
Google's engineers.

It's like Google takes in geniuses but outputs kind of boring, standard,
average quality products and services with a surprising number of problems and
deficiencies.

~~~
franzwong
It looks like they enjoy creating it instead of making it popular for the end
users. Google+ is a good example.

------
mathattack
A friend who transferred internally to a SW engineering position at Facebook
mentioned they probably couldn’t get in the front door.

------
Eridrus
This is basically the selection criteria for getting a job, why wouldn't they
be?

------
social_quotient
Any good examples of “whiteboard questions”, I’m not super familiar with the
phrasing.

~~~
pps43
Reverse a binary tree, check if a linked list has a loop, find common parent
of two elements in a binary search tree.

------
daly
BALL-PITS and CLOWN NOSES

I worked with a guy, Bob, in our college computer room. Bob had returned to
get his BS after many years in industry. He had great stories. He also had
great advice. He taught me that you can learn a lot about how a company will
treat their employees by paying attention to the way they treat you during the
interview. He suggested several sign that indicated it was best to just "walk
away".

If you go into a restaurant for a professional lunch meeting and they have a
ball-pit / swing set /etc. it might not be the most professional place to hold
the meeting. Just walk away.

If you go to a 5 star restaurant and they want you to wear a clown nose
(Everybody Does It!) Just walk away.

The big scam is "We hire the best and the brightest". "We mandate a whiteboard
test (Everybody Does It)". It is my opinion (based on experience) that
companies that insist on a whiteboard test, despite years of programming on
your resume and open source code, are either Ball-Pit companies (who don't
know what it means to be a professional) or Clown-Nose companies (who know
what it means to be a professional but still treat you like a commodity). Just
walk away.

When you object, please reference one study in a journal that shows that
whiteboard tests are effective in any measure when used during interviews.

I understand why Google does it. I've even interviewed there. They get
thousands of resumes (which they never read, at least nobody did at my
interviews). They have to weed out the "learn coding in 6 weeks" crowd. But
you're a professional. You should expect to be treated like one. You don't ask
your surgeon to cut up hams in an interview. You don't ask your builder to
nail two boards together. Professional accountants are not interviewd by bank
tellers and ask to count change.

Google, like Microsoft before it (remember the "why are manholes round?
quizes?"), have combined the marketing claim "We hire the best and brightest"
with the ball-pit mentality of whiteboarding. Google HR (sorry, People
Resource?) SHOULD be embarrassed but apparently they, and upper management,
LIKE ball-pits.

A real professional interview involves a discussion about what the company
does, what it current problems are (aka why are they hiring), and a discussion
of if you, as a professional, have the skills to solve the problem. What do
they need? How can you contribute? It is likely that your interviewer has no
idea what you are being interviewed for and cannot answer these basic
questions.

We, as professionals, should consider whiteboarding as an insult.

Just walk away.

~~~
marssaxman
I'd have to "just walk away" from the entire industry, since I've never once
in over twenty years had an interview which did _not_ involve a demonstration
of my ability to reason through a problem and communicate a proposed solution
using conversation and a whiteboard. I am a professional, yes, and thinking
about problems and communicating about solutions _is my job_ ; why should I be
offended that someone wants me to show them how I work?

Why would I ever want to hire someone incapable of demonstrating their skills
in such a simple, straightforward way? If you can't solve a toy problem and
explain your solution, or at least have a conversation about the constraints
and tradeoffs as you work on it, how am I to imagine there is any chance you
could be a productive teammate?

~~~
daly
That's nice in theory. But it doesn't fit the facts.

1) The whiteboard questions are unrelated to the job opening.

The interviewers have no idea why you are there. They don't know what your
resume says. They don't know who you might be working for. They don't know
what you might be working on. Would you hire someone to work for you without
knowing if they were going to clean your house, install new lighting, or
rebuild your kitchen? How exactly would you interview a person if you don't
know why you need their skills? Or how their skills are related to the task?
Asking a carpenter to "whiteboard" the steps to clean a bathtub during an
interview is insulting.

2) The interview is being conducted by people who have almost no job
experience.

My experience is that the interviewers are recent college graduates. And that
the whiteboard questions are related to their data structures class. They are
focused on details like worst-case behavior of the algorithm and whether you
can quote the log-log-n asymtotic performance. This entirely ignores the fact
that the actual behavior depends a lot on the actual measured performance.
Take, for example, my paper on garbage collection ([http://daly.axiom-
developer.org/TimothyDaly_files/Bozm84.pdf](http://daly.axiom-
developer.org/TimothyDaly_files/Bozm84.pdf)) where the actual data access
pattern matters. Theoretically strong algorithms usually exhibit bad behavior
because of data access patterns, CPU caches, look-aside buffering, and/or
branch prediction failures.

3) There is no known relation between being effective and being able to
present information.

I know people who are strongly autistic, to the point of not making actual eye
contact or giving any verbal feedback at all, appearing to be "not paying
attention"... and then create beautifully crafted excellent code. I also know
people who "talk a good game" and couldn't write a "hello world" page in html.
Please point me to any study that shows that whiteboarding is an effective way
to judge candidates. Even Google's HR head claims it is ineffective.

4) There is a ball-pit / clown nose aspect to the interview.

"Everybody does it" so wear the clown nose. I've had a fair number of
interviews in my 48 year career. Most of them were with people who needed
something done and I could demonstrate my ability to do that. Interviews exist
for a reason. Asking me to whiteboard Knuth-Bendix because you're writing an
editor is reasonable. But the same question for a customer service job would
be nonsense.

These "clown-nose" interviews are simply insulting and a waste of time. Walk
away.

~~~
marssaxman
Your theory does not fit my facts, and I can't relate to your "clown-nose"
metaphor. I respect the fact that you've been working in the industry almost
twice as long as I have; but if the environment you describe were as universal
as you are making it out to be, I would expect to have encountered it by now
(and I have interviewed at both Google and Facebook, as per the original
question, along with plenty of others).

With regard to your point #1, it's not that the questions themselves must
necessarily be related to the specific job one is interviewing for; it is that
the process of communicating about problems and collaborating in the
investigation of potential solutions represents the core of the profession. I
have no idea what you mean by "no known relation" in point #3; there certainly
are niches in which someone capable of nothing more than writing code might be
able to eke out a living, but for the most part software engineering consists
of interpreting user needs and definitions of problems, investigating those
problems sufficiently to derive specifics, designing solutions which make
appropriately balanced trade-offs, and communicating plans and progress in
order to ensure that the proposed solutions satisfy customer needs. Sure,
there's also a little typing of code every now and then, but if that's all
someone brings to the table their potential contribution is very limited.

I am not aware of any studies which provide any meaningful data about software
interviewing practices; we are all guessing. I would take the complaints about
the use of whiteboards and toy problems in technical interviews more seriously
if the people making such arguments were able to present a superior
alternative, but the proposals I've heard sound even more like your "clown-
nose" concept than the system we're used to.

~~~
daly
The environment I describe is not universal, nor did I claim it was. In fact,
I am advocating walking away from the subset of companies that do whiteboard
interviews.

About your reply for point #1, I agree that communication and collaboration
are important. I have picked up chalk (I'm old) during an interview in order
to draw diagrams related to robot paths. But you'll note that _I_ decided that
the chalk-talk was an effective way to communicate essentially visual
information. A "whiteboard" interview is one where the interviewer decides
that I need to use a whiteboard to communicate. Coding is not a whiteboard
activity and the medium choice is inappropriate. I rarely choose to
communicate algorithms with an interpretive dance for that very reason.

About your reply to point #3, in any large company it is highly unlikely that
a single, new-hire person would have such a broad scope of activity. Hiring a
person of that scope would cause me to invest in background checks and
presentations by the person showing their prior projects, designs, and
outcomes. I certainly would learn nothing by asking them to reverse a tree on
a whiteboard in 20 minutes.

As to your final point, I did present a superior alternative. Have the hiring
manager talk to the person about the job opening and the skills expected. Ask
the person to provide related background information from their prior
experience. Ask them about how they might appoach a current or previous
problem related to the job opening. If _THEY_ want to use the chalkboard to
communicate that's fine.

An interview tells you a lot about a company and how it treats employees. If
you see a "sea of desks" in a supermarket-sized open-plan floor you can assume
you're "just another ball in the ball-pit". If they hold meetings in a
fisherman's net strung from the ceiling (I wish I made that up, but no...)
then you can assume they have a playground mentality. If they are proud of
their "80 hour weeks" you can assume your pay rate is only half what it
claims. If "free food" is given as the best reason to work there, you can
assume the work is painful and boring. And, to the original point, if the
interview process resembles a frat-house hazing-style "paddle line" of
unrelated interviews, you can assume a frat-house "good culture fit"
mentality. Every frat house strives for a monoculture (as in, "we only hire
the best and the brightest").

But if you're a professional, working every day to improve your skills and
breadth of knowledge and experience, then respect yourself. Walk away.

------
sadamznintern
Yes they absolutely can.

~~~
smt88
The other comments for this post seems to cast doubt on your assertion that
they all can.

Also, solving them in an interview is radically different from solving them
for fun.

~~~
sadamznintern
I know a lot of people at top companies. All of them have an innate ability to
do these algorithm problems better than people like me - they can crank out
solutions quickly and get offers almost everywhere they try.

------
HugoDaniel
Yes because they only hire the absolute best

~~~
sadamznintern
Top 1% of intelligence

~~~
icedchai
About 8 years ago, I got an interview at Google. I didn't really even want to
work there... I just wanted to see what the place was like. So I made it
through the phone screens, went to the interview, and I failed. It was still a
good experience!

~~~
HugoDaniel
"I got an interview at Google. I didn't really even want to work there... I
just wanted to see what the place was like"

... sure

~~~
icedchai
I wanted to see if I could get in.

I don't like large corps, period.

