8 ms·

How to prepare a technical interview (and why good programmers also fail)

73 points by rafapaez 7y ago

fstopmick 7y ago
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 7y ago
  That's really witty! I might try to create my own acronym for interviews. Cheers!
dugreader 7y ago
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.
Clubber 7y ago
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 7y ago
  >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".
  - gnaritas 7y ago
    It's not a myth, most of the so called qualified devs on the market are terrible programmers. Companies do not have their pick, about 1 in 20 are worth hiring; most absolutely suck and can crank out extremely shitty code, but don't much understand what they're doing.
  - mav3rick 7y ago
    They try to choose the best and are spoilt for choice. Why won't they make it tough to get in.
- closeparen 7y ago
  Rank and file engineers give interviews and participate in debriefs. If the interview process were subverted for H1B candidates, you can bet they would be screaming about it.
whycombagator 7y ago
> Listen: do not use the mouse! And use Vim or Emacs. Professional programmers only use keyboards and this kind of editors. Sure...
- chrisseaton 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        For some people/tasks, these are the exact types of things accomplished faster in an IDE.
ben509 7y ago
> 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.
- x0x0 7y ago
  Seems decent to cut ESL folks a little slack.
- tiglionabbit 7y ago
  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 7y ago
    Sounds like a terrible workplace honestly, when your performance is evaluated on subjective and highly ambiguous criteria.
interview1234 7y ago
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.
muwoi 7y ago
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.
dplgk 7y ago
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 7y ago
  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 7y ago
    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.
ping_pong 7y ago
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.
- akhilcacharya 7y ago
  With that said, there are lots of people that get offers like that without doing 800. (Most people I know have done like < 50 and some claim to have never done any!). I did ~240 and I still struggled when I did new grad interviews. Feels like an IQ test to me quite honestly.
  - mav3rick 7y ago
    Not everyone is equally smart.
    - akhilcacharya 7y ago
      How exactly am I supposed to interpret that?
      - mav3rick 7y ago
        That it's not a given that you did 240 questions was a guarantee for you to pass these interviews. 1. Natural aptitude often separates people 2. There maybe people who are just good at DS and Algo or have done competitive programming that they don't need these questions. Either way it's not as straight forward as doing X or Y and getting in at Google FB is guaranteed.
notus 7y ago
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 7y ago
  I think this is the trend nowadays, at least in Europe startups/companies.
paulcole 7y ago
The point of the interview isn’t to keep good programmers from failing, it’s to make sure bad programmers don’t pass.
rb808 7y ago
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)
Animats 7y ago
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 7y ago
  There is a bit of humour in the video which is hard to translate into written words. And you got these "funny" points.
m3kw9 7y ago
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.
ohyes 7y ago
Hard to take this seriously when “Watch my videos” and “don’t use a keyboard” are the first two tips.
- rafapaez 7y ago
  “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 7y ago
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.

73 points by rafapaez 7y ago

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 7y ago
That's really witty! I might try to create my own acronym for interviews. Cheers!

dugreader 7y ago

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.

Clubber 7y ago

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 7y ago
>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".
- gnaritas 7y ago
  It's not a myth, most of the so called qualified devs on the market are terrible programmers. Companies do not have their pick, about 1 in 20 are worth hiring; most absolutely suck and can crank out extremely shitty code, but don't much understand what they're doing.
- mav3rick 7y ago
  They try to choose the best and are spoilt for choice. Why won't they make it tough to get in.
closeparen 7y ago
Rank and file engineers give interviews and participate in debriefs. If the interview process were subverted for H1B candidates, you can bet they would be screaming about it.

whycombagator 7y ago

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

chrisseaton 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        For some people/tasks, these are the exact types of things accomplished faster in an IDE.

ben509 7y ago

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

x0x0 7y ago
Seems decent to cut ESL folks a little slack.
tiglionabbit 7y ago
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 7y ago
  Sounds like a terrible workplace honestly, when your performance is evaluated on subjective and highly ambiguous criteria.

interview1234 7y ago

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.

muwoi 7y ago

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.

dplgk 7y ago

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

ping_pong 7y ago

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.

akhilcacharya 7y ago
With that said, there are lots of people that get offers like that without doing 800. (Most people I know have done like < 50 and some claim to have never done any!). I did ~240 and I still struggled when I did new grad interviews. Feels like an IQ test to me quite honestly.
- mav3rick 7y ago
  Not everyone is equally smart.
  - akhilcacharya 7y ago
    How exactly am I supposed to interpret that?
    - mav3rick 7y ago
      That it's not a given that you did 240 questions was a guarantee for you to pass these interviews. 1. Natural aptitude often separates people 2. There maybe people who are just good at DS and Algo or have done competitive programming that they don't need these questions. Either way it's not as straight forward as doing X or Y and getting in at Google FB is guaranteed.

notus 7y ago

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 7y ago
I think this is the trend nowadays, at least in Europe startups/companies.

paulcole 7y ago

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

rb808 7y ago

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)

Animats 7y ago

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 7y ago
There is a bit of humour in the video which is hard to translate into written words. And you got these "funny" points.

m3kw9 7y ago

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.

ohyes 7y ago

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

rafapaez 7y ago
“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 7y ago

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.