
Ask HN: How can I prepare for a coding interview in a week? - mattdue
I am from ECE background, been working in machine learning, and data analysis fields for couple of years, and have decent coding experience in Python and C&#x2F;C++.<p>I am about to be interviewed by one of the big five (they reached out to me, I wasn&#x27;t actively preparing for interviews).<p>Not being from a CS or software engineering background, I never took an algorithm and data structure course, and from what I know the coding test mainly involves those.<p>I know there are a ton of resources online for coding interview preparation, but I wanted to seek suggestions on an efficient&#x2F;quick resource given that I have strong coding skills but not familiar with data structure&#x2F;CS algorithm.
======
shankr
Truthfully, you don't have enough time. There are so many candidates who
basically eat and breathe Data Structure and Algorithm for at least few months
so that they can get into big five that your last one week preparation might
not match up to them, especially without any prior experience like a course. I
don't want to demoralize you, but how about you tell them that you aren't
prepared right now, and would like to interview after 4-5 months. I think
these companies are always looking for good talent, and don't mind
interviewing someone later if they find the profile interesting.

~~~
caseymarquis
This sounds like great advice, but it's very funny from a distance. "I think
I'm a great candidate for the work you need done, but your interview process
has nothing to do with that. As such, I'll need to reschedule so I can spend a
few months gaming that process."

I'm excited to be interviewing programmers in the near future as our company
grows. I have to think through a lot of things, but I'd like to focus on: Have
you successfully deployed an application before? How have you overcome the
technical challenges of programming on a team. How have you improved your
abilities over time. Explain something you're proud of creating in the format
you're most comfortable with. How do you power through losing passion about a
project? How comfortable will you be learning new frameworks and paradigms?
Prove to me that you're an able programmer in whatever format you'd prefer.
Etc.

All questions available ahead of time. Try to keep things comfortable for the
candidate. Enough depth and variance to figure out if they have the technical
skills you need. You get to see how they like to work.

~~~
arenaninja
An honest question for HN: has anyone really been in a project whose primary
reason for failure was the lack of engineering talent? I have worked in
micro/small businesses and large enterprise environments, and this has never
been the case. The projects I have seen fail usually do so due to poor
management, poor performers are typically fired unless they can pull one over
management to make themselves seem more competent than they really are (not
that difficult with bad management)

~~~
shaftway
I have. It's a long and interesting story, full of intrigue, backstabbing,
hacking, and corporate espionage. But in summary:

Owners started tech business using trust-fund money. They were extremely non-
technical, scared of computers to be honest. They hired people that were like
them (also non-technical), and didn't have the ability to properly vet
candidates. Tech staff was hired basically off of Craig's List with very
little interviewing. Tech was built and company got large enough to get a
couple contracts (heavily influenced by owners' existing personal
connections).

As you'd expect, tech stack started creaking under the load. At first tech
staff thought they had everything under control (strong Dunning-Kruger effect,
bolstered by early successes). Eventually tech staff realized how badly things
were going and started lying to management to cover for their own
incompetence.

Decent tech management was hired (I think by accident) and the tech staff saw
the writing on the wall. The entire tech staff just didn't show up to work one
day. Left without any notice or warning (the more intriguing stuff tangents
off here). New, more capable tech staff was hired (including me). At this
point the system was hemorrhaging data and users. We triaged, stemmed the
bleeding, and built out a decent infrastructure with a decent tech stack.

Unfortunately for them that was too late. The contracts had fairly stiff
penalties for non-compliance, and the company was in non-compliance for a
looooooong time. The owners had made some false statements about the assets of
the company, and settlements offered were based on those statement, far too
high for the company to pay. Other companies were pissed about that and took
it to court. Owners ended up getting taken to the cleaners and lost pretty
much everything, including a bunch of assets that they had owned before but
transferred to the company (including real estate) in some fairly shady tax
dodge scheme.

Ultimately the world is a better place now that this company doesn't exist. It
operated in an extremely sketchy manner, and I left when I found out the gist
of what was going on. I learned the earlier and later parts of the story from
personal connections.

Does that count? I mean, ultimately I think if you have poor engineering
talent then it's management's fault. But you can make that argument for any
corporate issue: it's management's fault for not recognizing the problem and
addressing it soon enough.

------
netgusto
I'm in a similar situation RN, and this is my battle plan:

𝗗𝗮𝘆 01

* Backtracking - know how to solve 1 problem (Knight's tour)

* Tree - implement BST

* Tree traversal - implement DFS, BFS & DFS iterative

𝗗𝗮𝘆 02

* Quicksort - know how to implement

* Mergesort - know how to implement

* Binary search - know how to implement

* Min/Max Heap (priority queue) - know how to implement

𝗗𝗮𝘆 03

* Graph - implement adjacency list

* Graph traversal - implement DFS, BFS & DFS iterative

* Graph algo - implement "Prim Minimum Spanning Tree"

* Graph algo - Implement "Detect Cycles algo"

𝗗𝗮𝘆 04

* Graph algo - Implement "Detect Connected Components" algo

* Graph algo - Implement "Lowest Common Ancestor" algo

* Graph algo - Implement Djikstra single shortest path algo

𝗗𝗮𝘆 05

* Sets - Determine all subsets of a set

* Sets - Determine Maximum consecutive subarray sum

* Sets - Determine 2 sets intersection

𝗗𝗮𝘆 06

* String - Implement Levensthein Edit distance

* String - Implement Polynomial Hash

* String - Determine all substrings

* String - Find anagrams

𝗗𝗮𝘆 07

* String - Implement KNP algorithm for pattern matching

* Basic DS - Implement Queue, Stack, Dynamic array, Linked list absolutely cold

\----

I chose javascript as the language for all this brushing up (no need to manage
memory, and I can focus on the algo)

It's a big list, but it's a traversal of the CS engineering domain that makes
sense to me, and it's only a fraction of the expected knowledge for that kind
of interview.

\----

Edit: I pushed some of the code of this list on GH here:
[https://github.com/netgusto/brushup](https://github.com/netgusto/brushup)

I struggle to implement each concept in the smallest, simplest way possible.
I'll keep adding code as I write it.

~~~
rimliu
Why would you want to work for a company which asks these question in the
interview?

~~~
shaftway
I can't speak to other companies, but I do know my [unofficial] experience
interviewing (on both sides) at Google.

As an interviewee, you know that you're going to have a handful of different
interviewers. What you don't know is how much of an effect each of those
interviewers is going to have on the hire/no hire decision. Is one bad
interviewer enough to torpedo you? Two? And you have no idea what kind of
questions each interviewer will ask. So, let's say only 10% of interviewers
ask these kinds of questions (I'm guessing that's low). That's a ~41% chance
that you're going to have to answer this, and if one bad interviewer is all
you need, then you'd be foolish not to prepare just in case.

As an interviewer, we're given surprisingly few guidelines on how to
interview. You take a one day class, then shadow half a dozen interviews, and
that's it. We aren't given specific questions to ask, and specific questions
get banned all the time (any time they're "leaked" as a Google interview
question).

Once someone is hired it's _really_ hard to force them out, so approving
someone who talks a smooth game but can't back it up is extremely costly. I've
seen teams get stuck with multiple people for well over a year because it
takes a long time to get them out, they won't leave willingly. Meanwhile
they're taking up headcount and letting them actually touch code is dangerous.
In fact, I've seen teams spend an additional engineer training them to the
point where they are productive, just because that's cheaper.

So you want people to actually prove themselves with some kind of an algorithm
question, but you get no real guidance on how to provide these and you
constantly have to come up with new ones, but they have to be the kind of
question that take less than 45 minutes to explain and solve. I have no doubt
that some people fall back on these kinds of questions.

Yeah, I get that these questions suck, and I try not to be _that interviewer_.
But as an interviewee I would consider it extremely foolish to not brush up on
it, just in case.

~~~
bsvalley
You said it yourself "they're taking up headcount and letting them actually
touch code is dangerous". My question is, how did they managed to get into
Google if they apparently don't know how to write code? The only way to get
into google is to go through a huge set of 45-min whiteborad crap. Not once,
not twice, we're talking about 7-8 times! Going over the same stupid 45-min
"technical screen" where only the original question varies. You need to know
all the CS basic stuff + ability to scale (if possible). Like they all say in
Silicon Valley - the only way for us to know if you're a rockstar is if you
manage to crack a few meaningless problems on a whiteboard. Oh... and make
sure to pick your favorite language. Your Resume tells us you have a MS in CS
but we don't believe it. So we're gonna put you back into a college-like exam
to make sure your degree isn't fake.

To me, that's step zero. I still can't believe companies like Google, etc get
stuck at step 0. They don't seem to care about step 1, 2, 3, 4. It doesn't
matter if you have 1 year or 10 years of experience, we all go through step
zero (again, even though we got an MS in CS a few years back).

So, if Google ends up in a situation where "teams get stuck with multiple
people for well over a year because it takes a long time to get them out",
it's because the hiring process at Google sucks. If it is that costly and
painful to hire the wrong people, then why Google hasn't put more resources to
actually innovate and think beyond college-like evaluations. It is OK for
people with zero experience, it is not OK for people with at least one work
experience (which I call step 1). Of course, if you have 10 years of
experience they need to use a different language in order to interact with
you. So, unless someone just graduated from college looking for a job, you
can't hire someone exclusively based on step 0 because it simply doesn't tell
you if a candidate knows how to write code, build features, work in a
collaborative environment, deal with requirements from product team, reuse
exiting code, handle code reviews and feedback from peers, create frameworks
or adopt new frameworks. All it tells you is if your CS degree is fake or
not...

~~~
shaftway
> The only way to get into google is to go through a huge set of 45-min
> whiteborad crap.

This is not the _only_ way to get into Google.

> Not once, not twice, we're talking about 7-8 times!

When I interviewed I had one 15 minute phone screen, and one round of in-
person interviews. The in-person set was 5 people. Of those I think I cratered
on one of them, did adequate on two, and stellar on the last two.

> Like they all say in Silicon Valley - the only way for us to know if you're
> a rockstar is if you manage to crack a few meaningless problems on a
> whiteboard.

Very few people get hired as a "rockstar", and the ones that do tend to be
hired for non-coding roles.

> Oh... and make sure to pick your favorite language.

Yeah, the point is for you to answer the question and not get hung up on
language semantics that you aren't comfortable with. I interviewed in C#
despite ~0.1% of code at Google being C#. I had a very in depth conversation
about contract differences between C# and Java that I think impressed the
interviewer, despite me not knowing a single line of Java and him not knowing
a single line of C#. If you pick the language and still struggle with the
semantics of it, that's a huge red flag.

> Your Resume tells us you have a MS in CS but we don't believe it. So we're
> gonna put you back into a college-like exam to make sure your degree isn't
> fake.

An MS in CS doesn't, by itself, qualify you for a role at Google. I have
plenty of friends who have the degree who I like very much, but I wouldn't
want them on my team.

> I still can't believe companies like Google, etc get stuck at step 0. They
> don't seem to care about step 1, 2, 3, 4. It doesn't matter if you have 1
> year or 10 years of experience

Yeah, I came in with 15 years of experience across 7 different firms. And I
went through the same thing. I've also worked with people who have been in the
industry for all kinds of timeframes, up to 35 years, and I've seen little to
no correlation between "experience" and ability.

A higher-touch process with more "describe what you did at company X" would be
nice. But it also feels easier to game. I read design docs for projects at all
levels at prior roles, including rationale, alternatives, etc. If I wanted to
pass one of those project off as my own through an interview I don't think
it'd be very hard. I also don't see any other companies that hire at the rate
that Google does (well over 100 software engineers per week) that manages to
do that.

> So, if Google ends up in a situation where "teams get stuck with multiple
> people for well over a year because it takes a long time to get them out",
> it's because the hiring process at Google sucks.

So now you're arguing for a _more_ stringent review process, but one that
doesn't require actually demonstrating any abilities? Also, this is less of an
issue with hiring, and more of an issue with staff management.

> you can't hire someone exclusively based on step 0

I'm not sure why you think that Google is "stuck" at step 0, or that we stop
there. There is generally no feedback to a candidate about why an offer isn't
extended. You're assuming that it's because of a whiteboard coding issue when
it might be that your experience doesn't really mesh with what's needed.

There are a wide variety of factors that candidates are scored on, and there
are plenty of them that have nothing to do with the code that's written on the
board. I've had plenty of candidates that have gotten a "hire" recommendation
despite not having an optimal, or even a correct answer on the board. I was
confident in their abilities because they demonstrated that they recognized
there was a problem, usually due to running through test cases, and that given
enough time they would solve it. I've had candidates that have gotten a "no
hire" because, despite have a correct and nearly optimal answer, they refused
to listen when told that "result &= true;" is a no-op in Java.

Is the interview process perfect? Of course not. Perfection isn't achievable.
And I'm happy to listen to suggestions on how to improve the process. But your
suggestions seem to be: 1.) Don't ask whiteboard questions at all (which I
have yet to be convinced of), 2.) Don't stop at asking whiteboard questions
(which we don't).

------
Shish2k
I'm doing a lot of interviewing at a big five company, but speaking personally
and unofficially - when it comes to code, I'm looking for fluency more than
anything else. At the phone screen level (which I assume is where you're at),
the questions I ask are in the same complexity ballpark as fizzbuzz (ie the
task will be fully specified in 5 sentences and assumes no prior knowledge),
and I expect a candidate to be able to implement that without having to google
for "how do I access an array element in <language that the candidate has
freely chosen and claims to have mastered>?". The bar for on-site interviews
is somewhat higher, but for the first round of interviews, just "do they
struggle with basic syntax" is enough to filter out a remarkably large number
of people...

Also (again personal opinion) - python is the most practical language for
doing interview questions, because interviews are heavily time-constrained and
python allows the developer to go from idea to implementation in the shortest
amount of time. I'm not going to penalize anyone for their language choice,
but somebody who completes the task in 5 minutes and then spends 25 minutes
getting bonus points for things like "what if the input data is larger than
RAM?" is going to come across stronger than someone who spends 30 minutes on
parsing the input and runs out of time before they get to the algorithm.

~~~
shoo
> python is the most practical language for doing interview questions, because
> interviews are heavily time-constrained and python allows the developer to
> go from idea to implementation in the shortest amount of time.

i'm not sure if python is the best, but it's a very strong choice. python also
has a lot of built in data structures that are relatively non-broken and
highly useful for the archetypical algorithm-prototyping interview questions

e.g. if you are using a language that only lets you use strings or ints as
keys for dicts/hashmaps - instead of say letting you use immutable compound
values as keys, or a language that doesnt give you set data-structures which
support basic set operations (contains, equal, subset, superset, intersect,
union, etc), or a language that requires you to write a paragraph of OOP-
boilerplate to encode e.g. a list of pairs of values, you're making life
harder for yourself than necessary.

also, i claim without evidence that prolonged and continuous exposure to
working with languages that dont offer sensible data structures, or only offer
broken data structures, may over time hamper your ability to think and problem
solve clearly.

------
baruchthescribe
I was in this exact position a month ago and I landed a great job because of
doing very well in two technical interviews. I also am a strong Python
programmer who was rusty on the classic CS stuff. Go to Codility's programming
lessons page:

[https://app.codility.com/programmers/lessons/1-iterations/](https://app.codility.com/programmers/lessons/1-iterations/)

and try to do at least two exercises from each lesson up to lesson 15 if you
can. The open reading material at the top of each section is excellent and
discusses all the CS theory you will need.

Good luck!

------
badatshipping
Read chapters 2-5 of Skiena’s book, then do leetcode eight hours a day until
your interview. Start with high-pass-rate mediums, then work your way up, and
try to solve some hards. Spend about half an hour on each problem, and if you
can’t think of an answer, look at the solution, reimplement it, and think hard
about the underlying concepts.

This will not guarantee you a pass — honestly, some people spend months
preparing for the big 5 interviews — but it may give you a fighting chance,
and either way it will give you a good foundation for future interviews.

~~~
johan_larson
Leetcode is a good idea.

[https://leetcode.com/problemset/all/](https://leetcode.com/problemset/all/)

And frankly, given your lack of background in this area, it would do you a
world of good to get more time to prepare. Try to push the interview back a
bit. Even one extra week would be an improvement.

------
hal9000xp
I'm surprised nobody mentioned LeetCode. You can start solving 100 most
popular interview questions (sort them by difficulty first):

[https://leetcode.com/problemset/top-100-liked-
questions/](https://leetcode.com/problemset/top-100-liked-questions/)

If you've never took any algorithm course and have only a week for
preparation, it would be very difficult to prepare for coding interview. But I
think you can at least finish all easy problems from this list. In this case,
you may at least pass screening coding interview.

Right now, I'm very actively interviewing with pretty selective high-frequency
trading companies. I can say that LeetCode has pretty relevant set of
interview problems.

One more thing. Even if you solved a problem, always look at description of
solution, if there is no description of solution, you should look at
discussion.

From there, you can find references to common algorithms/themes like binary
search etc.

------
nwbrown
You aren't going to gain the skills gained by a four year education in a week.
And if you try it will likely be obvious. Interviewers (at least the good
ones) aren't looking for someone who knows a particular algorithm by memory,
they are looking for someone who is familiar with the concepts. And
familiarity is easy to distinguish from rote memorization.

The good news though is that unless you lied on your resume, they already know
that and are still interested in you. So you likely have other characteristics
they are interested in.

I would concentrate instead on learning about the company you are interested
in. That's something you can do in the course of a week.

~~~
xenihn
>You aren't going to gain the skills gained by a four year education in a
week.

I know someone who was able to pull it off in 2 weeks, though they were
unemployed at the time. They got into Google with 7 years of prior experience
at the time. He admits a lot of it was luck. But it's possible.

~~~
nwbrown
I'm guessing it's the 7 years of experience that impressed Google, not the two
weeks of cramming.

~~~
xenihn
Your background only matters for getting the interview. Whether or not you are
hired depends on your actual performance during the onsite.

~~~
nwbrown
Yes, but his performance was more aided by his 7 years of experience than his
two weeks of cramming.

------
wodenokoto
Ask your recruiter what the test contains and how it relates to the position
they are interested in hiring you for, and then just strait up tell them, that
you are not strong in algorithms and data structures, but you are strong in
ECE and machine learning, and they should hire you for those things.

------
Improvotter
You could try reading/skimming over the book "Cracking the code interview" to
get some insight in how the company handles interviews. The big five are in
there so you'd get more information that way. Besides that, a week should be
okay if you study hard and got good resources.

------
LandR
Man, I've never studied for an interview...

I turn up on the day, but then these interviews asking difficult algorithm
question seem to be a rarity in the UK, thankfully.

Our interview process seems to be much more reasonable.

~~~
some_account
Because it's insane. You will not use of those algorithms in your job, and
even if you do, they are ready to use in modules already.

It's just a way to see who can learn those algorithms because the big five
need to filter out most people somehow. This is their method of doing it.

~~~
nwbrown
More likely they aren't testing your knowledge of the algorithm but testing
your ability to write code.

------
alaq
Coderust has been an invaluable resource to me. Yes, it won't give you what a
CS degree gives you, but it's enough to make you feel confident in a week or
less.

[https://www.educative.io/collection/5642554087309312/5679846...](https://www.educative.io/collection/5642554087309312/5679846214598656)

------
bsvalley
Based on what you've described (not familiar with data structure/CS algorithm)
the answer is very simple - you can't prepare in a week. Don't do it.

Tell the recruiter you need a month to prepare or they will have to skip the
CS basic screen for you in order to fast forward the process. If you're one of
these niche developers (python/C++), you might have a little power when it
comes to asking you the right questions. Same goes when a company originally
contacted you, you're in a position of power.

~~~
sgillen
Sorry, are you saying knowing python/C++ makes OP a niche developer? I was
under the impression these were very common languages at the big-N? Or is it
something else about their background?

Not trying to correct you, I'm really just curious since I have a similar
background and an in a similar situation to the OP.

------
bunny9
[https://www.interviewbit.com](https://www.interviewbit.com) is a good
platform to practice algorithm and data structure questions as if in an
interview environment.

~~~
shreyanshd
+1 for interviewbit. But it cannot be completed in a week if OP tries to solve
all the problems. Instead focus should be on solving few questions from each
category.

------
skate22
Glassdoor is a decent website to guage the type of questions you'll get during
an interview for a specific position.

Ive had interviews that re use the exact same questions (fortune 100
companies)

------
dharness
Not that this answers the question, but if they're big 5 they should be
willing to give you more time. Ask them for a month and see what they say.

------
mateo411
I would postpone the interview. Give yourself at least 2 months to study this
stuff. If you can't postpone it, then I would go ahead and do the interview
anyway. There are some good suggestions below, try to spend at least a few
hours each day. Hopefully a few hours in the morning, then a break, and then a
few more hours. Get plenty of sleep.

When you do the interview, do your best and try not to care about the outcome.
If you don't care about the outcome, you won't be nervous and you'll likely do
better.

------
rhizome31
If the company is Google, be aware that they contact pretty much everybody.
You shouldn't feel special because they contacted you.

Why not stick to data science, which is very hot right now?

~~~
tiborsaas
You think for data science position they won't test you with the usual algo
questions?

------
mathattack
You can’t gain the knowledge of a CS degree in a week, but you can calm your
nerves.

Have some friends conduct a few mock interviews every day, giving you some
questions you don’t know the answer to. Then have them give feedback on your
poise, especially with difficult questions.

You will be calmer and more confident in the rough patches of the interview.

------
nwsm
Can anyone with experience with "big 5" interviews tell me what to expect out
of web development job application process?

As someone who is coming from another web dev job, not coming right out of
college.

Will I still be quizzed on data structures and algorithms? Or will it be more
on-topic subjects like frameworks, patterns, architectures, etc?

------
fahimulhaq
[https://www.educative.io/d/InterviewPrep](https://www.educative.io/d/InterviewPrep)
has courses to brush up on DS/Algorithms and problems to practice coding
interviews.

------
nslindtner
I would recommend 'the imposter syndrome".

[https://shop.bigmachine.io/products/the-imposters-
handbook](https://shop.bigmachine.io/products/the-imposters-handbook)

------
pushedx
[https://codesignal.com](https://codesignal.com) has a good intro-level
course, make sure to focus on the "medium" difficulty and above problems

------
mailjenil
[https://www.interviewcake.com/](https://www.interviewcake.com/)

Perfect if you want to crack something in a week

------
Anayapatra
You can opt for some mock interview practice app such as MockRabbit which I
generally use

------
unixhero
Probably good to know git

~~~
expertentipp
yup. "git push -f" \- allow it or ban it? Should git hooks run all tests
locally?

~~~
pjc50
\- Ban it for everyone; if you need it, temporarily grant power to the admin
to fix something.

\- Only if they take a completely trivial amount of time

------
pmlnr
Prepair on theoretical level as well, O notations, and such.

------
hanselot
I know this is going to come across as a stupid question, but I would like to
ask what the point is of studying for an interview? I am self-taught (under
guidance from a mentor) with no formal training, and don't understand why one
would prepare for an interview by studying. Isn't that dishonest in a way?
Shouldn't an interview determine if you are comfortable providing a service
and (ultimately) generating profit for the company hiring you?

~~~
rwnspace
I'm not a programming professional, but as I understand it: you study for
interviews because the biggest tech companies used to ask difficult data
structure & algorithms-based questions, plus some difficult/tricky questions
which require a particular style of thinking. Now nearly everyone does it, and
YouTube and textbooks offer lots of help... Which has started an 'arms race'
in knowledge about DS&A and answers to tricky problems between interviewers
and interviewees.

At some point I think it was intended to be like a 'coding-oriented IQ test',
after you'd passed a set of HR checkboxes. Obviously an IQ test you study
carefully for is not a broadly applicable measure of relative performance. As
far as I understand, many of the top companies are shifting away from this
interview paradigm, but it'll take the rest of the industry which adopted it a
long time to catch up (I imagine).

~~~
hocuspocus
You're mostly right. Also, big companies want to

* Minimize the time spent by their engineers interviewing candidates,

* Standardize the process as much as possible, so that anyone can run the interview.

I'm convinced there are many reasons for smaller shops not to blindly follow
Google's practices. But as a candidate, what can you do... it's their loss, I
guess.

