
How to Rock an Algorithms Interview - harrisreynolds
http://blog.palantir.com/2011/09/26/how-to-rock-an-algorithms-interview/
======
ohyes
>Given a whiteboard and one hour, determine whether the person across from you
is someone you’d like to work with, in the trenches, for the next n years.

If we ignore the requirements of one hour...

Brute force: Hire a random candidate that hasn't been hired by you before.
Fire them when you get fed up with them. Hire a different candidate. Repeat.

Greedy Algorithm: Develop the model for an ideal candidate, assign that
candidate a numerical model and then compute the distance from the current
candidate to the ideal candidate.* Hire the candidate with the lowest computed
distance. If a candidate comes along with a lower computed distance fire the
old candidate and hire the new one.

Simulated Annealing: As with the greedy algorithm, but instead of hiring based
solely on lowest computed distance, include a small % chance that you will
randomly fire the candidate and hire candidate that is slightly worse.
(Optional extension to the algorithm is to keep the best candidate so far
cached somewhere, potentially a transporter buffer).

Genetic Algorithms: From your pool of candidates, select the top candidates.
Breed these candidates, randomly introducing mutations. Repeat again with the
progeny of the previous pool, until one of the candidates passes a satisficing
threshold 'distance' score.

* = Notice that this is the actually the most difficult part of (almost any useful application of) these algorithms but I managed to hand-wave right through it.

~~~
praptak
Recursive: require the candidate to come up with the perfect hiring strategy.

~~~
geoffschmidt
I'm willing to believe that the ideal candidate is a fixed point under your
operator, but I think it's going to be tricky to prove convergence :)

~~~
eru
And there might be other fixed points, perhaps with even greater catchment
areas.

------
mcantor
FTA:

    
    
        You should know these data structures inside and out.
        What are the insertion/deletion/lookup characteristics?
        (O(log n) for a balanced binary tree, for example.)
    

How does one achieve this? Not just being familiar with data structures and
algorithms (I am), but being _fluent_ in them, to the extent that you can
produce the Big O complexity for different operations off the top of your
head.

I didn't have a traditional CS education in college. Maybe there's some kind
of magic that happens in Algorithms [1-3]01 that permanently etches these
characteristics into your brain. But whatever it is, I missed out.

My main problem is that _I don't seem to need this information to do what I
do_. I work predominantly with server-side, interpreted languages, and I just
_don't run into_ the bottlenecks and performance problems that Big O-knowledge
seems to mitigate. Maybe I've been lucky. Maybe it's because none of my
personal projects have gotten popular enough to be subjected to the kind of
load that reveals such problems. Maybe it's because I haven't worked on the
_kind_ of project that needs this sort of attention. Whatever the reason, I
simply have never hit a point in my work (which I assure you has been non-
trivial at times) when I sat back and said to myself, "Gosh, if only I were
more familiar with the complexity breakdown of the classic data structures, I
would be able to solve this problem much more effectively or efficiently."

The thing is, I know that I'm perfectly capable of nurturing greater fluency
in algorithms, so it seems like a waste to inevitably flub the more demanding
portions of algorithm-based interviews. So what should I do? Is the answer as
simple as biting the bullet and using flash cards until I know it all by rote
(which feels like cheating), or am I "doing it wrong" somehow? Is my lack of
fluency preventing me from understanding just how important it is ( _a la_
Dunning-Kruger)?

~~~
jchonphoenix
Our interviews at Palantir test for these for two reasons:

We evaluate a lot of people coming straight out of school in CS. They don't
have much experience in development. Thus, the best way to test if a candidate
is smart is to see if he's learned his course material well. We do a lot of
heavy algorithms and distributed systems, so we ask that, but it also happens
to be what students learn.

Running time and Oh, however, in addition to systems knowledge, is extremely
important to creating good software in general. If you can't determine how
your software will scale with big data, and you can't understand why efficient
code that runs quickly with small operations does so, you simply can't write
good software.

I realize a lot of people on HN take offense at these claims because they've
written programs without this knowledge and claim they are self taught. The
reality, however, is that they aren't good programmers. You don't need a good
programmer to write a prototype that works and determines market fit. You do
need good programmers to scale your product, add features efficiently, and
architect solutions without making a crippling mess of your code.

Edit: I realize the above comment sounds a little condescending. It wasn't
meant to be. I have met self taught programmers that are amazing. Most people
just don't have the self discipline to fully learn a subject matter (I many
times don't). So a lot of "self taught" programmers have only taught
themselves 10% of what they need to know and never bother learning the other
90%.

~~~
mcantor
I upvoted you for the good explanation (and the refreshingly self-aware edit).
However, I think it is rather presumptuous to paint the broad strokes of
"good" and "bad" without adding so many caveats that it would no longer be
germane to this conversation.

By your definition, I am currently a "bad programmer" because I do not have
fluency in algorithms.

(I will leave the objective truth of this statement as an exercise to the
reader; God knows it might be so. However...)

I contend that I am capable of learning new material quickly enough that, if I
were suddenly called upon at my job to write code which handles all of the
slings and arrows of algorithmic complexity, I would be able to do so with
very little friction. To phrase it differently: I (probably) don't know enough
to write gorgeous, algorithmically sophisticated code on the first pass, but I
know enough to know when it's time for me to hit the books, and where to
start.

Obviously, it would take me longer than someone with prior experience in
writing such code! If the overarching question is "does algorithmic fluency
constitute a dealbreaker when hiring at certain positions", then I suppose the
answer depends on _how much longer_ it would take. I can only speculate on the
difference in a flagrantly biased manner, as I would egotistically prefer to
believe that I ought to be hired in more cases than not. :-)

 _Or_ , if we look through the Dunning-Kruger lens, we may conclude that lack
of algorithmic fluency _always_ constitutes a dealbreaker at certain
positions, because even if the developer in question can learn on the job, he
or she will still make errors and oversights with far-reaching implications
that are _invisible_ \--unknown unknowns--to the algorithmically illiterate.
This feels less plausible to me than the simpler consideration that "learning
on the job" may simply be an undesirable speed bump.

I don't really have any concrete points or refutations to make; I'm just
fascinated by the issue in general and enjoy exploring the possible angles.

(Also I shall likely just cut the Gordian knot and go play with algorithms
until it simply isn't an issue anymore. Go figure)

EDIT: Actually, there is a point I forgot to make:

In your edit you wrote, " _So a lot of "self taught" programmers have only
taught themselves 10% of what they need to know and never bother learning the
other 90%._ " I think this is the crux of the "good/bad" problem: "what they
need to know" is _very_ subjective and dependent on context.

I think it's reasonable to assert that there are programmers out there who
have long and satisfying careers, but never learned _X_ , or didn't learn it
for many years. Who's to say whether they are "good" or "bad"? It's a
judgment, and judgments are meaningless without context: "good programmers
need to know _X_ " doesn't really say anything, but "programmers need to know
_X_ if they want to _Y_ " does.

You certainly went down this road in your comment, but your _Y_ was " _You do
need good programmers to scale your product, add features efficiently, and
architect solutions without making a crippling mess of your code._ ", and I
feel like lack of fluency in algorithms is just not a surefire indicator of
bad architecture skills (among the others you listed) as well.

~~~
groby_b
Based on 20 years of experience, lack of fluency in algorithms _is_ a surefire
indicator of bad architecture skills. Yes, it gives a few false positives, but
the amount of false negatives is pretty much 0.

And since actually getting a new person on-board is an expensive process, you
aim for criteria that are a bit too stringent, if you can afford it.

There's also the issue that making a bad algorithmic decision at the center of
the problem turns scaling into an insanely hard problem, sometimes. It's not
so much about learning about it when you need it, but about avoiding issues in
the first place.

True, there are many places where it truly doesn't matter - but if
scaling/performance matter for your company, you don't want to head down the
garden path because your developers didn't know better.

Not knowing algorithms won't exclude you from all jobs (or even many of them),
but there are some jobs where it _will_ bite you. It's your choice if you want
to go for those jobs. Personally, I think they are where the cool stuff is
happening, but YMMV.

~~~
HardyLeung
I agree with jchonphoenix and groby_b. I'm sure there are a lot of great self-
taught genius who don't have the formal training but does a much better job
than most, but there are orders of magnitude more in the camp of "half-taught"
mediocre programmers, with shiny formal training, that can easily be filtered
out using this approach.

------
MattLaroche
Disclaimer: I work at Palantir Technologies. These are my own opinions and not
my company's.

The Palantir post is great for how to handle yourself when you are already
there. Steve Yegge's "Get That Job at Google" is a great how-to-really-prepare
piece. [http://steve-yegge.blogspot.com/2008/03/get-that-job-at-
goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html)

A couple other suggestions:

* Find sample questions that similar companies use. Work through them. Discover what you don't know. Find if you're weak on dynamic programming, graph algorithms, algorithm analysis, etc. Then get strong on those. The less you want to do sample problems, the more important they are for you.

* When practicing interview questions, whiteboard at least some. Talk through them. Really go through a question in every detail.

* Before you interview at your dream company, interview elsewhere with similar difficulty questions. In my opinion, it should be another company that you'd like to work at but don't covet. If that doesn't work for you, a technical or even a non-technical friend could play the role of interviewer (you'll have to give the non technical friend questions!). Nerves have been a giant issue for me in interviews - and this has significantly helped.

* Calm down as much as you can and forgive yourself when you make errors. The questions at good companies are calibrated to have non-obvious solutions, interviewers expect you to struggle a bit. Candidates who freeze-up and attach their mind to one (usually wrong track) solution fail interviews. I've done it. If you've practiced with the first three bullet points, this should be less likely.

~~~
rhizome
You mean the anti-Wikileaks Palantir?

~~~
jobu
Yes (<http://www.businessinsider.com/palantir-wikileaks-2011-2>), but they
have since have since apologized for that
([http://www.businessinsider.com/palantir-wikileaks-
apology-20...](http://www.businessinsider.com/palantir-wikileaks-
apology-2011-2+)

------
dr_rezzy
For me, this blog post represents a step backwards. They open up saying that
the 1 hour interview provides absolutely no indication of how well a
prospective candidate will perform. Hopefully most people will agree here.
Then they go ahead and state that their staple interview will be an on the
spot problem solving screening and then list the steps the expect the
candidate to take in solving said problem. What does this say about their own
problem solving skills? I will leave this upto the reader. Let me throw an
alternative out. Why don't you give a prospective candidate a written
test/problem and give them as much time as they want, using methods and
environments they are comfortable with, and have them return to you a solution
of their choosing. Wouldn't this best capture how a person breaks down a
problem, solves it, and finally presents a solution? Leave the onsite to
better understand someones personality, likableness, and workability. Maybe
even ask them to walk you thru how they came up with the solution and how they
worked the problem. The options here are plentiful.

~~~
eric-hu
That does seem to be an interview technique used at some companies. It comes
with its own set of problems, though.

What if someone asks a friend for help or pays someone to solve the problem in
its entirety? If your problems aren't unique enough, they could also google
the answers.

With that said, I actually prefer your approach. Its pitfalls have to be
weighed carefully; hiring someone who knew enough to fake it could be a costly
setback for a small company. However, it does remove some unnecessary pressure
from the interview process.

~~~
dr_rezzy
That would only be a risk if we were talking about a typical high school
multiple choice test. I would think that a cheater would be filtered out by
this point in their career (this point being applying to a high tech company).
However, collaborating on a solution is not necessarily a bad thing. I think
the goal here is to find candidates which can deliver unique, valuable, and
insightful problem solving skills. To go ahead and bottle that process up into
a pre determined steps or a 1 hour drill doesnt serve your goals very well.
Who knows, maybe these guys have a recipe which works for them. From my own
experiences, I would disagree.

~~~
regs
You'd be surprised at what people will do to game an interview. I've had
people give me the correct answer to a question I didn't ask (but from our
list of questions) - clearly having gotten from someone else who had
interviewed earlier.

Note that algorithms interviews are just one part of a larger inventory that
one takes of a candidates, one dimension. Take home and/or whiteboard coding
can be a part of that process as well, but each has its downsides.

What we look for, in particular, is methods that have a very low false
positive rate. In person algorithm interviews, where the point is not the
'right' answer but hearing about how someone thinks are in that category. You
can't really fake it.

------
dabent
One thing I noticed in recent interview is that the problems often test if the
candidate can think to use two structures or algorithms to solve a problem.
Early on, I made the mistake of thinking of interview questions more as
homework problems from college where there was often only one type of data
structure or algorithm involved in a problem. That's good when teaching a
single concept, but real-world problem are more complex. My advice is to find
problems that use multiple structures or concepts together and study and code
those.

Also, learn to code the basics so well that you can do them by hand on a basic
text editor or whiteboard. Get so good at it that you can write code that has
a very good chance of running if it were actually compiled/run. I found that
it's very different to code on a whiteboard than it is in an IDE or text
editor. When my first interview came up, I struggled to write down things with
a dry-erase that would have taken me seconds on-screen.

One strategy that I liked to see an employer use was homework. That might make
some job seekers cringe, but gave me a chance to write real code like I would
for a job. It was also a filter for how badly I wanted a job. There were jobs
I didn't complete the homework for just because the location or employer
wasn't something I was genuinely interested in.

I did homework for the position I landed and they did a code review as part of
my interview. It went well, because I got to see how my future co-workers
would handle giving feedback, and some comfort on my end that this employer
actually cared enough to do code reviews.

------
steve8918
The interview process at this point, at least in Silicon Valley, is broken.

There's an arms race between interview "gamers" that memorize all the answers
to every single question out there, vs interviewers that are asking
increasingly ridiculous questions. It's naive to think these days that not
knowing the answer to a common question, but coming up with the answer will
work. It won't. If 9 candidates know the answer right away, and you don't, but
you figure it out, do you honestly think the interviewer will care? I've
talked to plenty of interviewers at my company and that's the unwritten rule.

For example, over the phone, one of my friends was asked to design and give an
algorithm to solve a maze. It took 10+ mins just to understand exactly what
the interviewer wanted, and at that point, time was up, the interviewer was
frustrated, and my friend didn't get the job, even though he's better than me,
technically.

The only way to interview these days, it to know everything.

~~~
regs
It was much cooler to be jaded about the interview process last year.

But in all seriousness, I'm sure there are companies like the one you
described and there are many that aren't that way. I'm certain that your
blanket characterization of 'the interview process, at least in Silicon
Valley' being broken is incorrect.

You don't need to come up with weirder and harder questions. You just want to
give them something in a form that they haven't seen before. It makes them
listen and think, which is what you're looking for.

I always look at an interview to be more like a code review than a unit test:
it's not about getting the right answer, it's how you get there that tells me
what kind of an engineer you are. In fact, if you get the answer too quickly
or jump to it, even if I don't think you're cheating, I need to ask another
question or make you explain yourself in depth so I can probe how you got
there.

------
Blunt
Frankly, I find this type of interview insulting. Let's face it. Unless you
work with "algorithms" on a dialy basis, I'm willing to bet that most who do
not cannot regurgitate a red black tree at the drop of a hat. I work in this
field off in on as an embedded developer and I'm always going to various texts
on the subject to align my thinking with the code I'm writing (C++ in my
case). It's one thing to talk through these scenarios in an interview and it's
yet another to judge one's ability to solve problems on how well they come up
with a solution to an interview question. I give merit to the "talking
through" and this is what I do. I find that if a candidate can carry on an
intelligent conversation about a particular problem domain, he's hirable
material and in 15 years of running my own company I've had only 2 out of 43
people leave my company.

~~~
pjscott
I don't think anybody's asking you to write a red-black tree of the top of
your head, but it would be nice if everybody knew what a balanced tree was and
why they might be useful.

~~~
dhugiaskmak
It would be nice, but I bet the former question is asked far more frequently
than the latter.

------
njharman
>Given a whiteboard and one hour,

We, hiring folks, aren't limited to just that anymore. There's github,
linkedin, hn/reddit posts, random google stalking, etc.

I can find a lot about you, your attitudes, opinions, ability to communicate,
style, etc. that, or you for whatever reason (paranoid, on the lam, aren't
passionate) have zero online presence).

The face to face interview is mostly to confirm or refute what I've already
learned about you.

~~~
esrauch
What about people who don't use their real name online? Do people really give
recruiters their reddit username?

~~~
njharman
More than one application I've handled recently has included links to HN and
LinkedIn profiles. Most list github account.

------
lpolovets
This is a great, meaty blog post. I really like the first point about always
coming up with a brute force solution so that you at least have something, and
so that you have a chance to think about the problem a little. I've seen
candidates skip the brute force approach too many times so that they can
immediately work on a more optimal solution. At the end, they often end up
without any solution at all. I guess Knuth's advice about premature
optimization applies too interviews as well.

There's also a good Quora page that talks about the (complementary) coding
side of algorithm questions: [http://www.quora.com/What-is-needed-to-write-
flawless-code-d...](http://www.quora.com/What-is-needed-to-write-flawless-
code-during-interviews)

------
alain94040
... or you could just forget about O(n) questions in interviews. I know those
got really popular with Google, but as an R&D software developer, I probably
had to worry about complexity maybe about 0.1% of my time.

How clean is your code? Do you have good coding habits? Do you get lost inside
complex data structures? Do you understand concurrency issues?

~~~
Thrymr
"as an R&D software developer, I probably had to worry about complexity maybe
about 0.1% of my time."

Yes, but does it scale? If you deal with 10x, or 100x, or 1000x the data, that
% will grow. Fast.

------
ankimal
Sign up at topcoder.com (<https://www.topcoder.com/reg/>) and do a BFS
(Breadth First Search) of their Algorithm (Single Round Matches) SRMs
(<http://apps.topcoder.com/wiki/display/tc/Algorithm+Overview>).

Oh and if you want to brush up on your Algorithm Basics
([http://community.topcoder.com/tc?module=Static&d1=tutori...](http://community.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index)).

------
jchonphoenix
I'm seeing a lot of great discussion on this thread, but I'd like to point out
that you should NEVER rely on memorization to know the asymptotic bounds of
operations on data structures.

You should understand how that data structure works and then derive the
running time from that.

People seem to know hash sets use O(1) lookup, trees use O(log(n)), and so
forth. In reality, they have an in depth understanding of the underlying
implementation and are rederiving their answers on the spot with simple mental
calculations.

------
kamaal
You must hire people for two things to win big today's world. Productivity and
Analytical skills. If you are searching people with specific factual
knowledge, sure that is important but often that leads only to mediocre or
average results.

If you know how to do a thing before hand, that helps only in solving that
kind of problems specifically. And that too only if the person is productive
enough to do it in time. Any new problem or a change in paradigm of thought
will require you to undergo the same regime of work what it would be for a
newbie. They don't call learning a never ending process just like that.

The biggest winning point in today's world is not knowing something. But
discovering something quickly, and acting on it in time. If you are not hiring
people for this you will end with a lot of work force which looks good, but
doesn't necessarily translate to doing good.

This is the biggest problem with education systems around the world currently.
They impart facts and leave the person just there. Further its the individual
responsibility to take that forward.

The most brilliant folks who have done big around me have hardly been
algorithm experts. In fact if you are one, you are not likely to take big
risks. You are more than happy with the addiction towards that monthly salary.
And what helps you pay of those college loans.

The most successful around me are the ones, do a great thing. Think about the
next step. Research about it, work on it with full productivity. Deliver..
Next step and the process goes on.

If you hire people for factual knowledge you may hire the best, but you are
sure to miss out the exceptional. This is probably the reason, why big
companies fail to come with game changers.

You get folks who are great at the regular day to day operations. But anything
else, and you see the problems clear.

~~~
lutorm
"In fact if you are [an algorithm expert], you are not likely to take big
risks. You are more than happy with the addiction towards that monthly
salary."

Please elaborate on the evidence for a correlation between knowledge of
algorithms and risk taking?

Seriously....

~~~
kamaal
I have seen most people with degrees and especially brilliant ones hesitate to
take risks.

Probably that's because they feel after all the hardwork its better to have
some safer alternatives than risks which don't necessarily guarantee returns.

Now don't ask me to come up with survey/research paper. No one goes out and
spends time/money/energy to prove each debating point.

But I agree with you as well, there is no co relation between them. But
unfortunately truth is often stranger than fiction.

------
h3h
I don't agree with Aaron Swartz on very much, but we agree on hiring
practices:

<http://www.aaronsw.com/weblog/hiring>

------
alttag
I think the part that's missing from discussion here is: "First: Make sure you
understand the problem". Sure, for strictly algorithmic questions, where there
is one mathematically demonstrable optimal answer (or at least, a way to
compare solutions), this may seem less important, but for more open-ended
questions (e.g., "How many barbers are there in [$LOCATION]?"), clarifying the
_why_ is essential, because definitions are important and vary by context.
It's also important to seek whether a "good enough" solution is acceptable, or
if high optimization is important. (Related, what are the
memory/processing/load/runtime constraints, if any.) These are the sorts of
questions that, in my mind, demonstrates a candidate's willingness to reflect
on his/her own solutions.

------
gammarator
Abstracting away the specific content about algorithms, these suggestions are
helpful for any kind of technical oral exam, e.g. qualifying exams in grad
school. The more clearly you can communicate your thought process to your
interviewers, the more accurately they can assess your work.

------
Jun8
For an excellent discussion of the approaches outlined here and problem
solving heuristics in general check out Polya's _How To Solve It_ , it's a
classic (<http://en.wikipedia.org/wiki/How_to_Solve_It>)

~~~
gbeeson
Thanks for the link for the article - I appreciate it.

------
plant_meme
Sincere request to HN readers. If you have ethics, try to avoid working for
Palantir. Palantir is an unethical company. They were involved in the HBGary
scandal. They tried to smear Glenn Greenwald. They might have the best and
hardest interview process and may have the smartest people. But all these
technical wizardry is moot when they don't have ethics.

* [http://www.salon.com/news/opinion/glenn_greenwald/2011/02/15...](http://www.salon.com/news/opinion/glenn_greenwald/2011/02/15/palantir)

* [http://www.reuters.com/article/2011/02/17/idUS12186607112011...](http://www.reuters.com/article/2011/02/17/idUS121866071120110217)

------
MattGrommes
If you're struggling with algorithms I'd suggest reading the book Programming
Pearls (2nd edition). It's a little dated but not enough to matter too much.
The big thing it helps with is what I think of as "algorithmic thinking". The
various chapters go through different approaches to solving problems and help
you get a handle on why a particular approach might be O(n^2) versus O(logn)
and why that's important. It's very helpful stuff.

------
dsimms
"Error establishing a database connection". heh.

~~~
regs
Whoops - yeah, we're working on that problem right now - at the moment it's
back up.

~~~
ryan-c
It looks like it should stay up now - the traffic from this is much more than
we usually get, but it's doing fine now that the server has more resources
available to it.

~~~
jarek
You sure there couldn't have been an algorithm you could have optimized
instead of just throwing more resources at the problem? Your solution seems
awfully real world.

------
ernestipark
Real good advice. Totally agree with the brute force thing, I usually resort
to that first just to put something down. Related note, Palantir was at the
MIT Career Fair recently and when talking to prospective candidates, they
asked them a little brain teaser as a filter on the spot.

------
jtchang
Recognize the name because palantir sponsored one of the super happy dev
houses. Rather insightful talk was given. Seems like you guys do a lot of
number crunching which involve a lot of algorithms work.

------
pmf
Great article about this <http://ycombinator.com/munger.html>

------
nosequel
Step 1, send your resume and skills to wikileaks or other whistle blowing
operation Step 2, Palantir assists HBGary Federal in the hacking of wikileaks
and wikileaks supporters Step 3, Get hired when they read through your skills

------
zobzu
why those quizz interview sux is simple: anyone can look up the questions,
learn them in 2 weeks of time (going slowly) if they've any kind of basic
programming knowledge. so basically the questions are wasting the interviewed
person's time.

if the person fails that test, it means they just didnt care much about that
job. but i'm pretty sure any skilled interviewer can figure that out through a
much quicker process.

------
beachgeek
I had an interview back in 2009 where the CTO of the startup asked me a
question, I answered it, after which he very confidently corrected me with the
wrong answer(!)

Needless to say I didn't join them. The startup also went belly up about 6
months after I interviewed there. How do guys like this get funded?

------
phossal
This is a well-written article. You've acknowledged an interview process, and
you've provided very good advice for candidates who may encounter a similar
one.

Ideally, both hirer and hiree would obtain perfect insight during the
interview, and an alignment of skills, personalities and potential could be
determined and made obvious to both parties.

We cannot obtain such insight, and yet hiring decisions are still made every
day. Some work out, some don't.

As in most things, companies must optimize toward some strategy that produces
results consistent with their priorities. If each of your programmers must be
able to define - not just implement, but actually recall - breadth first,
depth first, big-o notation, and others, I suppose your strategy will have to
include such questions. What better way to determine whether your candidate
can memorize definitions than to ask them for them?

But some parts of the common technical interview exist simply because the
interviewers themselves aren't aware of any better strategy to obtain the
insight that really matters. Is your culture easy-going? Do you need a certain
kind of creative influence on your team? Is it really true that your
programmers need to program algorithms at all?

My point is really quite simple: to alleviate the feeling that we're passing
over good people, we should alter the interview process to give the candidate
ample opportunities to show us they're a good fit (and that we're a good fit
for them. For the record, I never accept offers from companies that ask me
lexical structure or algorithm questions, especially if those questions are
posed by peer-level interviewers - it suggests a non-performing competitive
rather than cooperative atmosphere). We should identify, if we can, the
priorities of our team, and then attempt to find a strategy that is optimized
for presenting the candidates we're seeking in a favorable light.

(I'm leaving this comment because you've written a post that is less about
improving the recall or application of algorithms, and more about helping a
candidate show you they're capable.)

