
Ask HN: How to not fail on coding interview questions? - evoneutron
I&#x27;m a mid-senior level software engineer with 5+ years of industry experience and making $100,000+. I don&#x27;t consider myself a bad software engineer, and yet I can&#x27;t seem to solve some basic problems on a white-board in 30-60min (i.e. traverse a heap, merge sorted arrays etc).<p>I joined my company as an intern ~5 years ago &amp; when I interviewed for the position I didn&#x27;t have to solve any white-board style interview questions etc., since it was an un-paid internship. After a few months I had demonstrated my ability to write code they made me an offer.<p>When I now casually look around and apply for mid-to-senior level positions I cannot seem to get past phone (coding interview) part, that involves solving some basic algorithm on collabedit. I get nervous and given I need to solve (perhaps a simple) problem in an optimal&#x2F;sub-optimal way in 30 minutes, my brain sort of shuts off and I cannot arrive at a clean solution, let alone solve the problem end-to-end.<p>I&#x27;m respected within the company, if you were to ask any colleague I have worked with whether I can write clean testable code that solves real business problems, everyone would attest that I absolutely can.<p>How do you create that environment of - &quot;Coding under pressure and someone looking at your code while you&#x27;re trying to think of how to solve a problem and your brain is thinking about everything other than a problem itself&quot;???<p>One idea is to just keep applying and failing until I become immune to it. But each failure kind of brings me down, and makes me think that I&#x27;m a bad engineer.<p>Last thing I want to mention is that I don&#x27;t blame the process itself. I think white-board style questions eliminate a lot of bad candidates.
I know that the process has to be rigorous because those jobs pay well. But there&#x27;s also extreme examples like the inventor of homebrew that got rejected by google because he couldn&#x27;t reverse a binary tree.
======
jaredklewis
I honestly feel you’ll get horrible advice from HN. Many here feel too
strongly about the process itself to give objective advice, as almost everyone
here has probably been screwed over for no good reason at least once.

What’s your goal? I assume, get a new, higher paying job. What’s the barrier?
Interview style coding problems, apparently.

So, things that will help you achieve your goal (IMHO):

\- Buying and reading cracking the coding interview

\- practice solving problems on sites like hacker rank and leet code

\- when you practice, try simulating interview conditions. Use pen and paper
or a whiteboard if your interviews will involve that

The more familiar and mundane the problems become, the less likely you are to
feel nervous with an audience. Just practice the problems until it is like
tying your shoes.

If asked to tie your shoe with someone watching, would you be so nervous as to
be unable? If so you may have some serious anxiety issue you might want to
work on before starting a job search.

Things that definitely won’t help you achieve your goal:

\- ruminating on life’s injustices

\- ruminating on your own shortcomings

\- comparing your self with others

\- ruminating on the decidedly capricious and error prone hiring practices of
Silicon Valley companies.

Life is not fair and there is a time and place to think about those things.
But doing so is counter productive to your goal, so I wouldn’t recommend it at
the moment.

~~~
OrwellianChild
Any chance we can up-vote this coherent response above the mud-slinging
rebellion against whiteboard interviews? This advice can actually help OP and
folks in similar situations.

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

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?

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

Just walk away.

~~~
inimino
> The big scam is "We hire the best and the brightest".

And adding noise to the hiring process increases the effect of "we are the
best".

If you flipped a coin, it would be more honest and less expensive than putting
people through a "difficult" whiteboard test. But you wouldn't get the "we
only hire geniuses" effect.

As these "difficult" tests are usually based on a corner of the CS field that
the interviewer enjoys, it is essentially random, while appearing to be
totally meritocratic.

You end up with a process that filters out 90% of qualified candidates, but
nobody that was hired by that process wants to change it.

~~~
rramdin
"Automatically reject 10% of applicants. We don't hire unlucky people."

------
joshuakcockrell
> But each failure kind of brings me down, and makes me think that I'm a bad
> engineer

First off, you are not a bad engineer for failing a technical interview. Over
the past 3 years, I've applied for hundreds of roles across dozens of
companies. I've been through dozens of interviews and I've got offers from (or
worked at) Uber, Twitter, Microsoft, Tesla, etc. The side of the story I don't
focus on is that I've had over 200+ rejections. Some after first rounds, some
just after they look at my resume. Rejection is part of the game but you just
need to push through it. Here's my advice.

\- As other comments have said, it's definitely a numbers game. Some days you
just don't mesh with your interviewer, others you know the answer to their
coding question before they've even finished asking it. Just apply over and
over if you want the best odds. You can't get too emotionally attached to any
single interview opportunity. I've had to apply for ~50 roles for each offer I
get. That's just the way it works.

\- Practice a ton. It sounds like you are more worried about coding under
pressure and thinking through the answer while you are in the middle of trying
to explain your thought process to the person interviewing you. I recommend
pramp.com You interview someone for 30 minutes over the webcam and then they
interview you for 30 minutes. It's super convenient and gets you very
comfortable thinking through problems on spot with someone else watching you.
I normally do ~10 pramp.com interviews while I'm preparing for an upcoming
interview. In person interviews with friends is good too but less convenient
than just signing up online for a time slot.

Just remember that bad interviews don't make you a bad engineer. At the end of
the day, no one will remember dozens of rejections, but they will remember the
job you eventually land. Keep interviewing till you get an offer that you're
excited about. Good luck!

~~~
ddebernardy
I commend what you did and where you're coming from but going through 200+
rejections is just soul wrenching, and it's probably not what the OP wants to
hear. Something is very wrong in this industry if its hiring practices are so
that someone competent needs to go through that many interviews (and
rejections) before finding work.

~~~
tannhauser23
Honestly once you get into the groove the rejections really don't matter
anymore. I've been rejected from companies that I forgot I even interviewed
with - just gotta push forward and play the numbers game.

That said, getting rejected from a company that you had your sights on... that
does suck, at first. But usually you can apply again in a year.

------
koala_man
>there's also extreme examples like the inventor of homebrew that got rejected
by google because he couldn't reverse a binary tree.

HN has rehashed this debate plenty, but I don't think you should necessarily
see this as an example of a dramatic failure of the Google SWE interview
process.

Homebrew became a success due to great vision and execution, not because it
solved a challenging technical problem. Howell seems like a great guy who
would probably make a great senior developer, founder or PM at any company
that aims to solve customer needs.

Google's focus, however, is on hiring SWEs that can solve uniquely complex and
difficult technical problems. The merits of such a narrow focus is obviously
up for debate, but if that is to be your goal, this hiring decision aligns
with it.

~~~
anigbrowl
_Google 's focus, however, is on hiring SWEs that can solve uniquely complex
and difficult technical problems._

I think that's kinda just marketing TBH. How else do you explain things like
their habit of overhauling the graphics while removing functionality on many
of their popular offerings? The last update of Google News looked a lot nicer
but removed all user customization of the news feed - you can't even filter
out sources any more.

I mean, maybe there are a lot of super-clever SWEs at google who are bored and
frustrated with everyday consumer-centric product development and so do a
terrible job at it until they're rotated onto something more interesting. I
can't think of any other reason to inflict such a product on the public.

~~~
koala_man
>How else do you explain things like their habit of overhauling the graphics
while removing functionality on many of their popular offerings?

I can't speak to any specific instances, but generally when this happens it's
because the front-end needed replacing, and not because they had to give up on
supporting the functionality on the backend.

For example, the front-end may have been mobile or offline hostile, while the
new one works great with both but only reimplemented 80% of the massive
feature set that the old UI accumulated.

It sucks if you primarily used the site on desktop and heavily leveraged the
missing 20%, but I can see the value in such a trade-off.

------
smnscu
I really enjoyed practicing on Pramp [1]. I ran through their whole batch of
problems (roughly 40) so I can't schedule more interviews, but it helped me a
lot to work on the soft skills required for FAMG type interviews.
Unfortunately I still didn't pass the Google interview (had on-sites in
Zurich) even though I was very well prepared. I also maintain (sort of lol) a
list of interview preparation resources [2], although I find [3] to be even
better.

PS: I also failed much easier interviews at CrowdStrike and SourceGraph so
maybe I just suck at being interviewed in a way that's not clear to me. It
really takes a toll on your confidence though.

1 - [https://www.pramp.com/](https://www.pramp.com/)

2 -
[https://github.com/andreis/interview](https://github.com/andreis/interview)

3 - [https://github.com/jwasham/coding-interview-
university](https://github.com/jwasham/coding-interview-university)

~~~
smnscu
At least 2 downvotes on this comment. I'm done with this site.

~~~
jensv
Hey I appreciated your comment, have an upvote.

Try not to take things personally, it could have just been a bot.
[https://news.ycombinator.com/item?id=17334552](https://news.ycombinator.com/item?id=17334552)

------
togusa2017
Before this discussion starts between how the interview process sucks. Here is
my 2 cents:

1\. Pick up leetcode (or whatever rocks ur boat).

2\. Do a lot easy questions and understand the pattern.

3\. Do medium level questions and understand the pattern.

4 If you are aiming for Big 4 do Hard.

Coding interviews is all about finding the pattern and applying it. Only way
to be good at it is practice. Don't give interviews without some practice.

~~~
zerr
Anyone has any top list in terms of most interesting/creative/fun? Because, I
find most of these tasks quite boring - even if the solution is not clear from
the start, it just feels too contrived and you know that it's aimed at some
particular algorithm and the data structure.

~~~
torbjorn
I am really enjoying working through the book "Elements of Programming
Interviews"

------
stuxnet79
It's all supply and demand. The expectations from employers as to what a
'qualified' engineer is likely to demonstrate within a 30 min to 1 hour
timespan has increased. To get access to the plum jobs you have to be able to
pass the gauntlet of interviews and this is something that's not particularly
easy if you don't know the 'game'. First thing to realize is that you don't
have to be a genius to pass these interviews, however it does require
consistent practice and you will have to be dedicated enough to rearrange your
life such that you are able to get in some practice on a regular schedule. Of
course how feasible this is depends on your life situation. It is easier for
younger engineers to dedicate their evenings and weekends to grinding Leetcode
than older candidates.

My unsolicited advice is to:

A. Come to terms with the fact that there has been a shift in expectations
from employers. Understand that to get the really plum jobs it will require a
lot of dedication to get to where you need to be interview performance wise.

B. If you are really rusty, start off with Firecode.io. It provides a more
structured approach to studying these interview questions. Once you feel
comfortable with the questions there then you can go for Leetcode.

C. Go to interviewing.io and pramp and practice with actual engineers. This
will allow you to work on your communication skills. A big part of interviews
is just basic communication. You could be rock solid with your algorithms but
if you still can't communicate what you are thinking to interviewers in an
effective manner you still won't pass the screen.

D. It's not a particularly popular corner of the internet but
reddit.com/r/cscareerquestions has a lot of good advice on how you can improve
your interview skills. It's also a good place to get a sense of how interviews
are structured, how people typically prepare, expectations etc. It's skewed
towards getting jobs at the FAANG type of companies but the good advice you
will get in the sub is pretty solid and will help regardless of the direction
you want to go.

Overall, try not to be too hard on yourself. Technical interviews are an
inherently noisy screening tool, and a lot of great engineers fall through the
cracks. Preparing for these interviews just like you would prepare for any
other important assessment will help you in being more competitive.

~~~
dabockster
> reddit.com/r/cscareerquestions

> good advice

That place is literally college confidential for CS students. It really
doesn't help anyone when the people who are giving job advice haven't even
left school yet.

------
neverminder
Apply to companies that don't do whiteboarding/phoneboarding. I don't know,
maybe this is a US thing, or the Big Four thing, but down here in London I am
yet to encounter a company that does whiteboarding.

[https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards)

~~~
dabockster
If you live near enough to a tech hub, you have to assume you're going to be
code screened and whiteboarded. Companies around here (Seattle) use it as a
cost cutting measure so they don't have to spend time and money manually
interviewing every single candidate. It's significantly cheaper to enforce a
competition-style coding challenge and pick off the top 5-10% performers
(example figure) of the challenge for the actual interview.

~~~
ahoka
London is a "tech hub".

------
mratzloff
I'm one of the most low-key, relaxed people you might meet, which makes my
test anxiety worse: since I've learned strategies to mask my anxiety around
whiteboard coding, I just look incompetent when my mind goes blank and I can't
think clearly.

Contrast this to my daily work, which is often highly technical and high
pressure in a wide variety of areas.

The tech interview is broken. The problem is that there aren't many good ideas
to replace it. Every large company is focused on eliminating personal bias,
easing the process of training new interviewers, and improving repeatability.
Pass/fail-type challenges (or perhaps a simple grading system) are the easiest
way to achieve those things.

Additionally, companies like Google and Facebook can absorb large numbers of
junior candidates directly from schools. Most of these exams are geared toward
those fresh from an academic setting.

Small companies adopt these techniques because they also want "the best"
without actually considering their real needs. As a result, a cargo cult has
arisen around making the technical interview increasingly long and baroque.

Here is some practical advice:

1\. Talk to your doctor about your situation and tell them you've heard beta
blockers[0] help stop the flight-or-fight response.

2\. As others have said, practice over the course of months. Do the same
problems again and again. If you can't solve these toy problems without
pressure, you definitely won't solve them with pressure.

3\. Ask the company ahead of time for a take-home as an alternative. Explain
the situation.

Ultimately this situation won't change until engineers in decision-making
positions force it to change. Interviewers also need to be trained on how to
recognize test anxiety and what strategies they can employ to ease that.

[0]
[https://en.wikipedia.org/wiki/Beta_blocker](https://en.wikipedia.org/wiki/Beta_blocker)

------
KirinDave
Hi. I also feel this way when I'm interviewing, so please know that you're not
alone. Interview Anxiety afflicts a lot of us and it makes us perform much
worse in interviews. The way that interviews are structured tend to hurt
people as well, often deliberately trying to create a sense of inferiority in
applicants to help close deals and negotiate rates. It's an act, usually an
intentional one!

One of the most effective ways I've found to deal with this is be open. Say,
"Yeah, I suffer a bit from anxiety and interviews in particular are difficult.
Do you have a take home interview? I can easily commit to git in near real
time if you want a blockchain-quality log of my process, and I'm happy to
review it with an engineer." I have gotten a surprising number of takes on
this (and in general I annihilate these).

As a bolster to your confidence, try not to take these too seriously as an
indicator of your personal skill. Having worked a bit on my current and past
employer's interview process, tbh an awful lot of orgs have questions that are
more like riddles than actual coding exercises; they often have a simple
solution you have to "know" otherwise the problem is excruciating and every
solution is obviously bad. Examples of this include "chocolate bar" division
problems, skyline problems, or rainfall problems. All of them are bad
examples.

We also enjoy a sellers market for many tech skills right now. In such a
market, interviews can also be information for you to save your time not
proceeding. This feels very strange for people normalized to the creepy feudal
culture of tech where you align yourself with a company body and soul and only
state laws allows you to escape their clutches, but it's pretty powerful. If
an interview seems deliberately excruciating, just say, "I've seen all I need
to see. Thanks for your time, but I don't think you're a good fit for what I'm
looking for in an employer."

Finally, it's also worth remembering that just modest reading in PL, CS and
database literature written in the last 10 years often gives you ammunition to
completely break down these questions. The folks that structure and ask these
only seldom actually their theoretical basis. I've managed to break out of
ugly and tedious interview questions by flipping the conversation to something
I _do_ know well and am confident speaking to, like modern O(n) sorts
(discrimination, american flag), wavelet trees, recursion schemes, CRDTs and
strategies for gossip protocols. Appeal to their greed and interest and show
them that you DO know things, you just may not know THIS thing RIGHT NOW.

------
hal9000xp
Here are my advices on how to train yourself for algorithm/data structures
interviews:

1\. Others already recommended to practice solving problems on LeetCode;

2\. While solving these problems don't spend too much time if you got stuck,
look for answer or discussion after hour or two;

3\. If you feel weak on some topic (e.g. dynamic programming), try to read up
related material, lecture notes, familiarize yourself with classical problems
on this topic;

4\. Even if you solved problem, look for other answers. You often be surprised
how much shorter and concise solution can be;

5\. Read some books on algorithms like Skiena or Papadimitriou. I don't
recommend you to read Knuth or CLRS unless you have strong math background.
Skiena or Papadimitriou are much easier to read for beginner. Also,
separately, I do recommend the book - Programming Pearls by Bentley;

6\. Once you practised for two months or more, start taking mock interviews on
Gainlo;

7\. Enjoy algorithms and solving programming puzzles. Enjoying algorithms is a
must because if you really want to master it to the Google interview level, it
may take years;

------
atak1
Coding interviews is a performance-based art, so treat it as such. The best
way to prepare for an on-stage performance? 1 Memorize your lines until you
can't forget, 2 practice with fellow actors, and then 3 practice with real
interviews. 1+2 is practice. For step 3, concentrate on improv & how to
compensate for when you're not at your best (aka you didn't get great sleep so
you forgot a line - what do you do?)

Same for coding interviews. Practice, then interview. 5-10 years down the
line, every time you're looking to switch jobs, it gets easier, and you get
the insights from the past experiences.

NB

The phone screen isn't easier than on-site; it can often be harder, and often
is the same level of difficulty, with more pressure.

NB 2

If you're mid-level they'll ask a few systems design questions. Make sure for
the systems you've built, you know at a high level how each individual
component was built and what abstraction it stands for.

Good luck! And ping me at my tw email (check profile) if you want to follow up

------
tzs
Several people have mentioned practicing on LeetCode problems. I've been doing
LeetCode problems recently as exercises to refresh skills in languages I use
infrequently but don't want to forget too much of.

Here's a tip that they either don't tell you, or that I managed to overlook.
You are allowed to mutate inputs.

I had assumed that inputs were read-only, and spent about three months trying
to solve "Given an array of N integers, find the smallest positive integer
that is not in the array, in O(N) time and O(1) space". (It wasn't three
months of constantly working on it...it was more for three months it was one
of my "something to think about while falling asleep in bed or while sitting
at a red light" problems).

I then came across a site that talked about the problem and mentioned doing it
in O(1) space involved overwriting the input. It was only a couple minutes to
solve after that.

Possibly interesting variant of that problem: Can you still solve it in O(N)
time and O(1) space if when your code returns the answer the input must be
unchanged? You can still mutate the input while your code is running, but you
have to undo any changes you make before returning.

I'm pretty sure that the answer to this is "no" in the general case, but if
you are allowed to limit the size of the input so that N is not a significant
fraction of MAXINT on your machine you can do it.

~~~
JoachimSchipper
> Can you still solve it in O(N) time and O(1) space if when your code returns
> the answer the input must be unchanged?

I don't think that is possible in general. In _some_ cases, such as your
"small integers only" case, the program can get extra working memory by
essentially compressing the input, doing some work in the freed-up memory, and
uncompressing; but if the input memory is already used optimally, there should
proveably be no way to store the input plus additional data in those bits.

(Obviously, you can e.g. store one bit of the input in the program counter by
splitting the entire program on an initial "if (first_bit) ..."; but that's
just moving information around without gaining additional storage.)

FWIW, mutating the input array is a neat trick, but I wouldn't be inclined to
accept such a solution, either.

~~~
tzs
(Note: this comment contains spoilers for the original problem and for my
proposed variation)

(Note: I'm going to use Python3-based pseudo code, except I'm going to assume
1-based array numbers, so the input is in a[1], a[2], a[3], ..., a[N].)

Suppose the input input list has N integers. Then the smallest positive
integer not in the list must be one of 1, 2, 3, ..., N+1. (Prove by noting
that all positive integers less than the smallest missing positive integer
must be in the list, and then apply the pigeonhole principle).

In the classic problem, where you can use the input list as scratch memory and
do not have to restore it, there are two approaches I've seen.

1\. The sorting/permuting approach. With this approach you go through the
list, and for a[k] you do

    
    
      while 1 <= a[k] <= N and a[a[k]] != a[k]:
        a[k], a[a[k]] = a[a[k]], a[k]
    

The result is that if a 1 is in the list, a[1] ends up with 1. If 2 is in the
list, a[2] ends up with 2, and so on. Then you can scan the list looking for
the first k such that a[k] != k, and k is the smallest missing positive. If
a[k] == k for all k, then k+1 is the fist missing positive.

If one takes this approach, I don't see much hope in restoring the input back
to its original state after identifying the missing integer.

2\. The flagging approach. Conceptually you have an array, b, of N Boolean
values, initialized to all False, and do this:

    
    
      for k in range(1,N+1):
        if 1 <= a[k] <= N:
          b[k] = True
    

Then you scan b looking for the first a[k] that is False. k is the missing
integer. If all of is True, N+1 is the missing integer.

Note that if all of the input integers were known to be positive, we could use
the sign bits of a[] as out b[].

    
    
      for k in range(1,N+1):
        if 1 <= abs(a[k]) <= N:
          a[a[k]] = -abs(a[a[k]])
    

(The abs is there on the assignment to deal with duplicate values in the
input).

Then we can scan a[] looking for the first positive a[k], and k is the missing
integer, or N+1 if all a[k] < 0.

In this special case, where we know all of the input is positive, we can
restore the input back to its original value after finding the missing by
simply setting a[k] = abs(a[k]) for each k.

The flagging using sign bit approach also works if not all the input is
positive. Just add this at the start:

    
    
      for k in range(1,N+1):
        if a[k] <= 0:
          a[k] = N+2
    

(If N+2 ≥ the maximum positive integer your language allows, then you are
going to have to do some special cases that I'm not going to go into).

But now we cannot reverse this after we find the number. If we had a way to
get rid of the non-positive entries that we could later reverse, we'd be good.
One approach would be to find the most negative value, m, in the list, and
then add abs(m) + 1 to everything. Then we could do the prior positive-only
sign flagging approach, remembering that when we want the value at position k
it is a[k] - m - 1, not a[k]. At the end, we then just subtract m + 1 from
a[].

This works as long as M + m + 1, where M is the most positive value in the
list, is not greater than the maximum positive integer.

Here's some working Python3 code for this (so arrays are back to 0-based, and
so there are "\- 1"s here and there):

    
    
      def firstMissingPositive(a):
          s = min(a)
          if s > 1:
              return 1
          s = abs(s) + 1
          for i in range(len(a)):
              a[i] += s
          for i in range(len(a)):
              v = abs(a[i]) - s
              if 1 <= v <= len(a):
                  a[v-1] = -abs(a[v-1])
          missing = len(a) + 1
          for i in range(len(a)):
              if a[i] > 0:
                  missing = i+1
                  break
          for i in range(len(a)):
              a[i] = abs(a[i]) - s
          return missing
    

For Python3, which automatically does big integers, so M + n + 1 will not
overflow, this should always solve my proposed restoring variant of the
problem.

For systems where that can overflow, we need another approach. I've had some
ideas, but they all would also run into overflow problems, so I'm currently
stumped.

I think this subproblem is interesting enough on its own to state as a
separate problem:

Write a function that given a list S of integers, returns an invertible
integer function f and its inverse f', such that for all k in S, f(k) exists,
is > 0, and INT_MIN <= -f(k) <= f(k) <= INT_MAX where INT_MIN and INT_MAX are
the smallest and largest integers, respectively, your language handles. This
should run in O(N) or better time and O(1) space.

Then to solve the restoring variant of missing integer, find f for your input,
apply f to the input, and then do the positive-only flagging version of
missing integer (using f' to get to the original values of a[]). Use f' to
restore the input at the end.

This can be further generalized, because flagging by sign is not the only way
to flag. For instance, if we happened to know that all of the input was even,
we could use a[k] |= 1 to flag it, and we could clear the flag at the end with
a[k] &= ~1. If not all of the input is even, we could start with a pass of
a[k] *= 2 and undo it at the end with a[k] //= 2.

That gives us this problem to contemplate. Write a function that given a list
S of integers, returns using O(N) time and O(1) space an invertible integer
function f and its inverse f', invertible integer function m and its inverse
m', and integer function t, such that.

1\. For all k in S, f(k) exists

2\. For all f(k), m(f(k)) exists

3\. t(f(k)) = 0, t(m(f(k)) = 1

f, f', m, m', and t should all be O(1) time and O(1) space.

~~~
JoachimSchipper
I was indeed thinking of (1), albeit just using radix sort - your permutation
trick is nicer.

But (2) doesn't work in general, because information theory may not allow
storing more information in the input array than is already there; I'm
convinced myself, but I haven't come up with a better argument than "obvious"
in the time I had available. ;-)

------
mlthoughts2018
Just be fine with failing a bunch until you find a company not using such
obviously bad interview techniques.

Don’t waste time on leetcode / HackerRank / etc. It’s not useful. Practice
programming by writing code you enjoy, solving problems you are interested in.
You’ll be naturally productive at what you enjoy, and just build on that.

Anybody giving advice that comes from the point of view that these interview
techniques have any legitimacy is probably just someone who happens to
randomly be good at or enjoys interview trivia, and so their opinion is
clouded by a selection bias effect. This is especially true on Hacker News.

They do well on interviews, not because their study methods work better and
not because they are better at engineering or more effective in a job. They
are not. They just benefit randomly from a system set up to reward traits they
happen to have already and find easy. Their ideas worked _for them_ but are
very unlikely to work for you.

Seriously, just do a lot of interviews, fail a lot, and be fine with it. It’s
easier said than done, but it’s necessary for you to weed out the places with
foolish interview practices and find the ones which are more holistic, human
productivity focused, flexible, etc.

I happen to be good at quickly working through algorithms, mostly in machine
learning and search data structures, but in general software too.

If anyone tries to hire me _because_ of that quick “see how you think”
whiteboard nonsense, I just walk away. They are doing it wrong; life’s too
short.

------
annon6182018
Posting as annon for obvious reasons.

I was in exactly the same situation you describe about 4 months ago. 5+ year
work experience, making 100k+ and joined my company after an internship.
Additionally, as an electrical engineer by training, I had little formal
training in algorithms and data structures.

Here are some things that worked for me:

1\. Interviewcake.com - worth every cent I paid for the annual subscription.
It is an excellent resource - even better than the book “cracking the coding
interview” in my experience.

2\. Donald Knuth’s Art of Computer Programming - as a person without a formal
training in algorithms and data structures, the classic text by Cormen et al
was pretty poor. Knuth’s AOCP had much better treatment for multiple topics
and really helped me understand what’s going on. (See the treatment on hash
tables in both works for an example on the difference in quality)

3\. Whiteboarding tips - (here is where my recent interviewers might be able
to identify me) - You have to remember how whiteboards are more versatile than
text editors. Use the whiteboard to draw things, make notes for yourself,
analyze the question. I followed a process of writing and underlining these
headings:

i. Problem : Reverse alphabets in a word stored as a linked list ii. Test
cases: h-e-l-l-o iii. Algorithm: <write down pseudo code> iv. Final code

This might seem like a lot more work at first, but an organized approach like
this really helped me complete complex challenges within 45 mins. Give this a
try. It really helps

4\. Resume polishing - Some former colleagues were very helpful in reviewing
my resume and providing feedback. I saw a dramatic increase in the number of
calls I received after revamping my resume.

5\. Practice white boarding - Book a conference room for a weekend and
practice solving 10 to 15 hard problems with a timer in the conference room.
It makes an incredibly huge difference.

I am happy to say that with these, I went from being completely unprepared for
interviews to multiple fantastic job offers in the past 4 months.

------
soreally
I've gone through about 6 coding interviews in my life and I failed one. I've
given hundreds of interviews, many at some of the biggest companies.

Here's the thing. There aren't that many different kinds of problems that
you'll be asked to solve. The recipe for 80%+ of the interview problems I ever
see is this:

1\. You have a data structure (tree/array/matrix/graph/string) that may have
some special properties (sorted? directed? etc?)

2\. You solve one of a few classes of problems: * Find an optimal <blah>
(shortest path, highest value node, longest subsequence, etc) * Mutate the
output in some interesting way based on the values

3\. You do that using some other data structure (Queue, Stack, Hash, Heap) or
technique (dynamic programming, recursion, etc) for efficiency.

There's probably also a brute force solution you should be able to implement
and that shouldn't take too long to do.

My point is, these interviews should be easy for a good candidate because the
fundamental problem space for a typical question isn't huge and there's tons
of places to practice online. For most interview problems, you should be able
to say "Oh! I recognize the general shape, I can apply a few primitive
patterns together and get a solution that's basically correct, and maybe I'll
have to tweak it a bit to optimize it later".

Instead, I tend to get candidates with 15 years of experience who think
they're so hot but somehow can't implement a trivial depth-first search. I
don't want to spend the whole interview on trivial coding problems. I want you
to finish that part in 15 minutes so we can spend the rest of the time on
interesting topics and technologies.

------
nunez
Right, so most of the problems in coding interviews that I've done are closer
to CS111 trivia or ACM contest prep than an interview of your real-world
abilities. Therefore, the best way to practice for that problem set is to
practice doing problems like that problem set. There are plenty of resources
online to help prepare for that.

That said, a surprising number of problems in life tend to reduce or closely
resemble a fundamental data structure or computer science problem. (A lot of
problems tend to approximate to graphs.) Additionally, even though most
languages have support for fundamental data structures or algorithms in their
standard libraries, knowing the performance implication of a double-for loop
or understanding when to use a binary search tree compared to a B-Tree or RB
Tree can make huge performance differences that real users care about.

This is where the value of the coding trivia interview sort-of comes in. It is
the clearest indicator of ones skills in CS primitives you can have, and it
does a good job in setting a quality bar within an engineering organization
(at least everyone knows how to do these).

I personally think that more comprehensive and system-level interview
questions are more valuable in assessing the technical abilities of a
candidate in toto. In asking something like "How would you design an app like
Instagram," you get a clearer sense of how the candidate thinks, how they
approach problems, how much of their CS fundamentals they've retained, and, to
some degree, what they're like to work with. It also allows more flexibility
than the trivia-style interview. If you want to assess coding ability, you can
ask them to write their idea of a feed algorithm. Conversely, if you want to
assess their abilities as a lead, you can ask them about maintaining the
system and finding the right team to build an app like this.

------
stevenwoo
Even before stackoverflow was available, my ability to solve a problem on the
spot was probably not that great so my success in passing technical interviews
seems like a lot of luck in hindsight - in my actual work I had to solve
similar issues in successful technical interviews, and this is over four
different industries/positions. This is versus unsuccessful ones where I
haven't looked at the thing in question in years or _ever_ so I am pretty much
going in cold on the question. I've seen some people talking about going
through every question on leetcode or hackerrank and being able to recall a
solution instantly to prep for a Google style interview so you have to ask
yourself if you think it's worth that kind of effort. Don't take your lack of
success now as a very good measure of your ability, it sounds like your
company might not hire you if you applied to it even though you are really
good at your job.

------
kenshi
\- Practice a lot.

\- For that authentic whiteboard performance feeling ask a friend to play the
role of an interviewer.

\- Maybe set up a local meet up to help people practice this interview skill

~~~
ryandrake
+1 for practice. Gone are the days when you could go into a tech interview and
count on your skills and smarts carrying you to the finish line. They’re just
too high pressure and picky nowadays, and you’re competing with too many good
candidates. You need rote practice: mock interviews with good mock
interviewers, and book study. I’d shoot for at least 10:1 prep:interview
ratio, so for a 4 hour interview, prep at least 40 hours.

~~~
gaius
_They’re just too high pressure and picky nowadays, and you’re competing with
too many good candidates_

Indeed. Many people (including myself) find it hard to reconcile our lived
experiences with the hysterical claims in the press about a desperate skills
shortage.

To the OP: if it helps, understand that these kinds of interviews and how you
do on them are in no way reflective of your skills as an engineer or your
worth as a human being. You’re just being hazed, by someone you probably
wouldn’t want to work with anyway. Keep at it, and eventually you will get to
speak to someone who is basically normal that you can have a real conversation
with.

~~~
borplk
The shortage is a myth and corporate propaganda.

They have collectively adopted a strategy of constant moaning because they
always want more and better candidates for lower prices.

------
partycoder
You have entered the world of "competitive programming". Companies have
started to incorporate competitive programming problems into their interview
processes. They're hard, and often don't overlap a lot with what you may do at
work, but there's not much you can do about it other than to prepare.

A good book is "Competitive programmer's handbook", available for free in
[https://cses.fi/book.html](https://cses.fi/book.html). This book is
programmer to programmer advice that will take you very very far into these
kinds of problems, and gets to the point really fast. The code examples are
clean and well formatted. For interviews, it gives you about 70% of the
competence you would get from reading much longer books like Skiena's or
Sedgewick's.

My approach to these interviews is:

\- Read the requirements very well. Try to read between the lines as much as
you can.

\- Ask if there are follow up questions or if the exercise has multiple parts.
This helps you plan your time.

\- If you do not have an ideal approach, try a bruteforce approach first.

\- Try to narrow down candidate solutions: what happens if I use an array? a
list? a tree (binary search, trie, heap, etc)? a stack? a queue? a graph? a
combination of them?

You can practice on sites like Leetcode, Hackerearth and so on so forth. If
you want to try something harder, you've got this (not for the faint of
heart):
[https://techdevguide.withgoogle.com/](https://techdevguide.withgoogle.com/)

But first, try to implement common data structures from scratch and get a
better intuition about them. Remember to try recursive and iterative versions
of operations. You can output Graphviz data and use that to debug.

Finally, even if you fail an interview, many companies will let you reapply
after some period of time. I failed an interview a few years ago and I still
get contacted by that same company today. It's not a life sentence.

------
lsaac
In the same boat as you here.

As everyone here says, you have to practice.

Then, when you're finally fairly good at coding challenge questions, you'll
discover that you also have to be good at system design questions which is a
different beast altogether. And then you'll learn that instead/addition to the
above, company X actually wants you to complete a take-home exercise, and
company Y won't consider you because they do Python while you have Java.

It becomes very hard to know what to focus on when you don't have your eyes
set on a particular company.

~~~
digianarchist
I had two take homes this week.

The first suggested not to spend longer than two hours and had very precise
requirements. I passed this.

Second had four questions - first two were clear and the last two were vague
hinting that I should spend 5+ hours implementing a authorization system in
rails. They got high level answers for those two. We’ll wait and see.

------
gregorygoc
If you don't have problems with sharpness of your mind, you might want focus
on stress handling. I'd start with the attitude. Why stress out when you have
a 6 figure salary?

------
im_down_w_otp
The problem is, while possible that "white-board style questions eliminate a
lot of bad candidates", it's a terrible and empirically unsubstantiated
methodology of assessment given the purported goals most companies claim to
have in hiring people.

In the event that it works at all, it does so by accident, not by design.
Which is often evident in how hit-or-miss hiring someone is in most companies
even after they've managed to make it through all these silly contrived
crucibles.

To a certain extent it's a cargo culting problem. Insofar as companies like
Google do it, and Google appears successful, and so other companies (failing
to do any meaningful analysis or meta-analysis of their own) decide to model
Google on the basis that surely their company will be successful just like
Google. The problem, taking Google as the example, is that Google has AdWords.
Which is for all intents and purposes a money printing machine. Google can be
basically terrible at almost everything they do and still appear wildly
successful so long as they don't disturb their money printer. As a result it's
very difficult to just pattern-match to what Google does and evaluate either
its benefit or its appropriateness in any context.

The other part of it is inertial. Often the wheel of hiring in a company
started this way for lack of any better ideas, and then as the company grew it
became proportionally more biased toward people who made it through a process
like that, and then it becomes generationally perpetuated. The unfortunate
side-effect of this is that biasing the employee population this way makes the
job, for a new executive or manager, of changing these ineffective (and
sometimes toxic) strategies extra difficult while trying to maintain team
cohesion. Because it has a lasting cultural fingerprint.

Honestly, it's really a shame. I'm sorry you're having to go through it. My
capacity to try to interact and change this weird marketplace phenomenon
extends only about as far as the company for which I'm the Engineering hiring
manager. My hope for you, and for others, is that you either find a place to
work which doesn't do things this way, and/or you otherwise advance far enough
in your career that nobody bothers to foist these silly ceremonies on you.
Because your involvement in their pursuits is seen as a priori beneficial or
existential.

------
thisisit
I can understand your situation because I was in your shoes once. I joined a
place as an intern and stayed there for 6 years. Once I tried getting another
offer, I realized I was a bad SWE by other company's standard. And I failed
interviews after interviews. Around 25 interviews but finally nailed one which
led me to path which turned my life around.

So, how did I get the last interview? Once I realized that I wasn't doing
great, I started writing down all the interviews questions. The aim was to
understand what was I doing wrong. But in doing so, I started to see a
pattern, most interviews tend to follow a singular script. For example
transverse a heat map, merge sorted array etc. And I trained on all those
questions. Now this wasn't a perfect solution because I still failed 10+
interviews but over time I got better. And then around the 25th one I finally
nailed one as all the questions were repeated.

Nowadays there might be a better options to do this like books/sites which
throw tons of whiteboard interviews at you. So try those and best of luck.

------
pault
Does anybody know what the interviews at the FANGs are like for non-SWE roles?
What are the interview questions for a front end developer? Do they still make
you reverse binary trees?

~~~
meiraleal
Frontend Developers at Google (and probably the other letters in FAANG) are
SWEs.

------
cornellwright
A lot of people recommended practicing coding problems. Along with this, I
would add practice talking to people you don't know.

Go to networking events and meet-ups. Offer to give mock interviews to people
more junior than you. Have coffee with founders to give them feedback on their
ideas. Anything that puts you in unstructured conversation with strangers will
make you more comfortable and confident in an interview. You get better at
reading people and start to see things from both sides.

Being a software engineer often mainly only requires communicating with a
mostly unchanging group of people. Interviewing well requires being able to
communicate efficiently with someone you just met. During an interview if you
can direct less time and mental energy at just communicating you'll have more
for demonstrating that you'll be able to do the job.

------
ashwinaj
This was told to me by someone who recently got into Google:

"It is irrelevant whether you can come up a solution all by yourself. Being
able to understand and remember the optimal solutions for those questions is
the key. All the interviewer is looking for is whether you can write those
optimal solutions literally on the whiteboard."

We can debate (and people have here) about whether it makes sense and the
like, but this is the reality. Make this process as mechanical as possible,
everyone knows it's a stupid game and yet we all play along.

[https://translate.google.com/translate?hl=en&sl=zh-
CN&u=http...](https://translate.google.com/translate?hl=en&sl=zh-
CN&u=http://www.cnblogs.com/grandyang/p/4606334.html&prev=search)

------
Cofike
I would say the biggest thing you can do is practice on Leetcode. You need to
be see the different patterns that are used to solve certain classes of
problems (tree problems, dynamic programming, array focused problems). There
are common data structures that pop up in almost all of the questions
(hashmap, linked lists, tree, bst, etc). It's just a matter of exposure but
focus on the underlying pattern/technique used to solve the problem and
understand how and why it's being used as opposed to rote memorization.

The alternative is finding companies that do not ask these types of interview
questions. The only big company I know that doesn't ask those types of
questions is Stripe but I'm sure there are plenty of others though they may
not be 100% what you are looking for.

------
eksemplar
I haven’t programmed much since I stepped into management 15 years ago, and
while I’m not sure I could do still do Dijkstra I can still do all those silly
text-book examples on a whiteboard if you gave me the business logic. From
x-sort to linked lists and trees.

If they don’t give you the business logic, then you’ll need to practice,
practice, practice, but you honestly should be able of reasoning you through a
piece of businesslogic and turning it into pseudo code.

Aside from that, it’s a terrible test for hiring people exactly because you,
can, memorize it through practice. But American hiring processes are funny
like that.

------
koala_man
What's the pain point? The stress of being observed? Getting started? The
difficulty of the problems themselves?

How long would it take you to merge two sorted arrays on a computer without
internet access and no one looking?

~~~
evoneutron
It would probably take me less time due to not having the pressure of someone
looking, but it might still take me ~ 30min.

I think the general problem is that I don't deal with such low-level problems
on a daily basis.

I can write multi-threaded Kafka consumer app that processes thousands events
per second and applies some basic ETL on them, add end-to-end integration test
for it in <8 hours.

But it may take me ~1/8th of that time to write a low-level (quick) sort
algorithm.

~~~
mlthoughts2018
Interviewers are very bad at accounting for this.

For example, there is almost no engineering question on the planet that people
straightforwardly solve from first principles in 30 minutes, unless it’s
totally shallow based on memorization or childish rote practice — and has
virtually zero relationship to how they would ever solve any problem at work.

But there are all kinds of insanely hard problems that people can give you
beautiful solutions for in 10-20 hours, and involve an entirely different way
of working than anything possibly representable in 30 minutes.

Engineering and math questions just require burn-in and rumination, tinkering,
stop & get a cup of tea, take a walk, tinker more. They _just do._

Seeing “how someone thinks” in an artificial 30-60 minute session only tests a
completely separate and mostly unnecessary skill set for passing tests and
memorizing things.

~~~
koala_man
>Seeing “how someone thinks” in an artificial 30-60 minute session only tests
a completely separate and mostly unnecessary skill set

Totally agree. However, what's a good alternative? A company can't hire
everyone for a trial week, and a candidate can't work a trial week for every
company. It's really hard to design a hiring process that is efficient for
both parties plus resistant to abuse.

~~~
mlthoughts2018
They can ask probing technical questions about past work experience, projects
and education. Pretty much like how every other industry interviews people.

You are right that interviewers won’t get much more than an hour to judge a
candidate. So why waste it on information that fundamentally can’t be helpful
(like whiteboard trivia)?

Instead, first jump right into a domain where the candidate should already be
comfortable and technical — their past work projects — and go from there,
probing for more technical depth.

The idea that it somehow makes more sense to use limited time by wholesale
discounting & ignoring the person’s previous work history in favor of having
them write a sorting algorithm in CoderPad is totally indefensible.

------
Maro
I feel you, I also get stressed out during interviews and perform worse than
normally; it was the same for me during oral exams at Uni.

At one point I interviewed at a couple big ones and got into FB, where I also
did a fair amount of interviewing. My tips:

1\. Accept it's a numbers game; apply to N, and you'll get an offer from one.
I got rejected by Google and Spotify, got an offer from FB. Some people do
better and get more offers, but I know I'm a nervous type during interviews
and under-perform. It's okay, it's a First World Problem, just apply to more
companies. I think most people I know who work at G/FB/Spotify got rejected be
a few others.

2\. Practice a lot. There are 100s of questions available online. If you're
smart, you will pick up the patterns / tricks you can use to solve the coding
questions. Eg. when the obvious solution is O(n^2), usually there is a more
efficient one involving using a hashmap to do a lookup.

If you think the problems you find online are too hard or stupid (eg. "who
cares about implementing an LRU cache"), then read up on core CS topics to
appreciate the subject matter.

If you think it's not worth to invest the time to beef up for it, then (i) it
is, you can learn a lot at the big ones (ii) you can see how hiring candidates
who think it's worth it is better for the company.

3\. Think of it as a good thing. You brush up on your core skills (LRU cache),
and it probably forces/incentivizes you to look at some recent developments in
your sub-field so you feel prepared and can comment on it if it comes up.
Although I don't enjoy the interview itself, I find the preparation to be a
very fun time, reminds me of the good old days at University; a good break
from the usual crunch of the job, which usually leads to rusting of core
skills and specializes you in the tools the team/company happens to use.

4\. At the big companies, on the initial loops where you solve the shortish
interviewing questions, usually they just want you to solve the problem, not
talk too much. I found some candidates think they have to talk a lot and
relate the problem to their work, but that's not the case. Don't say "At work
I'd just use a library for this." That's obvious, that's not the point of the
interview. In the initial screens the interviewer just wants you to supply a
solution, explain it, and move on. So just do that. Be efficient.

5\. Getting rejected feels like shit but doesn't say much about you. It just
means you had a bad day, or you were nervous. Or maybe the interviewer
actually did a good job of assessing your skills, and you're not a good fit
for the team/org that was hiring. I've seen lots of people get rejected from
FB where I thought any smaller company would _kill_ to get them onboard, but
FB didn't accept them for some weird reason, which at a high level is sth like
"Would they be successful here at this role X, in team Y or Z, _given how this
role works here_? Maybe, but the hiring manager isn't convinced enough". It's
a bit frustrating, but it works for the company: the people who get through
the filter are very smart&good, work together very well and efficiently,
altogether create products Bs of people use (good for everybody), creates Bs
of revenues and Bs of profits. So it works, it's not going to change. Play the
game.

------
chrisbennet
Sometimes it's not the white board part of the interview that is the problem
but the anxiety and general anger the w.b. interview generates. It's a little
like getting groped by TSA at the airport.

It would go a long way towards making the experience better if the
interviewer/TSA guy stated right at the beginning said _" I realize this
experience is degrading and it sucks to be treated like a liar/terrorist but
I'll try to make it as pleasant as possible. "_ ?

A part of the reason we have this current interview process is because there
are people out there who can really "sell" themselves and have bogus resumes
so they have to screen these guys out i.e. "this is why we can't have nice
things".

~~~
monksy
> It would go a long way towards making the experience better if the
> interviewer/TSA guy stated right at the beginning said "I realize this
> experience is degrading and it sucks to be treated like a liar/terrorist but
> I'll try to make it as pleasant as possible. " ?

That's why I volunteer to be massaged. Can't be forced into something you've
already went along with.

------
techjuice
Best thing you can do is to enhance your skills in data structures and
algorithms so you have a strong base in them. The interviews normally start
here for most of these companies because their software deals with a large
amount of data structures and/or algorithms and is essential to understand to
be a productive contributor there.

If your previous work did not actually require you to know them, they probably
where not building algorithms from scratch or optimizing parsing/processing of
data very much. As without the essential basics of data structures and
algorithms it is very hard to build scalable applications that rely on them.

As you grow in your career you will have to learn things outside of your base
knowledge as you move up the ranks on the technical skills ladder. This will
be standard requirements for senior level positions which you are probably
seeing now. At the junior and mid level you are normally not responsible for
building the core pieces of data processing software engines or massively
scalable applications that run custom in house algorithms.

If you go through some of the below resources they should help fill that
skills gap and make you an overall stronger engineer so you can feel confident
applying for senior level positions.

I would recommend taking the following course:
[https://www.coursera.org/specializations/data-structures-
alg...](https://www.coursera.org/specializations/data-structures-algorithms)
[https://www.edx.org/course/algorithms-and-data-
structures](https://www.edx.org/course/algorithms-and-data-structures)
[https://in.udacity.com/course/data-structures-and-
algorithms...](https://in.udacity.com/course/data-structures-and-algorithms-
foundation-nanodegree--nd004-indsa)

and reading the following book: [https://www.amazon.com/Introduction-
Algorithms-Press-Thomas-...](https://www.amazon.com/Introduction-Algorithms-
Press-Thomas-Cormen-ebook/dp/B007CNRCAO)

------
bradstewart
Practice. I have a very similar reaction to those types of interview
questions. Your day-to-day engineering work is entirely different, so it's no
surprise you get stuck on those questions. This programming interview book [0]
really helped me.

While I don't agree with this type of interview, it is the reality we live in.

Disclaimer: The book was written by a professor of mine in college. [0]
[https://elementsofprogramminginterviews.com/](https://elementsofprogramminginterviews.com/)

------
throwaway080383
"But each failure kind of brings me down, and makes me think that I'm a bad
engineer."

You're not. I do these type of interviews and there are plenty of times where
a person doesn't pass but I can tell it's just because they need to prepare
more. I think your strategy of applying and failing is good, but I would also
supplement it with practicing these type of interviews (e.g. get a whiteboard,
go to leetcode or wherever, pull up a random question and pretend like you're
in the interview).

------
jeffrallen
Try practising speaking your ideas and approach out loud. This may do two
things, which reinforce each other: giving yourself momentum and positive
vibes as you say things you know are right and leading you forward towards the
answer, and building a clearer idea of your skills and manner in the minds of
the interviewer. In effect, you are trying to turn the liability of the
audience into an asset.

------
randop
You are not alone on this one. I myself have also been through this
experience.

Have you considered a different option ? How about building your own start-up
to serve real business needs? Or working on open source projects. There are a
lot of opportunities to look forward into.

Why keep banging your head multiple times on something, when you can use that
energy on other meaningful ways.

~~~
gaahrdner
I like what you're saying, but there is quite a bit of comfort and safety that
comes with a $100,000+ job compared to starting up your own business. While
many of us are ok with that risk, others may very well have responsibilities
that dictate taking the "sure thing."[0]

0\. [https://danluu.com/startup-tradeoffs/](https://danluu.com/startup-
tradeoffs/)

------
tananaev
One thing people often don't realise about interviews at Google and other
companies with similar interview standards. You can't casually apply for
those. You have to prepare a lot. At least for a month (probably much more)
before the interview you have to practice coding questions on Leetcode or
similar resources.

------
smt88
My company doesn't use this for interviews for many reasons. It's absolute
nonsense.

Email me at the link on my profile if you'd like a list of our open positions.

------
AlexCoventry
Would you get different results if you were in a room by yourself, under exam
conditions? Maybe some companies would let you test that way.

------
paktek123
Having gone through the same situation, I'd advise practice and you'll
eventually catch on. Hackerrank is a good place to start.

------
avip
Practice, practice, practice. Then practice more. It sucks, but until we get
to set the rules - just practice 'till you good.

------
foobaw
Solve 150+ random leetcode questions. Play a video on YouTube of someone
watching you and "taking notes."

------
justaaron
Consider freelancing or going into business for yourself.

------
linouk23
Practice on interviewing.io

~~~
Kelicious
I conduct interviews on interviewing.io so I'd just like to add some
clarification on this advice. You don't get unlimited interviews so it's best
used for interview practice, not coding practice. If you have trouble with the
technical parts (sorting, trees, etc), you can learn that on your own from
books/leetcode. Once you're confident in your coding and CS fundamentals, use
interviewing.io for the aspects of interviewing that you can't learn from
leetcode: gathering requirements from the interviewer, explaining your thought
process, staying calm under pressure, time management, etc.

------
ninjakeyboard
Interviewing is its own skill!! To get into eg Google you have to go through
the rites of passage of learning to interview. That's not true of all
positions. I give take-away assignments now. I want to see you can turn in
good code. That's all I really care about. How you get there doesn't matter,
your decisions do.

The Golden Rule: When in doubt, use a hashmap. Almost all code challenges are
about finding an algorithm or datastructure to fit the problem/solution. Many
of them are solvable efficiently via a hashmap.

Preparation

\- Practice on a whiteboard

\- Do mock interviews with the most skilled people you can find and get
feedback! This is critical to glean any information about how you're actually
doing! I could volunteer to do that for you remotely if you like. Send me your
contact info. I'm a distributed systems guy but could walk you through some
problems and tell you how you're doing with whatever you're using for tech
very likely still. Drop a note on how to connect if you're comfortable.

\- Take an algorithms course before you interview. (The princeton sedgewick
one is great and easy to grokk. see coursera:
[https://www.coursera.org/learn/algorithms-
part1](https://www.coursera.org/learn/algorithms-part1))

During:

\- Write tests for your code during the interview to demonstrate production
quality code.

Especially if interviewing for eg Google. They don't give super tricky
problems in every interviews (eg during phone screen) - focus on writing good
code that is tested and will compile and run after the interview, not writing
mediocre code fast.

\- It's okay to incrementally improve your solution. Talk through your
thinking. Start at the naive solution and then work toward optimal. Eg give
two lists, find any number from list a sums to any number from list b. To
start, you could write a couple quick tests on the board to make sure you
understand the problem. Then you could reason about solutions - say you could
use nested for loops. That's O(n squared) which isn't suitable as a solution.
So you ask if the data is sorted. If they say no, you can sort lists, iterate
through one and binary search on the larger list to get to an asymptotically
linearithmic solution. That's suitable so you write that fairly swiftly. To
improve you discover you only need to sort one list so you change the solution
to only sort the larger one and iterate through the smaller. If there is extra
time you might start to reason about how you can move toward a linear
solution. Remember I said the golden rule is use a hashmap? Why don't you make
a hashmap out of one of the lists and iterate through the other one to find
values in the map? Don't just sit there and take it away to the corner and try
to solve it.

God Mode: \- WAYYYY before you take the interview: Stop using an IDE at work
if you're working in a statically typed language. Use emacs, or vscode or
whatever you fancy. Moving to emacs made my brain learn the qualities of the
language at an intimate level faster than anything else. You check the docs if
you forget the api until you stop forgetting the API. It slows you down a bit
at first so it's an investment but whatever - tack 25% on your estimates for a
few weeks. You can revert to the IDE for larger refactoring work.

------
samueldavid
you don't want to blame the process, yet you admit it brings you down every
time you fail and makes you doubt of the already proven ability you have as an
engineer, and the process is ok?

~~~
crististm
Your answer is not helpful on several levels and you might even know it.

~~~
samueldavid
he is just hurting himself by trying so hard on a already broken system,
encouraging him to keep going at it like most of the user on this thread( Keep
drilling! keep drilling!) will just make him more sad and doubt even more of
his own skills which are already proven on his company to be good enough, if
anything people should encourage him to try places that don't use such broken
methods and go for companies that really value his skills and dont take such
broken process seriously.

~~~
crististm
Apparently you place no value in an evaluation done within a broken process -
and rightfully so.

I have to ask: how do you tell a good process from a bad one?

~~~
samueldavid
(personal opinion), but to me a process that encourages these kind of drills
is pretty broken, these drills are ( most of the time) not related to the real
world problems the company faces on a day to day basis, imo, a better process
( but not perfect) would be to test candidates on problems related to the ones
you face at the company combined with cultural fit / pair programming
sessions, even tho not perfect it can attract more candidates that are more
fitting to the company and the team.

this doesn't mean the tests and problems need to be easy or an easy pass, they
can be just as hard or even harder to solve, depending on the problems you
guys face, i often hear people defending the drills because "people just want
a for loop problem and fizzbuzz and easy pass", which is not the case for many
seniors engineers that would like a decent challenge related to what the
company works on.

~~~
crististm
If I understand you correctly, the bad issue is tests by drilling for drilling
sake. I agree with you but follow me on this:

Am I wrong to say that he as one person is in no position to change the
process?

What I mean is that his choices are either to just go through the hoops and
reject to the drills because they are not representative for his ability, or
accept this testing but not stamp negative results on his quality as a person
or developer.

In the end he is not defending the process too strongly; is seems to me that
he simply wants a formula to navigate it.

------
chrisjshull
Shameless plug:
[https://chrisjshull.com/agent/](https://chrisjshull.com/agent/)

~~~
tom_mellior
Meta: I downvoted you for not explaining what this random link is and how it
relates to the topic.

