Coding Interview Preparation Bootcamp
medium.comWikipedia has an excellent article on this under https://en.wikipedia.org/wiki/Imperial_examination.
Essentially, the system used to recruit candidates into the Imperial Chinese state bureaucracy was an-ever-more-elaborate progression of less- and less-relevant testing, and more- and more-gamable (and expensive) testing. If you thought getting quizzed about FizzBuzz was bad, imagine getting quizzed about Beowulf with the same degree of seriousness.
"Intense pressure to succeed meant that cheating and corruption were rampant, often outrunning strenuous attempts to prevent or defeat them."
"In the 19th century, critics blamed the imperial system, and in the process its examinations, for China's lack of technical knowledge and its defeat by foreign powers."
This doesn't amount to any huge revelation to many of us when we're seeking jobs, nor any comfort, really.
Maybe a little bit of solace that the coding interview you inexplicably failed, which had the trappings of a serious attempt to gauge your fit, but the actual behind-the-scenes decision-making progress involved the finesse you'd expect from a group of blindfolded monkeys throwing darts, will eventually pay a dividend for all the fat dumb and happy juggernauts in the bay. Amazon may be the Sears of the 21st century, but I strongly suspect it and its cohort will meet the same fate a century later and for the same reasons.
FizzBuzz is relevant to job. People complaining about izzBuzz havent had the pleasure of working with someone able to talk about development well while being unable to write simple code. Problem of FizzBUzz is that it is too easy, so folks get insulted.
I have worked who are totally passionate and read all the blogs and can talk about all new buzzwords and techniques. Who simultaneously had problem write simple code. That is incomparable to Beowulf.
I agree completely on Fizzbuzz. It has saved us from making so many bad hires. It takes 15 minutes during the interview and you learn so much about a candidate. Not only if they can do basic coding but also how they react when they encounter something that don't know or conversely how they react when they think something is "easy" or "beneath them".
10 years ago I was asked how to tell if an integer is divisible by two without using division or modulus. What they expected was to bit mask the 1s place in the integer and check for equality with 0. I'd take Fizzbuzz any day.
10 years ago I was asked how to tell if an integer is divisible by two without using division or modulus. What they expected was to bit mask the 1s place in the integer and check for equality with 0.
Wait, it gets better. I was asked the "divisible by two" question and gave the standard bitmasking technique in response. But then my interviewer said that wasn't "allowed" either, because apparently this programming environment they do their daily work in (this was an old-school web development shop basically) doesn't support basic math operations of any kind except equality, plus and minus.
He then pressed me for something "even simpler", "perhaps using function calls". Then I figured out what the "right" answer was -- he wanted be to test for odd- or even-ness recursively by, well, you know how.
So after reminding him about the obvious performance drawbacks of such an approach, I asked him -- "So do you actually write code like this in production?"
To which his answer was: "No, but I do during interviews".
come on. this is so obvious. read an int at that location and see if you take a misaligned read fault. so easy.
if CPU masks it then time the read.
ok partly sarcasm but partly: this isn’t a hard question. i’m sure i could enumerate ALL the possible ways to do this. maybe i’m good at puzzles.
if your comment is about how awful an interview question it is, in that case yeah i agree. but not because it’s hard. anyone should be able to answer this.
I never said it was hard. I was pointing out that people have been asking easy screener type questions like fizzbuzz for at least 10 years.
Further I was pointing out I prefer fizzbuzz because it at least bears a resemblance to what would be done on a daily basis on the job.
> anyone should be able to answer this.
Anyone should be able to answer fizzbuzz yet people who look good on paper constantly fail it. This is why it is useful. And that is why it is actually not a bad interview question. (in my opinion)
FizzBuzz is just an icon, of course. And by itself not such a bad filter - even if it's just basically a test of memorization (a lot people actually can't remember a simple trick like that, or can't be bothered to see the importance of it).
The only problem is... at some point the tech industry basically started saying to itself, "That worked pretty well! Now if we can just make our tests 50 times harder the must be... 50 times as good!"
Which explains a lot about the situation we're in now.
> ... can't remember a simple trick like that
What "simple trick"? The original point of FizzBuzz is not to check that the interviewee produces hyper-efficient code that avoids repeating the divisibility checks (or, for that matter, to check that they repeat the divisibility checks and are able to defend why that's simpler). It's to check that they can write down any solution at all (within reason [1]). Doing that doesn't require any tricks; you literally just need to write down the requirements in the form of code. Unless you count for loops as tricks! I know the guy who came up with FizzBuzz [2], and he did so to root people who couldn't code at all, not those who weren't good at coming up with (or memorising) coding tricks. Or, if the "trick" you're talking about is memorising, verbatim, a simple for loop solution to FizzBuzz without understanding it, then that can be countered with small variations of the problem.
I agree that some interviewers pose questions that are too hard, which ending up testing ability to perform in an unrealistic situation more than actual programming competence. Of course this happened before FizzBuzz existed. Similarly some probably set a straightforward FizzBuzz and overanalyse details rather than worrying about whether it works (or worry about silly syntax mistakes, which are perfectly reasonable on a whiteboard).
[1] http://joelgrus.com/2016/05/23/fizz-buzz-in-tensorflow/
[2] https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de...
I guess the parent posters point is you could come up with a question bank of FizzBuzz problems, that candidates can study through to ace through your Imperial exam.
There is generally little substitute for real world experience. Measuring through proxy only goes that far.
In the past one of my bosses said he the most valuable thing to asking someone claiming to know C++ was "How do you make a class member that cannot be accessed outside the class". If you know anything about C++ you know the one word answer, yet many so called programmers can't get that far.
That’s a good idea. I interview programmers and I’m pretty sure some would fail that question. What I don’t get: why put C++ on your resume if you don’t even know the basics?
If I had to guess, it's the "I'll figure it out" mentality. The problem here is, with C++, you probably will NOT figure it out!
I did the bare minimum C++ in my classes. I can write trivial little "code challenge" type things with it. (mostly imperative style, very basic OO) But, ask me anything about Templates, etc, and I'll quickly admit you've gone beyond my knowledge. I'm intrigued at the answer to this question though....
Actually a great programmer will figure C++ out fast enough for most purposes. Templates are weird and hard, but a great programmer can figure them out. However if you don't have a several years of experience you will make mistakes, so I can't hire you as the next go-to expert in the difficult corner cases of C++ that sometimes we can't avoid (though as we move to modern c++14 there are a lot less of them)
If you lie on your resume and I catch you that is an important red flag because I no longer no what else I can trust you on.
I think that's where I was coming from: "if you don't have several years...." I learned enough C++ in school to complete my assignments. But the C++ PRs I've reviewed contain FAR more than those rudimentary basics. When looking at Rust, it brought back some of those memories. (`using` vs `uses`, etc) I'd never DARE say I "know" C++ well enough to be useful.
You've nailed the psychological and intellectual rot at the heart of the tech interviewing craze quite eloquently. Thank you.
Perhaps employers not only want the best coders, but also look for traits that enable some to game the system - like having the willpower and discipline to practice and get good at these types of questions.
Doy.
The point of the post was that they were/are optimizing for the wrong things.
Some people watch "Are you smarter than a 5th grader?" and chuckle when they realize they're not.
A smaller subset of people take it to the next level and (would) hire the 5th grader instead of the adult to do an adult's job.
Life's not a game show, but some (most?) of us forget that when we conduct interviews.
Truer words have never been spoken.
I imagine that the longer you’ve been coding in the real world, the harder it is to justify doing all this studying for interviews to get a similar job, especially if you aren’t motivated by money alone.
Recently interviewed with one of the big ones and they were enamoured with my Swift and iOS dev knowledge but I’m not great with identifying graph questions. After many long internal discussions and even a letter of recommendation they passed/asked me if I was interested in other semi-technical roles at the company. In moments like this my sentiment is ‘take me or leave me’.
It is sad to see the huge divergence between skills required for coding interviews and the skills required to be a good software developer/engineer.
Yes, ironically the better / more experienced I have become as a developer the worse i have become at algorithmic style questions. Why? Because I never use that stuff on the job. I make an effort to avoid complex code by proper database and application design. The only times i have ever needed to implement a sort algorithm are for interviews.
When I design system, I don't do it in an interview time frame. I read the problem, and then go and do other stuff. Part of the design will become clearer to me a couple of days later, when I am cooking dinner or cycling to work - that stuff goes on in the background in my head. It's not an area where I find sharp focus useful, more a case of going through the many options at a slower pace is more useful.
Apparently it's still the best indicator for hiring engineers on large scale. It's proven that there is a big correlation between performing good during an coding interview and performing good during your day-to-day job.
Ofc the coding interview is bad, but it's the best of all available (viable) options.
tbh: most people say it's bad because interviewers focus on the optimal solution or something like that. Most of the time that's incorrect as an interview is literally capturing: "Can the candidate solve a difficult problem and transfer his thoughts into code, while being a nice guy to work with"
disclaimer: I'm doing interviews for a faang company.
"It's proven that there is a big correlation between performing good during an coding interview and performing good during your day-to-day job"*
*citation needed
Unfortunately it's internal. All faang companies spend a lot of time and resources on hiring to make it more fair for everybody and to get signals faster. And nobody internally enjoys doing a lot of coding interviews - it's as frustrating for the interviewer as it is for the candidate.
If there would be an easier way then these companies would definitely use it. A candidate usually has 5-7 interviews (if he is not failing the phone screen), which is 5-7 engineers spending at least 1 hour for the interview + 1 hour for the feedback. I am having 2-5 interviews per week, which means I spend between 4 and 10 hours per week just on hiring. If we could reduce this number we would definitely do it, as it's costing a loooot of money.
To be fair: there is some innovation and traction in those areas, s.t. some candidate s do a coding project at home and then present their solution (to reduce the number of interviews).
Someone who didn't get the job should sue just because if these valuable they will have the data to prove it and then the rest of us can look it up in the court records.
My boss asked HR about this and they said if we want to ask coding questions we need to first give the coding interview and score the results - but not use that to decide to hire or not. Then after two years look at their performance and compare to how they did on the interview.
> And nobody internally enjoys doing a lot of coding interviews
That's true, I recently had an interview and the interviewer was on the phone all the time totally uninterested, barring the first 5 minutes. How do you account for that?
Everybody knows (and as stated in the article) the system can be gamed (by memorizing Leetcode solutions) and I choose not to. If you don't believe me have a look here:
https://www.1point3acres.com/bbs/thread-191077-1-1.html (translate it to English)
(there are a ton of interview experiences and detailed questions and strategies on this site)
There are people who are freaking memorizing behavioral questions!! Surely, the FAANG companies are aware of this?
This what I see happening these days: 1. You have an interview candidate solving questions without memorization
2. You have an interview candidate solving questions with memorization
How are you distinguishing between the two and how do you prevent bias? Bias in all forms, not just the stereotype: white guy hiring another white guy.
Just for context it seems the above user works at Google based on previous comments.
The idea that Google has internal research indicating this wouldn't be surprising to me.
> The idea that Google has internal research indicating this wouldn't be surprising to me.
The problem with internal research on these matters is the nearly total lack of negative examples. Depending on the quality of the pre-on-site screening the quality of candidates at that point might be so high that random selection might be just as good.
A negative example would be someone who scored good within the interview process, but then performs bad on the job (bad performance rating). Such examples get discussed internally by the hiring committee (senior people doing the last hiring decision for every candidate).
I think the biggest issue with the current approach among faang interviews is that a lot of really good people get filtered out (false negative) - but faang get so many applications that they are ok with this.
And yet, googles previous public comments on the topic are somewhat the reverse - all their interview question except for questions on previous work/experiences were not correlated with "success".
Scare quotes used because knowing how to define success is an even more hairy question that we (industry, humans) dont have a good grasp on either. So any criteria you use might be wrong or a subset of the right (where "wrong" means you would change your conclusion if you saw the bigger picture, which none of us can.)
success criteria is the rating the people get during their performance review which happens twice a year.
Either that or performance reviews have similar problems. 5-7 interviews seems insane to me. Is competition that high to justify that number?
As a candidate I would give you 3 at most. But that would require me to be in the near vicinity.
5-7 interviews? That is more than many people need to form a marriage...
I also saw people having 10 interviews, and then get rejected :,(
8-15 years ago fb/google had 20+ interviews - and reduced the number based on research that after 4 they can predict it really good.
They mention 4 in the article, but that actually means 4 on-site. Before that a candidate usually has to pass a simple recruiter phone screen and a simple coding phone screen.
> *citation needed Yes. Citations would be useful. To me, it seems to make sense intuitively. I'd say that at the very least it is a fair/objective way of ranking candidates. Particularly so if where the ratio of candidates to positions is high.
In order for there to be a big correlation wouldn't they have to have a ton of negative examples? So that would mean they're hiring a bunch of people who "fail" the interviews to see how their performance matches up to someone who passed the interview. I mean, they could do that. That is assuming they hid the results from whoever those failing candidates go to work for or I imagine there'd be a psychological self-fulfilling prophecy of sorts where people always see that person as a "interview-failer" and view all their results in a negative light. Can you speak to whether this is the case at all?
My gut feeling is that they wouldn't do this at all. If you fail, you fail. Not only that, it seems like a legally shit-situation to put yourself in to hire someone who you think is going to fail and then fire them.
My experience is that people who enjoy the “intellectually interesting” types of problems don’t have the stamina or discipline to get past the 80% mark and are easily distracted by the “ooh shiny”.
Disclaimer: doing interviews outside of FAANG and not on the west coast - where the majority of developers are working.
It's become ridiculous actually. I've been developing professionally for over a decade now and the past few times I've had interviews I've had to make sure I spend a few days preparing by brushing up on stuff I hardly use, but know will be asked in the interview.
I get that it's hard to determine someones skill level, and people aren't prepared to spend multiple hours on practical tests (especially when having multiple interviews), but there must be a better way to interview.
I don't get why they don't do something like give you a computer with a terminal, a buggy program, and an internet connection and tell you to make it compile (or whatever the equivalent is for your domain) using whatever resources you want. Even knowing what to search for or what an error means or how to locate the source is actually like 95% of what most companies are even looking for but they're too much of cargo cult kool aid drinkers to realize it.
Funny to read this and look back at a recently downvoted comment https://news.ycombinator.com/item?id=18445332
I should start a bootcamp to help prospective students prepare to attend a bootcamp.
Who is this article aimed at?
> Who is this article aimed at? Presumably at anybody looking to 'crack' the coding interview. Obviously not all of it is going to be relevant for every role but I found some useful things in there. At the very least I think it offers a structured approach on which to model your own preparation.