
How to prepare a technical interview (and why good programmers also fail) - rafapaez
https://www.rafapaez.com/2019/10/how-to-prepare-technical-interviews.html
======
ping_pong
The reason why good programmers also fail technical interviews is because the
algorithmic/coding questions are mostly random. You can be asked any of over
1000 distinct questions, and if you haven't seen it before, almost no company
will "reward" you by figuring it out on the spot. Instead they will compare
you to another candidate that studied that question and gave a solution in the
allotted time.

It's completely random chance at this point. I have friend who solved 700-800
Leetcode questions and got offers from Google and Facebook. I recently did 100
LC questions and got destroyed in the interviews. They didn't care about
communication skills, asking the right questions, etc, everyone including
Google, Facebook, Netflix etc expects the correct answer at the end.

It is what it is, and I accept it. It's stupid, it's not representative of how
I work, and it's completely gamed at this point, but it's how Silicon Valley
is hiring. There's no use in pretending I'm better than it, so it's just plain
studying and leetcoding for 2 hours a night until I get a new job.

~~~
acheron
Or you could get a job in a place that isn’t a dystopian hellhole. The country
is pretty big, you don’t actually have to work in California. Other places
don’t do this.

~~~
stjohnswarts
Exactly, I've called out a fellow coder on these lame-ass questions before. My
technical questions are things we are doing, how do you approach a big
software problem, and some fundamental language questions. My co-worker always
pulls out these lame zinger questions like google and she and I always give
different appraisals almost every time of interviewees. Too many time someone
has answered her "zinger" but hadn't the slightly clues about the fundamentals
of programming or what we are currently coding for.

------
eveFromKarmaFm
A long time ago I came up with an acronym that's served me well as a
consultant who has to bounce from one customer to the next and run through
interview gauntlets of all types: RACEMOORES:

R: Restate with sample inputs/outputs/diagrams

A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now
and in the future

C: Complexity: runtime complexity, space complexity, etc

E: Edge cases

M: Maintainability

O: Overflow

O: Optimizations

R: Refactoring - DRY / SOLID / etc

E: Extensibility

S: Scalability

I use the "memory palace" heuristic to guide me through this, where each
letter is a naked dude waving a flag on a racetrack I vividly remember from
Gran Turismo back in the day. Absurdity helps it stick . I start every
interview by writing this on the board and checking off the letters as I run
through them. I usually stick another "O" in there for "Other stakeholders",
depending on the gig.

This happens to work nicely when guiding/assessing interviewees through
technical scenarios as well.

~~~
rafapaez
That's really witty! I might try to create my own acronym for interviews.
Cheers!

------
dplgk
Hard to take advice from an article with a ton of typos.

The interview process seems to favor CS grads who memorize academic exercises
and algorithms. It doesn't seem to take into account if you can actually
produce a product and write maintainable code. I don't see the point as you
can Google just about any solution during the work day, as needed, and real
life work doesn't require you to write galaxy-scale algorithms within a 30
minute deadline.

~~~
dan-robertson
I think the author is just not a native English speaker. The typos seem pretty
consistent (eg the author thinks chance is spelled change) and there are some
grammar errors and unidiomatic phrases but I don’t think it’s particularly
difficult to read or that the errors should imply the article is bad. My guess
is that the article is a translation to English of an article in Spanish for
Spanish-speakers (eg it talks about “international” startups)

~~~
rafapaez
You're right. I'm not a native English speaker. That's why I speak in Spanish
in my videos. I wrote the article too quickly (which indeed is a summary of
the video) and the grammar corrector wasn't very smart with the "changes"
things. Thanks for pointing out the typos.

------
Animats
This is so funny.

"The first advice is nice and simple: read my posts and watch my weekly
videos." (Which he started two weeks ago.)

"Do not use the mouse! And use Vim or Emacs. Professional programmers only use
keyboards and this kind of editors." (It's not 1980 any more, guys. There's
been progress. The only time I use Vim is if I have to SSH into something.)

"Actually, there is less than 10% of changes to pass a technical interview, so
don't set high expectations." (Does he mean "chances?")

~~~
rafapaez
There is a bit of humour in the video which is hard to translate into written
words. And you got these "funny" points.

------
ben509
> Let me conclude with a personal quote:

> "The most important capacity for Software Engineers is their ability to
> developer soft skills"

Maybe those will get you hired, but attention to detail helps you keep your
job.

~~~
tiglionabbit
I can confirm that soft skills are highly valued and useful on the job as
well. They are the #1 criteria at most tech companies I've worked at. I'm
highly regarded as awesome technically but I've lost jobs based on my poor
soft skills alone.

The company I'm working at right now gives out a bonus at the end of the year
so long as your work "meets expectations", but they have a specific rule that
if they don't like your behavior it doesn't matter how good your work is
because your bonus will be set to zero. It's the "no brilliant assholes" rule.

~~~
TheChaplain
Sounds like a terrible workplace honestly, when your performance is evaluated
on subjective and highly ambiguous criteria.

------
notus
The technical interviews I enjoy the most are where I write a small piece of
software beforehand and we discuss the code during the technical interview. It
gives me a better idea on what to prepare for because most questions are going
to be about your technical decisions and ways to improve the solution. The
downside is that doing a project for every job is a lot of work.

~~~
rafapaez
I think this is the trend nowadays, at least in Europe startups/companies.

------
muwoi
I don't like the terminology 'fail'. It implies a mental model like an
examination, where there's a clear link from effort, to performance, to
reward.

A job interview is more like a date. It's two parties with a limited amount of
time trying to gauge if they will be compatible. And, like a date, you
shouldn't feel personally deficient if you end up being a poor fit. You should
be aware that the other party may already have someone in the sidelines
because, if you're popular, so may you. If the other party makes you jump
through hoops you find silly, maybe that just means you're a bad fit, at which
point you should feel confident to withdraw as an equal participant. If you
pretend you're a better fit than you are, it won't work in the long run.

Crucially, you also shouldn't feel you're owed a reward just for being a good
catch. If you are that good, it won't matter.

------
interview1234
I got the most out of mock interviews: friends, colleagues, and when I ran out
of people sites like PracticeCodingInterview.com, Gianlo.co, and Pramp.com.
Just having a stranger judging me helped me up my game.

------
dugreader
Also remember that many great opportunities will not have as their only states
litmus test the usage of VIM. Not even most people that prefer that
environment would use it as a litmus.

------
rb808
I'm starting to think the best way to prepare is to pay a coach to train you
up and give feedback. The interviews dont have much to do with reality, if you
want to be good at leetcode style whiteboarding you need to get advice from
someone who knows how it works on the inside. (yeah I'm bitter)

------
ohyes
Hard to take this seriously when “Watch my videos” and “don’t use a keyboard”
are the first two tips.

~~~
rafapaez
“don’t use a mouse” ... but true, I usually add some "fun" points into my
videos and I tried to write it down (which is hard). Thanks for your comment.

------
amriksohata
Hired many, realised as long as they can do basic coding, I am not bothered
about them solving complex problems. I need to identify their team and people
skills first.

------
m3kw9
Best interview is the 3 week probation period, prev job and ask general
questions on what you did that only someone who actually did that role would
know.

------
paulcole
The point of the interview isn’t to keep good programmers from failing, it’s
to make sure bad programmers don’t pass.

------
Clubber
I read a theory that says that these impossible interviews were designed so
that companies can say they couldn't find any qualified stateside candidates
so that they could get more H1B visas. It just kinda caught on because
everyone wants to imitate FAANG.

When I started in 1997, it was a 30-60 minute walk in. Now I understand multi-
day interviews are the norm. Madness.

~~~
aphextron
>When I started in 1997, it was a 30-60 minute walk in. Now I understand
multi-day interviews are the norm. Madness.

I think a lot of it is just the glut of CS grads these days. The whole myth of
a "tight market" for developers is just nonsense; companies have their pick of
thousands of qualified developers these days and they can afford to pick and
choose. Ultimately they are filtering for someone who can not just do the job,
but jump through their hoops and be a good "culture fit".

~~~
mav3rick
They try to choose the best and are spoilt for choice. Why won't they make it
tough to get in.

------
whycombagator
> Listen: do not use the mouse! And use Vim or Emacs. Professional programmers
> only use keyboards and this kind of editors.

Sure...

~~~
chrisseaton
Where does this kind of nonsense attitude come from? I use GUI editors, use
the mouse, don’t use magic keyboard shortcuts, and I manage to produce
software like everyone else.

~~~
fouc
The speed of operating your tools definitely has an impact on your development
velocity. Invisible interruptions like switching from keyboard to mouse add
up.

That said, even though I use vim/keyboard mainly, I still have embarrassing
habits like opening a new vim for each file and cd'ing & ls'ing around to find
the files.

~~~
chrisseaton
If I can do the job and produce results as fast as needed why do you care
about how fast I’m switching between mouse and keyboard?

And we’re not typing programs in from magazines like in the 80s here. My
bottleneck is nearly always thinking time. Typing time is irrelevant.

~~~
fouc
I guess it depends a lot on the sort of programming that you're doing. But
there's still a lot of activity around the challenging bits that don't require
a lot of thinking. Things like organizational/cleanup, some types of
refactoring and testing, dealing with git and other commands.

~~~
drewrv
For some people/tasks, these are the exact types of things accomplished faster
in an IDE.

