18 ms·

Cracking the Coding Interview Tutorial

214 points by rvivek 10y ago

anilgulecha 10y ago
Some background on this: http://blog.hackerrank.com/introducing-cracking-the-coding-interview-tutorial-new-study-on-interview-practice/ http://blog.hackerrank.com/introducing-cracking-the-coding-i...
deleted 10y ago
[deleted]
jakebasile 10y ago
If there are separate tutorials for how to "Crack the Coding Interview", maybe coding interviews do not accurately select for coding skill.
- kafkaesq 10y ago
  Exactly. What kind of hiring "bar" is it if all it measures is the motivation (or more specifically: degree of desperation) necessary to pony up for a 30-day cram school... led, not coincidentally, by the very company that's administering your weeder tests?
  - jakebasile 10y ago
    > led ... by the very company that's administering your weeder tests? I actually didn't even notice this conflict of interest. It would line up exactly with how such an awful class of product has gotten so popular. I've been subjected to HackerRank tests before, along with a few competitor's products. They are universally demeaning, insulting, infuriating, and useless as an indicator of skill.
    - blablablame 10y ago
      then do it like I do. Whenever they send you a link to one, don't take it. Explain you are more than happy to talk to an engineer but you won't do some random online test. (or if you want to be mean, take it, answer every question with a variant of 'this is dumb' and then email the company saying they just wasted their money on these systems)
      - fail2fail2ban 10y ago
        I was polite but ended a phone interview recently when they wanted me to code in a Google Document.
        kafkaesq 10y ago
        Good call. The sheer idiocy of expecting people to show off their mad hacking skills in such an obviously crippled environment is just... breathtaking. Especially when the cost of renting a session on one of the services that does offer a full-featured IDE (with vi and emacs modes) is close to zero. But given that it's most likely the result of junior hiring managers giving marching orders to junior engineers (i.e. the people conducting the screening) who just don't know any better than to say "no" to such a silly and insulting request to make of incoming candidates... the depth and reach of this annoying fad becomes less surprising.
        jstimpfle 10y ago
        This is really misguided. As a programmer you should be able to write a few lines of code in a Google Document. On the other hand it would be idiotic to expect people to be able to code in IDE XYZ (whether it has vi and emacs mode or not).
        fail2fail2ban 10y ago
        I've written code for pay for over two decades in a variety of languages and on a variety of platforms. I can say if I don't wish to write code into a Google Document, nothing misguided about that. Someone fresh out of school, maybe, even then, most coders are using an IDE all day or have another window or terminal open so we can do a quick compile sanity check so even for a new coder fresh out of school, this makes no sense.
    - Apocryphon 10y ago
      The College Boardification of software has begun. Arguably it was already here back when companies were hiring based on candidate SAT schools and college pedigrees, this is just a new chapter with sw interviewing platform firms becoming the new Princeton Reviews.
      - kafkaesq 10y ago
        Along with the "Top 20 Startups to Work For in 2017" mentality. As if for the same crop of... for want of a better term... "kids" who had the whole stack-ranking and "human beings are infinitely measurable and weighable" ethos so relentlessly and successfully drilled into them from pre-K up through graduate school -- there's not even a question of jacking up and scaling out that same system out into the professional working sphere. It's just the way universe works. And so of course getting a leg up and "making it" means cramming one's brains out for however many months as necessary in order to graze whatever "bar" they set because... that's just what learning is, right?
- gaylemcd 10y ago
  Oh, totally. If interviews were a perfect science, and perfectly measured ability, then you wouldn't need to prepare for them at all. You're absolutely right there. And if it were 100% about preparation -- if preparation could land anyone any job they wanted -- then the interviews would be mostly worthless (other than perhaps assessing how much work someone is willing to put in). The reality is somewhere in between: Preparation helps someone perform at their best, but it will not land anyone any job they want. This is why tech companies actually encourage preparation -- it reduces the number of good candidates who get rejected. Note that this isn't really unique to coding interviews. People prepare for ALL types of interviews, so it's revealing the same flaw in all of them.
  - jakebasile 10y ago
    In my experience over the past year, programmer interviews are almost all the way towards the "preparation" (learning to interview, not learning to do the job) end of the scale, with a unhealthy doses of sadism and elitism. I've rarely been asked anything that has something meaningful to do with my abilities as an engineer, only demeaning HackerRank style tests that check only for algorithmic academics knowledge, insulting take-home exams that ignore existing code and industry experience, and torturous whiteboard sessions that select for nothing except ability to withstand day-long in-person inquisitions. HackerRank is a symptom of the terrible interview cult that is pervasive in our industry which is so extremely guarded against the fabled false positive hire. It is designed with absolute certainty that no one is qualified for any job unless they are some silly notion of a 10x engineer or "hacker" while claiming there is an engineering shortage. It allows us to opine about how terrible impostor syndrome is while simultaneously engendering it in others through these interview practices. It allows us to write off people with experience who are further out from college (and therefore older) or never even went under the guise of algorithmic knowledge requirements without admitting ageism. As to other industries, I have little direct experience. I know that my friends and family (none of which are in tech) have been on interviews that are humane and conversational as opposed to the inquisition our industry supports. They have all been aghast at what I've been going through.
    - friendlygrammar 10y ago
- parennoob 10y ago
  I have no idea why people who otherwise are against practices like stack ranking think that companies like "Hacker"Rank which assign you a score based on a set of simplistic algorithm are a good idea. If you are a manager and your company uses HackerRank as a hiring filter, I request you to take a good, hard second look at it – specially if you lament that you are unable to find any developers. These companies make bank from both sides (the person interviewing who is cramming on their material, and the employer), and leave out important things like how well you work with teams, how fast you adapt to new frameworks, or how maintainable your code base is. I guess it is no surprise that another of their "featured" blog posts talks in extremely glowing terms about someone for coding for 24 hours without any sleep. (http://blog.hackerrank.com/recap-how-mimino-solved-78-project-euler-problems-in-under-24-hours/ http://blog.hackerrank.com/recap-how-mimino-solved-78-projec...).
  - chezinn 10y ago
    "Make bank from both sides" Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?
    - parennoob 10y ago
      I am sorry -- since Gayle's book of the same name is a product worth ~$30, I assumed there was a paywall at some point behind https://www.hackerrank.com/domains/tutorials/cracking-the-coding-interview https://www.hackerrank.com/domains/tutorials/cracking-the-co... -- I guess I was wrong? It doesn't clearly say on the page that it was, and I don't want to sign up for their product. A slightly weaker version of that argument is that having a vast base of signed-up users and data about their challenges is still making bank out of the efforts of individual users, but clearly not as bad as requiring you to pay for this tutorial.
      - chezinn 10y ago
        Had a look myself. There isn't.
      - jakebasile 10y ago
- achr2 10y ago
  Imagine a world where the interviewers sat a candidate down in the company's typical environment, with a simplified version of their codebase, and asked them to re-implement a small piece of striped-out functionality. Give them a couple of hours, and then allow them to ask questions, explain what they did, where they got stuck, and give their own feedback. Now you know that they understand your environment/stack, and get an actual sense of how they would perform for your company on code that matters. Let them see the actual code you use at the end, and discuss differences, why they made certain choices, and see if they get excited or frustrated with your company's practices (style, systems, conventions).
  - gaylemcd 10y ago
    Yeah, some companies do those (or a slight variation, called pair programming interviews). There are a lot of benefits of those, but also some drawbacks. First, it's much harder to scale in a consistent way. Second, and more importantly, you also evaluate how they code right now, on these specific technologies, not how well they would code with a bit of training. Think about it: There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. But a person with 20 years of experience who knows that technology will perform better in an immediate sense than the new grad. No interviews are perfect.
    - jakebasile 10y ago
      > There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. Citation? How does having fresh recollection of algorithms that you will rarely if ever use outside of interviews make someone a better software engineer?
      - gaylemcd 10y ago
        I didn't say it did. I wasn't saying that new grads are, on average, better than experienced hires. I was just saying that experience is not everything. An experienced hire will outperform a new grad on a "build this project in 3 hours" test. But the new grad might actually be a fundamentally better engineer - they might be smarter, more careful, etc. Given 3 - 6 months of training, the new grad might actually make better technical decisions. Obviously, the reverse can also happen: the experienced hire might be not only more knowledgable, but also smarter, more careful, etc. The problem with the "build a project in 3 hours" test is that it weights experience and knowledge so heavily that you end up eliminating people who could be great, with a little bit of training. Again, a new grad could also be a fundamentally terrible software engineer (there are fundamentally terrible software engineers with experience and with no experience). And in 20 years, they'll be a terrible software engineer with 20 years of knowledge and experience. They might be able to build a 3-hour project better than some smart inexperienced coder but I'd still rather hire the smart inexperienced coder (assuming I have some time to train them). Ultimately, ALL hiring processes are flawed.
blablablame 10y ago
I just turned down an offer after a technical interview. Just after my tech call, I call the hiring manager and said I didn't want to move forward. Technical interviews aren't the problem, is when interviewers already have an answer they want, and if anything strays from it, they just flat out refuse the answer. Sure datastructure X maybe better when getting to a million items, but for most use cases, Y is valid, and when Y is a problem, I can easily google an alternative, but nooooooo, it has to be X from the start because or A B or C. I like being chalenged in a interview, talk about various topics, but if for every question you have, you have one and one answer only, and any other that may fit but isn't on your spreadsheet is wrong, then seriously, F U. Fortunately also talked with other companies that were more sane, but this 'My way or the highway' from pseudo engineers is what is wrong with hiring in tech.
- ProAm 10y ago
  > but this 'My way or the highway' from pseudo engineers Aren't you saying the same thing to them when you decline to move forward? Looks like your both have the same message just relative to your position in the discussion.
  - blablablame 10y ago
    Not really. Im open to discuss any solution to a problem, from the most performant one to the most simple one (code wise) that does the job. When someone says: Maybe you could use a binary tree. and the reply is: No, that is wrong, what you need is X, is a different thing. Beste inverviews I had were always a give an take. I talked algorithms, data structures, etc but never with the interviewer having a one solution answer. Best interview questions are like: Ok, we have this domain problem, what can you do about it? and then spend a couple hours on a whiteboard on a back and forth discussion about it, maybe you get it right, maybe you dont but have another idea, etc.
- swillis16 10y ago
  You may have dodged a bullet because if someone has a "only one answer approach to interviewing" then the inability to see other possible solutions may carry over into their daily work as well.
davidcgl 10y ago
While there are many legitimate criticism of whiteboard-style coding interviews, I have yet to see a convincing alternative that scales well to the size of big companies. Google [1][2], Facebook et al. hire thousands of engineers per year, meaning they conduct at least 10-100k interviews per year. How do you design a process that is consistent, measurable and efficient at that scale? [1] Google gets 2 million resumes a year https://www.fastcompany.com/3044606/hit-the-ground-running/googles-head-of-hr-shares-his-hiring-secrets https://www.fastcompany.com/3044606/hit-the-ground-running/g... [2] Headcount increased from 57,148 to 66,575 between Q2 15 and Q2 16: https://abc.xyz/investor/ https://abc.xyz/investor/
- 8_hours_ago 10y ago
  Give them a computer and some resources. Let them work on a problem for a few hours. Then have a discussion with them about how they approached the problem, any limitations of their implementation, and what they would do if they had more time. I don't see how whiteboard-style coding interviews can scale any better than that approach.
  - daxfohl 10y ago
    The thing I don't like about whiteboard: A solid candidate that has a bug near the top of a function ends up looking sloppy because whiteboards don't have "insert". The same candidate making the same bug at the bottom of the function can just erase a closing brace and continue looking marvelous. It's very arbitrary I think.
    - nitrogen 10y ago
      Possible solution: leave room at the top of the whiteboard and between some lines for erasing and rewriting sections.
      - daxfohl 10y ago
        Another option would be to write the program in BASIC, with line numbers.
yanilkr 10y ago
One size fits all type of interviewing might be bad for your company or team. If you are hiring for short term, you might find someone who can crank the code appealing, but for long term hiring, you want to choose someone who is creative, who has better imagination or at least has a healthy amount of passion for tech ideas. We might have pushed the limits with coding questions. Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not?
- gaylemcd 10y ago
  > Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not? The coding questions are not literally "Can they physically write code or not?" They're evaluating your problem solving skills and coding skills. There is some inconsistency though with someone's performance in coding questions. Someone usually won't bomb one and then do great in another (although they might feel as though they did). But someone might do mediocre and then do pretty well on the others. Asking multiple questions is just getting multiple data points.
  - 1474295912 10y ago
    I wonder what percent of these questions in all the 5 rounds have production level significance? Do people really solve these "Invert a red-black tree" problems regularly at their day jobs? I understand Big4 doing this as they're bombarded by resumés, but the problem starts when mom'n Pop CRuD shops start aping these blindly.
    - collyw 10y ago
      Exactly. The only time I have needed to implement a quick sort was for university exams or interviews. The rest of the time, pick an appropriate library.
    - gaylemcd 10y ago
      No, and people don't really ask that interviews. (Or if they do, they shouldn't.) The point of these questions is basically to assess intelligence (as it relates to coding). It's not about having you solve a specific problem because you might need to solve that exact thing in the real world. You're right though that part of the issue is a bunch of companies trying to replicate the Google process (which might not even be right for their company) -- and then not knowing what it's all about. So they ask super common or really easy problem, which don't even test problem solving skills.
cle 10y ago
Yeah, I don't understand that approach to interviewing. Technical questions are great, but IMO the point isn't to get the right answer. The best technical questions have many "right" answers, depending on the context. And the best interviewees know how to find that "right" answer by analyzing the use cases, customers, clients, etc. to find the best tradeoff. THAT is what I care most about in a technical interview--the ability to handle ambiguity and make the right tradeoffs. Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.
1474295912 10y ago
I wonder if such a scheme would fly in other disciplines of Engineering? Would they hire a person at a Thermal power station, who can dazzle people with fancy Laplace transforms on a white-board? I recently interviewed for a position at a small Amsterdam based company. They simply asked me to work with them and refactor a part of their code base. It was really interesting and frankly, we all had lots of fun during the 3-4 hour process. Coming from the USA, it was eye opening to see the ingenuity of this simple way to determine candidates ability. It's such a shame that Stack ranking like HackerRank are being favoured instead of on-job evaluation.
- hartator 10y ago
  This is the Amsterdam startup scene, basically an extension of the US startup scene where you can smoke weed. Try France, Spain or Italy that truly have a different culture for tech things, I am not sure if you will like it.
  - plandis 10y ago
    It's probably pretty easy to obtain pot in SF. Definitely easy in Seattle if you're over 21.
  - 1474295912 10y ago
    Ignoring your snark, I had the similar experience at a Salzburg and Berlin based company. On the other hand there were many companies (Zalando, ProhectA etc) which were copying the shitty model of useless programming puzzles.
- mahyarm 10y ago
  Cracking the coding interview trains you for one interview type. Many places do multiple interview types: 1. Coding challenge <- Your interview was mostly this. - Make an object - Make a mini-app - Fix this code - Refactor this thing 2. Design a program on a whiteboard 3. Algorithmic & Data Structures <- Cracking the coding interview helps here, and is the type many engineers struggle with. 4. Hiring manager interview <- the most subjective People also will bring up if you're an asshole in any of the above interviews.
ktRolster 10y ago
Google recruiters tell candidates to buy this book to pass the interview. It drives the interviewers crazy. Clearly there is some friction between interviewers and recruiters at Google, incentives aren't quite aligned.
- serge2k 10y ago
  One set wants to get people hired, the other wants to prove how smart they are by rejecting as many as possible?
  - gwbas1c 10y ago
    It's very hard to evaluate a candidate if they know the answer(s) coming in.
    - vonmoltke 10y ago
      Which is why you shouldn't be asking questions that have specific answers.
- Lewisham 10y ago
  Where did you get the idea it drives interviewers crazy? a) I shouldn't ask questions that are in that book, any question found in the wild is banned. b) I want my candidates to study and show me the best of themselves, and that they want the job and are not wasting my time by throwing their resume on the pile as an afterthought. c) Cracking the Code Interview is really good at helping you through the algorithmic questions popular on whiteboards. I find the signal:noise ratio on those questions pretty poor, so I ask more straightforward questions that more closely represent things a software engineer encounters in their everyday life. CtCI is good for getting you up to snuff at the stuff you don't do all the time (if ever) just in case you get That Interviewer. Admittedly, I am but one interviewer and there are many others who do many things many different ways, but I've never heard anyone denounce candidates studying.
- gaylemcd 10y ago
  Yeah... Where did you get the idea that it drives the interviewers crazy? While I'm sure there are interviewers who are opposed to preparation, mostly interviewers support this.
bogomipz 10y ago
Are there plans to add more questions from the book? Are the Editorials generally approved by the author of the book?
lsjroberts 10y ago
We've been running a very effective initial filter coding interview that simply tests the very basic ability to write loops, refactoring and a little recursion. It's astonishing how many people with CVs of 5+ years professional contract experience in London fail this test. We've had a <15% pass rate on that test alone. Personally I'm not a fan of taking these interviews, but now being involved on the other side I've seen how essential it to filter out those who don't actually understand how to code.
- danieltillett 10y ago
  Have you looked into why these people fail? I see all the time claims made like this (i.e. that a large percentage of programmers fail fizz-buzz type questions), but I never see why. Are they morons, frauds, frazzled, confused?
  - lsjroberts 10y ago
    Of the 6 tests I've personally run, 1 passed decently, 2 were probably affected by nerves, 3 just weren't capable. We've had >30 people come in so far and offered to 3 or 4 I believe. The test is essentially writing a function that can take any number of numbers and add them together followed by a couple of bits around javascript's built in functions and object syntax. 1 of the failures couldn't write a for loop despite having 5 years experience including React. The test also works as a general personality test as we need people who are fully confident in their abilities due to the difficultly and scale of the product. We are specifically aiming for the top 20% of candidates who come in, so there are subsequent tests after this one. I thought I'd be able to spot a bad CV, but it turns out either people are lying or they are crediting other people's work to themselves when they are able to hide amongst the team at large organisations.
    - ionwake 10y ago
      Did you look at any of their portfolios? Were they taken into account?
smnscu 10y ago
I have the paperback and I've been following her for a long time (she's very active on Quora but I quit that site long ago). I think if you're a moderately good programmer looking for a job at the big four you only need to read Cracking the Coding Interview, maybe aosabook.org, and solve all medium problems on leetcode. This course is just the right thing to get me to actually start preparing for my upcoming Google interview.
collyw 10y ago
"According to our data, developers with at least two years of experience, who practiced even just a little (20 challenges) increased their chances of getting an onsite interview by 50 percent". Last time I looked at hackerrank, they were 90 minutes long. So I am expected to do nearly a full weeks work to interview with some companies. Thats why I refused last time Skyscanner asked me to do this (actually they have asked me 3 times! Before I even get to speak to anyone technical). Plus the platform is frustrating to use - I don't my write code in a web browser. I use an IDE step through debugger especially for the algorithmic style stuff that's on there. I don't particularly like writing code in a rush, as it leads to poorer quality code.
- djsumdog 10y ago
  I refuse to take these tests today. Let's have a conversation, break down a problem, look at on a white board. If you want me to take your fucked up bullshit coding test, pay me my contracting rate for it. I hate these things. They're shit.
  - chad_strategic 10y ago
    I can't up vote this comment enough. I stopped taking code tests waste of my time and money.
- eikenberry 10y ago
  I don't think they mean the tests, just the challenges. I whipped though 80-90 of them (bash and python) in a couple days.
- mattnewton 10y ago
  They are debating over whether or not to pay you 150-250k a year and you're upset over a weeks worth of effort? I'll put in a week's worth of effort for decent shot at a salary increase every single time I have the opportunity.
  - collyw 10y ago
    They are debating whether or not to interview me.
deleted 10y ago
[deleted]
chad_strategic 10y ago
I just took a hacker rank test let me know if you the questions and answers to there stupid test. 2 1/2 hours gone from my life. #neveragain
deleted 10y ago
[deleted]
ChrisAntaki 10y ago
Thank you, Gayle & HackerRank! Recently, with help from Cracking the Coding Interview and HackerRank, I was able to pass some fun yet challenging technical screens with Google, Facebook, and Uber.
- jedmeyers 10y ago
  > Recently, with help from Cracking the Coding Interview and HackerRank, I was able to pass some fun yet challenging technical screens with Google, Facebook, and Uber. How challenging were the actual screens compared to the CtCI practice problems on Hacker Rank?
  - ChrisAntaki 10y ago
    Pretty close. They'd present a problem, then expand on it. The problems would keep evolving, so that kept it engaging. Then at a certain point, they'd say we're done, we're about out of time, etc - and we'd have a few minutes to chat about life, technology, etc.
user5994461 10y ago
There is no article. It's just disguised advertising which is asking for you to register on their website. If you really want to crack the HackerRank test, read this instead: https://thehftguy.wordpress.com/2016/07/13/cracking-the-hackerrank-test-google-to-the-rescue/ https://thehftguy.wordpress.com/2016/07/13/cracking-the-hack...
- anilgulecha 10y ago
  FYI.. Googling for answers is a bad idea. We have a built in plagiarism detector which will flag your report to the recruiter.
segmondy 10y ago
I interview plenty and I've moved away from technical questions and puzzles. We have a conversion, and talk about programming. I ask scenario based questions and just see how they think and will solve it. i.e You have a program, it's running slow, how do you debug it. You find that the slow part has a query, how do you debug it? So you check the table, it has indexes, as a matter of fact, it has index on all 10 columns and the insert is slow as hell, what now? What's your opinion on OOP vs procedural? or OOP vs functional? Two developers come to you with various idea, idea A and B, which will you pick why? What do you think is the pros and cons of A and B? This is very revealing.
- GreatPowers 10y ago
  Those type of interviews have been the most enjoyable. Having to code a function to do a very specific thing while also having to come up with the algorithm with strict requirements in a half hour while the interviewer watches over your shoulder are the worst. And then having to repeat that for 4+ more interviewers just isn't worth it to me anymore. I did an interview at Fitbit where I did a phone interview with the manager who asked me algorithmic questions, then I had to write a program and make it optimized and pretty which took about a day to write, then I had to do about a 4-5 hour interview on site where I was drilled by about 8-10 different people 2 at a time to write code on a whiteboard. After all that and taking off work to do it I didn't get an offer saying my experience doesn't match up with what they are looking for. It was after that I realized I'm not going to go through all that bullshit anymore.
eternalban 10y ago
Industry requiring professional level resources is having a very hard time coming up with a sane method for screening candidates not screened by professional degree programs. (-> taking the ad hoc Bar exam, again, and again.)
throwaway896 10y ago
I've been programming for 24 years (12 professionally). I've worked in startups, BigCo, and Facebook. I've been a jr. dev, lead, E4, E5, E6, EM, and VP. I've worked in the capacity of a PE, SWE, Front-end, Back-end, Data Engineer, and Data Scientist. I've worked with various clients such as: web, android, ios, tv, playstation, mac, and windows. I've been interviewed a dozen times, and have always been given an offer. I've been an interviewer throughout my career, and have conducted interviews at each company. I'm now in a place where I've made my money, and now I'm set to move outside of the Valley. Given that I'll be near Irvine, I thought it might be fun to see what Google is up to. Completely ignoring my history, this is what I'm told I have to prepare for when I come onsite: - Be ready to talk about complex algorithms like Dijkstra and A* - Be comfortable with sorting and efficiency (be comfortable knowing when insertion sort, radix sort, quick sort, merge sort, heap sort - Be aware of discrete math solutions and know probability theory, combinatorics, n choose k, etc.. - Know all data structures and what algorithms tend to go with them - Know graph algorithms and structures, their representations, and how to traverse them - Be comfortable with recursion and how to think recursively - Know OS concepts like processes, threads, concurrency issues, locks, mutexes, semaphores, monitors, etc.. So, to join the "best of the best", I have to brush up on all of these concepts (again) enough to answer random questions from random interviewers for 5 hours. Also, I'll need to do it in one of the preferred languages... on a whiteboard... and be syntactically correct. Oh yeah, I'll also need to talk through my thought process the entire time, and explain the tradeoffs, time complexity, space complexity, alternative paths, etc... I'll also need to show a go-getter attitude and not get flustered while the interviewer "pushes" me in various ways. I'll also need to build a rapport with half a dozen different people with various personalities, quirks, and moods. If it involves lunch, I'll need to pay attention to what I eat, how I eat, what I chit chat about, what the temperature is (am I sweating, am I dressed the same), etc.. Depending upon the type of work being performed, I'll need to show good "excitement" for the product, be it ads, games, VR, AR, etc... I'll need to show intelligence, but not be abstract. I'll need to think through problems very quickly, but also be thorough and not make mistakes. Do you have any idea how long it takes to prepare for this? Do you realize how taxing it is on your life? I'm an introvert... this stuff destroys me for weeks. ...and this is from someone who has a 100% success rate, and already knows all of the answers! The sad part in all of this, is that it doesn't actually work. You've made your candidates go through this awful gauntlet, and your people are no better than any other company. You still have great people that leave, bad people that stay, bad solutions to easy problems, features that shouldn't be built, genius developers that can't communicate, teammates that won't stop talking, managers that make your life hell, managers that are amazing, problems that excite people, problems that bore people, etc... There's no difference, and that's why it's tiring. Would you like to know the absolute worst project you could ever work on as a developer? It's one that takes a lot of time, work, thinking, personal interaction, consumes personal time, requires ridiculous scrutiny, needs to be perfect the first time, and wether or not it succeeds or not, it is trashed as soon as you're done with it. That's our interview process. That's what we're making thousands of good people do, every single day.

214 points by rvivek 10y ago

Some background on this: http://blog.hackerrank.com/introducing-cracking-the-coding-interview-tutorial-new-study-on-interview-practice/ http://blog.hackerrank.com/introducing-cracking-the-coding-i...

deleted 10y ago

[deleted]

jakebasile 10y ago

If there are separate tutorials for how to "Crack the Coding Interview", maybe coding interviews do not accurately select for coding skill.

kafkaesq 10y ago
Exactly. What kind of hiring "bar" is it if all it measures is the motivation (or more specifically: degree of desperation) necessary to pony up for a 30-day cram school... led, not coincidentally, by the very company that's administering your weeder tests?
- jakebasile 10y ago
  > led ... by the very company that's administering your weeder tests? I actually didn't even notice this conflict of interest. It would line up exactly with how such an awful class of product has gotten so popular. I've been subjected to HackerRank tests before, along with a few competitor's products. They are universally demeaning, insulting, infuriating, and useless as an indicator of skill.
  - blablablame 10y ago
    then do it like I do. Whenever they send you a link to one, don't take it. Explain you are more than happy to talk to an engineer but you won't do some random online test. (or if you want to be mean, take it, answer every question with a variant of 'this is dumb' and then email the company saying they just wasted their money on these systems)
    - fail2fail2ban 10y ago
      I was polite but ended a phone interview recently when they wanted me to code in a Google Document.
      - kafkaesq 10y ago
        Good call. The sheer idiocy of expecting people to show off their mad hacking skills in such an obviously crippled environment is just... breathtaking. Especially when the cost of renting a session on one of the services that does offer a full-featured IDE (with vi and emacs modes) is close to zero. But given that it's most likely the result of junior hiring managers giving marching orders to junior engineers (i.e. the people conducting the screening) who just don't know any better than to say "no" to such a silly and insulting request to make of incoming candidates... the depth and reach of this annoying fad becomes less surprising.
        jstimpfle 10y ago
        This is really misguided. As a programmer you should be able to write a few lines of code in a Google Document. On the other hand it would be idiotic to expect people to be able to code in IDE XYZ (whether it has vi and emacs mode or not).
        fail2fail2ban 10y ago
        I've written code for pay for over two decades in a variety of languages and on a variety of platforms. I can say if I don't wish to write code into a Google Document, nothing misguided about that. Someone fresh out of school, maybe, even then, most coders are using an IDE all day or have another window or terminal open so we can do a quick compile sanity check so even for a new coder fresh out of school, this makes no sense.
  - Apocryphon 10y ago
    The College Boardification of software has begun. Arguably it was already here back when companies were hiring based on candidate SAT schools and college pedigrees, this is just a new chapter with sw interviewing platform firms becoming the new Princeton Reviews.
    - kafkaesq 10y ago
      Along with the "Top 20 Startups to Work For in 2017" mentality. As if for the same crop of... for want of a better term... "kids" who had the whole stack-ranking and "human beings are infinitely measurable and weighable" ethos so relentlessly and successfully drilled into them from pre-K up through graduate school -- there's not even a question of jacking up and scaling out that same system out into the professional working sphere. It's just the way universe works. And so of course getting a leg up and "making it" means cramming one's brains out for however many months as necessary in order to graze whatever "bar" they set because... that's just what learning is, right?
gaylemcd 10y ago
Oh, totally. If interviews were a perfect science, and perfectly measured ability, then you wouldn't need to prepare for them at all. You're absolutely right there. And if it were 100% about preparation -- if preparation could land anyone any job they wanted -- then the interviews would be mostly worthless (other than perhaps assessing how much work someone is willing to put in). The reality is somewhere in between: Preparation helps someone perform at their best, but it will not land anyone any job they want. This is why tech companies actually encourage preparation -- it reduces the number of good candidates who get rejected. Note that this isn't really unique to coding interviews. People prepare for ALL types of interviews, so it's revealing the same flaw in all of them.
- jakebasile 10y ago
  In my experience over the past year, programmer interviews are almost all the way towards the "preparation" (learning to interview, not learning to do the job) end of the scale, with a unhealthy doses of sadism and elitism. I've rarely been asked anything that has something meaningful to do with my abilities as an engineer, only demeaning HackerRank style tests that check only for algorithmic academics knowledge, insulting take-home exams that ignore existing code and industry experience, and torturous whiteboard sessions that select for nothing except ability to withstand day-long in-person inquisitions. HackerRank is a symptom of the terrible interview cult that is pervasive in our industry which is so extremely guarded against the fabled false positive hire. It is designed with absolute certainty that no one is qualified for any job unless they are some silly notion of a 10x engineer or "hacker" while claiming there is an engineering shortage. It allows us to opine about how terrible impostor syndrome is while simultaneously engendering it in others through these interview practices. It allows us to write off people with experience who are further out from college (and therefore older) or never even went under the guise of algorithmic knowledge requirements without admitting ageism. As to other industries, I have little direct experience. I know that my friends and family (none of which are in tech) have been on interviews that are humane and conversational as opposed to the inquisition our industry supports. They have all been aghast at what I've been going through.
  - friendlygrammar 10y ago
parennoob 10y ago
I have no idea why people who otherwise are against practices like stack ranking think that companies like "Hacker"Rank which assign you a score based on a set of simplistic algorithm are a good idea. If you are a manager and your company uses HackerRank as a hiring filter, I request you to take a good, hard second look at it – specially if you lament that you are unable to find any developers. These companies make bank from both sides (the person interviewing who is cramming on their material, and the employer), and leave out important things like how well you work with teams, how fast you adapt to new frameworks, or how maintainable your code base is. I guess it is no surprise that another of their "featured" blog posts talks in extremely glowing terms about someone for coding for 24 hours without any sleep. (http://blog.hackerrank.com/recap-how-mimino-solved-78-project-euler-problems-in-under-24-hours/ http://blog.hackerrank.com/recap-how-mimino-solved-78-projec...).
- chezinn 10y ago
  "Make bank from both sides" Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?
  - parennoob 10y ago
    I am sorry -- since Gayle's book of the same name is a product worth ~$30, I assumed there was a paywall at some point behind https://www.hackerrank.com/domains/tutorials/cracking-the-coding-interview https://www.hackerrank.com/domains/tutorials/cracking-the-co... -- I guess I was wrong? It doesn't clearly say on the page that it was, and I don't want to sign up for their product. A slightly weaker version of that argument is that having a vast base of signed-up users and data about their challenges is still making bank out of the efforts of individual users, but clearly not as bad as requiring you to pay for this tutorial.
    - chezinn 10y ago
      Had a look myself. There isn't.
    - jakebasile 10y ago
achr2 10y ago
Imagine a world where the interviewers sat a candidate down in the company's typical environment, with a simplified version of their codebase, and asked them to re-implement a small piece of striped-out functionality. Give them a couple of hours, and then allow them to ask questions, explain what they did, where they got stuck, and give their own feedback. Now you know that they understand your environment/stack, and get an actual sense of how they would perform for your company on code that matters. Let them see the actual code you use at the end, and discuss differences, why they made certain choices, and see if they get excited or frustrated with your company's practices (style, systems, conventions).
- gaylemcd 10y ago
  Yeah, some companies do those (or a slight variation, called pair programming interviews). There are a lot of benefits of those, but also some drawbacks. First, it's much harder to scale in a consistent way. Second, and more importantly, you also evaluate how they code right now, on these specific technologies, not how well they would code with a bit of training. Think about it: There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. But a person with 20 years of experience who knows that technology will perform better in an immediate sense than the new grad. No interviews are perfect.
  - jakebasile 10y ago
    > There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. Citation? How does having fresh recollection of algorithms that you will rarely if ever use outside of interviews make someone a better software engineer?
    - gaylemcd 10y ago
      I didn't say it did. I wasn't saying that new grads are, on average, better than experienced hires. I was just saying that experience is not everything. An experienced hire will outperform a new grad on a "build this project in 3 hours" test. But the new grad might actually be a fundamentally better engineer - they might be smarter, more careful, etc. Given 3 - 6 months of training, the new grad might actually make better technical decisions. Obviously, the reverse can also happen: the experienced hire might be not only more knowledgable, but also smarter, more careful, etc. The problem with the "build a project in 3 hours" test is that it weights experience and knowledge so heavily that you end up eliminating people who could be great, with a little bit of training. Again, a new grad could also be a fundamentally terrible software engineer (there are fundamentally terrible software engineers with experience and with no experience). And in 20 years, they'll be a terrible software engineer with 20 years of knowledge and experience. They might be able to build a 3-hour project better than some smart inexperienced coder but I'd still rather hire the smart inexperienced coder (assuming I have some time to train them). Ultimately, ALL hiring processes are flawed.

blablablame 10y ago

I just turned down an offer after a technical interview. Just after my tech call, I call the hiring manager and said I didn't want to move forward. Technical interviews aren't the problem, is when interviewers already have an answer they want, and if anything strays from it, they just flat out refuse the answer. Sure datastructure X maybe better when getting to a million items, but for most use cases, Y is valid, and when Y is a problem, I can easily google an alternative, but nooooooo, it has to be X from the start because or A B or C. I like being chalenged in a interview, talk about various topics, but if for every question you have, you have one and one answer only, and any other that may fit but isn't on your spreadsheet is wrong, then seriously, F U. Fortunately also talked with other companies that were more sane, but this 'My way or the highway' from pseudo engineers is what is wrong with hiring in tech.

ProAm 10y ago
> but this 'My way or the highway' from pseudo engineers Aren't you saying the same thing to them when you decline to move forward? Looks like your both have the same message just relative to your position in the discussion.
- blablablame 10y ago
  Not really. Im open to discuss any solution to a problem, from the most performant one to the most simple one (code wise) that does the job. When someone says: Maybe you could use a binary tree. and the reply is: No, that is wrong, what you need is X, is a different thing. Beste inverviews I had were always a give an take. I talked algorithms, data structures, etc but never with the interviewer having a one solution answer. Best interview questions are like: Ok, we have this domain problem, what can you do about it? and then spend a couple hours on a whiteboard on a back and forth discussion about it, maybe you get it right, maybe you dont but have another idea, etc.
swillis16 10y ago
You may have dodged a bullet because if someone has a "only one answer approach to interviewing" then the inability to see other possible solutions may carry over into their daily work as well.

davidcgl 10y ago

While there are many legitimate criticism of whiteboard-style coding interviews, I have yet to see a convincing alternative that scales well to the size of big companies. Google [1][2], Facebook et al. hire thousands of engineers per year, meaning they conduct at least 10-100k interviews per year. How do you design a process that is consistent, measurable and efficient at that scale? [1] Google gets 2 million resumes a year https://www.fastcompany.com/3044606/hit-the-ground-running/googles-head-of-hr-shares-his-hiring-secrets https://www.fastcompany.com/3044606/hit-the-ground-running/g... [2] Headcount increased from 57,148 to 66,575 between Q2 15 and Q2 16: https://abc.xyz/investor/ https://abc.xyz/investor/

8_hours_ago 10y ago
Give them a computer and some resources. Let them work on a problem for a few hours. Then have a discussion with them about how they approached the problem, any limitations of their implementation, and what they would do if they had more time. I don't see how whiteboard-style coding interviews can scale any better than that approach.
- daxfohl 10y ago
  The thing I don't like about whiteboard: A solid candidate that has a bug near the top of a function ends up looking sloppy because whiteboards don't have "insert". The same candidate making the same bug at the bottom of the function can just erase a closing brace and continue looking marvelous. It's very arbitrary I think.
  - nitrogen 10y ago
    Possible solution: leave room at the top of the whiteboard and between some lines for erasing and rewriting sections.
    - daxfohl 10y ago
      Another option would be to write the program in BASIC, with line numbers.

yanilkr 10y ago

One size fits all type of interviewing might be bad for your company or team. If you are hiring for short term, you might find someone who can crank the code appealing, but for long term hiring, you want to choose someone who is creative, who has better imagination or at least has a healthy amount of passion for tech ideas. We might have pushed the limits with coding questions. Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not?

gaylemcd 10y ago
> Why do you need 5 coding rounds? does one programming problem not clarify if this person can code or not? The coding questions are not literally "Can they physically write code or not?" They're evaluating your problem solving skills and coding skills. There is some inconsistency though with someone's performance in coding questions. Someone usually won't bomb one and then do great in another (although they might feel as though they did). But someone might do mediocre and then do pretty well on the others. Asking multiple questions is just getting multiple data points.
- 1474295912 10y ago
  I wonder what percent of these questions in all the 5 rounds have production level significance? Do people really solve these "Invert a red-black tree" problems regularly at their day jobs? I understand Big4 doing this as they're bombarded by resumés, but the problem starts when mom'n Pop CRuD shops start aping these blindly.
  - collyw 10y ago
    Exactly. The only time I have needed to implement a quick sort was for university exams or interviews. The rest of the time, pick an appropriate library.
  - gaylemcd 10y ago
    No, and people don't really ask that interviews. (Or if they do, they shouldn't.) The point of these questions is basically to assess intelligence (as it relates to coding). It's not about having you solve a specific problem because you might need to solve that exact thing in the real world. You're right though that part of the issue is a bunch of companies trying to replicate the Google process (which might not even be right for their company) -- and then not knowing what it's all about. So they ask super common or really easy problem, which don't even test problem solving skills.

cle 10y ago

Yeah, I don't understand that approach to interviewing. Technical questions are great, but IMO the point isn't to get the right answer. The best technical questions have many "right" answers, depending on the context. And the best interviewees know how to find that "right" answer by analyzing the use cases, customers, clients, etc. to find the best tradeoff. THAT is what I care most about in a technical interview--the ability to handle ambiguity and make the right tradeoffs. Technical chops are a prerequisite, of course, but they're useless if the candidate doesn't make the right tradeoffs and technical decisions.

1474295912 10y ago

I wonder if such a scheme would fly in other disciplines of Engineering? Would they hire a person at a Thermal power station, who can dazzle people with fancy Laplace transforms on a white-board? I recently interviewed for a position at a small Amsterdam based company. They simply asked me to work with them and refactor a part of their code base. It was really interesting and frankly, we all had lots of fun during the 3-4 hour process. Coming from the USA, it was eye opening to see the ingenuity of this simple way to determine candidates ability. It's such a shame that Stack ranking like HackerRank are being favoured instead of on-job evaluation.

hartator 10y ago
This is the Amsterdam startup scene, basically an extension of the US startup scene where you can smoke weed. Try France, Spain or Italy that truly have a different culture for tech things, I am not sure if you will like it.
- plandis 10y ago
  It's probably pretty easy to obtain pot in SF. Definitely easy in Seattle if you're over 21.
- 1474295912 10y ago
  Ignoring your snark, I had the similar experience at a Salzburg and Berlin based company. On the other hand there were many companies (Zalando, ProhectA etc) which were copying the shitty model of useless programming puzzles.
mahyarm 10y ago
Cracking the coding interview trains you for one interview type. Many places do multiple interview types: 1. Coding challenge <- Your interview was mostly this. - Make an object - Make a mini-app - Fix this code - Refactor this thing 2. Design a program on a whiteboard 3. Algorithmic & Data Structures <- Cracking the coding interview helps here, and is the type many engineers struggle with. 4. Hiring manager interview <- the most subjective People also will bring up if you're an asshole in any of the above interviews.

ktRolster 10y ago

Google recruiters tell candidates to buy this book to pass the interview. It drives the interviewers crazy. Clearly there is some friction between interviewers and recruiters at Google, incentives aren't quite aligned.

serge2k 10y ago
One set wants to get people hired, the other wants to prove how smart they are by rejecting as many as possible?
- gwbas1c 10y ago
  It's very hard to evaluate a candidate if they know the answer(s) coming in.
  - vonmoltke 10y ago
    Which is why you shouldn't be asking questions that have specific answers.
Lewisham 10y ago
Where did you get the idea it drives interviewers crazy? a) I shouldn't ask questions that are in that book, any question found in the wild is banned. b) I want my candidates to study and show me the best of themselves, and that they want the job and are not wasting my time by throwing their resume on the pile as an afterthought. c) Cracking the Code Interview is really good at helping you through the algorithmic questions popular on whiteboards. I find the signal:noise ratio on those questions pretty poor, so I ask more straightforward questions that more closely represent things a software engineer encounters in their everyday life. CtCI is good for getting you up to snuff at the stuff you don't do all the time (if ever) just in case you get That Interviewer. Admittedly, I am but one interviewer and there are many others who do many things many different ways, but I've never heard anyone denounce candidates studying.
gaylemcd 10y ago
Yeah... Where did you get the idea that it drives the interviewers crazy? While I'm sure there are interviewers who are opposed to preparation, mostly interviewers support this.

bogomipz 10y ago

Are there plans to add more questions from the book? Are the Editorials generally approved by the author of the book?

lsjroberts 10y ago

We've been running a very effective initial filter coding interview that simply tests the very basic ability to write loops, refactoring and a little recursion. It's astonishing how many people with CVs of 5+ years professional contract experience in London fail this test. We've had a <15% pass rate on that test alone. Personally I'm not a fan of taking these interviews, but now being involved on the other side I've seen how essential it to filter out those who don't actually understand how to code.

danieltillett 10y ago
Have you looked into why these people fail? I see all the time claims made like this (i.e. that a large percentage of programmers fail fizz-buzz type questions), but I never see why. Are they morons, frauds, frazzled, confused?
- lsjroberts 10y ago
  Of the 6 tests I've personally run, 1 passed decently, 2 were probably affected by nerves, 3 just weren't capable. We've had >30 people come in so far and offered to 3 or 4 I believe. The test is essentially writing a function that can take any number of numbers and add them together followed by a couple of bits around javascript's built in functions and object syntax. 1 of the failures couldn't write a for loop despite having 5 years experience including React. The test also works as a general personality test as we need people who are fully confident in their abilities due to the difficultly and scale of the product. We are specifically aiming for the top 20% of candidates who come in, so there are subsequent tests after this one. I thought I'd be able to spot a bad CV, but it turns out either people are lying or they are crediting other people's work to themselves when they are able to hide amongst the team at large organisations.
  - ionwake 10y ago
    Did you look at any of their portfolios? Were they taken into account?

smnscu 10y ago

I have the paperback and I've been following her for a long time (she's very active on Quora but I quit that site long ago). I think if you're a moderately good programmer looking for a job at the big four you only need to read Cracking the Coding Interview, maybe aosabook.org, and solve all medium problems on leetcode. This course is just the right thing to get me to actually start preparing for my upcoming Google interview.

collyw 10y ago

"According to our data, developers with at least two years of experience, who practiced even just a little (20 challenges) increased their chances of getting an onsite interview by 50 percent". Last time I looked at hackerrank, they were 90 minutes long. So I am expected to do nearly a full weeks work to interview with some companies. Thats why I refused last time Skyscanner asked me to do this (actually they have asked me 3 times! Before I even get to speak to anyone technical). Plus the platform is frustrating to use - I don't my write code in a web browser. I use an IDE step through debugger especially for the algorithmic style stuff that's on there. I don't particularly like writing code in a rush, as it leads to poorer quality code.

djsumdog 10y ago
I refuse to take these tests today. Let's have a conversation, break down a problem, look at on a white board. If you want me to take your fucked up bullshit coding test, pay me my contracting rate for it. I hate these things. They're shit.
- chad_strategic 10y ago
  I can't up vote this comment enough. I stopped taking code tests waste of my time and money.
eikenberry 10y ago
I don't think they mean the tests, just the challenges. I whipped though 80-90 of them (bash and python) in a couple days.
mattnewton 10y ago
They are debating over whether or not to pay you 150-250k a year and you're upset over a weeks worth of effort? I'll put in a week's worth of effort for decent shot at a salary increase every single time I have the opportunity.
- collyw 10y ago
  They are debating whether or not to interview me.

deleted 10y ago

[deleted]

chad_strategic 10y ago

I just took a hacker rank test let me know if you the questions and answers to there stupid test. 2 1/2 hours gone from my life. #neveragain

deleted 10y ago

[deleted]

ChrisAntaki 10y ago

Thank you, Gayle & HackerRank! Recently, with help from Cracking the Coding Interview and HackerRank, I was able to pass some fun yet challenging technical screens with Google, Facebook, and Uber.

jedmeyers 10y ago
> Recently, with help from Cracking the Coding Interview and HackerRank, I was able to pass some fun yet challenging technical screens with Google, Facebook, and Uber. How challenging were the actual screens compared to the CtCI practice problems on Hacker Rank?
- ChrisAntaki 10y ago
  Pretty close. They'd present a problem, then expand on it. The problems would keep evolving, so that kept it engaging. Then at a certain point, they'd say we're done, we're about out of time, etc - and we'd have a few minutes to chat about life, technology, etc.

user5994461 10y ago

There is no article. It's just disguised advertising which is asking for you to register on their website. If you really want to crack the HackerRank test, read this instead: https://thehftguy.wordpress.com/2016/07/13/cracking-the-hackerrank-test-google-to-the-rescue/ https://thehftguy.wordpress.com/2016/07/13/cracking-the-hack...

anilgulecha 10y ago
FYI.. Googling for answers is a bad idea. We have a built in plagiarism detector which will flag your report to the recruiter.

segmondy 10y ago

I interview plenty and I've moved away from technical questions and puzzles. We have a conversion, and talk about programming. I ask scenario based questions and just see how they think and will solve it. i.e You have a program, it's running slow, how do you debug it. You find that the slow part has a query, how do you debug it? So you check the table, it has indexes, as a matter of fact, it has index on all 10 columns and the insert is slow as hell, what now? What's your opinion on OOP vs procedural? or OOP vs functional? Two developers come to you with various idea, idea A and B, which will you pick why? What do you think is the pros and cons of A and B? This is very revealing.

GreatPowers 10y ago
Those type of interviews have been the most enjoyable. Having to code a function to do a very specific thing while also having to come up with the algorithm with strict requirements in a half hour while the interviewer watches over your shoulder are the worst. And then having to repeat that for 4+ more interviewers just isn't worth it to me anymore. I did an interview at Fitbit where I did a phone interview with the manager who asked me algorithmic questions, then I had to write a program and make it optimized and pretty which took about a day to write, then I had to do about a 4-5 hour interview on site where I was drilled by about 8-10 different people 2 at a time to write code on a whiteboard. After all that and taking off work to do it I didn't get an offer saying my experience doesn't match up with what they are looking for. It was after that I realized I'm not going to go through all that bullshit anymore.

eternalban 10y ago

Industry requiring professional level resources is having a very hard time coming up with a sane method for screening candidates not screened by professional degree programs. (-> taking the ad hoc Bar exam, again, and again.)

throwaway896 10y ago

I've been programming for 24 years (12 professionally). I've worked in startups, BigCo, and Facebook. I've been a jr. dev, lead, E4, E5, E6, EM, and VP. I've worked in the capacity of a PE, SWE, Front-end, Back-end, Data Engineer, and Data Scientist. I've worked with various clients such as: web, android, ios, tv, playstation, mac, and windows. I've been interviewed a dozen times, and have always been given an offer. I've been an interviewer throughout my career, and have conducted interviews at each company. I'm now in a place where I've made my money, and now I'm set to move outside of the Valley. Given that I'll be near Irvine, I thought it might be fun to see what Google is up to. Completely ignoring my history, this is what I'm told I have to prepare for when I come onsite: - Be ready to talk about complex algorithms like Dijkstra and A* - Be comfortable with sorting and efficiency (be comfortable knowing when insertion sort, radix sort, quick sort, merge sort, heap sort - Be aware of discrete math solutions and know probability theory, combinatorics, n choose k, etc.. - Know all data structures and what algorithms tend to go with them - Know graph algorithms and structures, their representations, and how to traverse them - Be comfortable with recursion and how to think recursively - Know OS concepts like processes, threads, concurrency issues, locks, mutexes, semaphores, monitors, etc.. So, to join the "best of the best", I have to brush up on all of these concepts (again) enough to answer random questions from random interviewers for 5 hours. Also, I'll need to do it in one of the preferred languages... on a whiteboard... and be syntactically correct. Oh yeah, I'll also need to talk through my thought process the entire time, and explain the tradeoffs, time complexity, space complexity, alternative paths, etc... I'll also need to show a go-getter attitude and not get flustered while the interviewer "pushes" me in various ways. I'll also need to build a rapport with half a dozen different people with various personalities, quirks, and moods. If it involves lunch, I'll need to pay attention to what I eat, how I eat, what I chit chat about, what the temperature is (am I sweating, am I dressed the same), etc.. Depending upon the type of work being performed, I'll need to show good "excitement" for the product, be it ads, games, VR, AR, etc... I'll need to show intelligence, but not be abstract. I'll need to think through problems very quickly, but also be thorough and not make mistakes. Do you have any idea how long it takes to prepare for this? Do you realize how taxing it is on your life? I'm an introvert... this stuff destroys me for weeks. ...and this is from someone who has a 100% success rate, and already knows all of the answers! The sad part in all of this, is that it doesn't actually work. You've made your candidates go through this awful gauntlet, and your people are no better than any other company. You still have great people that leave, bad people that stay, bad solutions to easy problems, features that shouldn't be built, genius developers that can't communicate, teammates that won't stop talking, managers that make your life hell, managers that are amazing, problems that excite people, problems that bore people, etc... There's no difference, and that's why it's tiring. Would you like to know the absolute worst project you could ever work on as a developer? It's one that takes a lot of time, work, thinking, personal interaction, consumes personal time, requires ridiculous scrutiny, needs to be perfect the first time, and wether or not it succeeds or not, it is trashed as soon as you're done with it. That's our interview process. That's what we're making thousands of good people do, every single day.