20 ms·

I conducted a couple hundred interviews for my first FAANG employer, and I was constantly amazed at the percentage of candidates with years of Microsoft or Face

I conducted a couple hundred interviews for my first FAANG employer, and I was constantly amazed at the percentage of candidates with years of Microsoft or Facebook experience on the resumes who apparently did not know how to program. I always thought, 'huh, guess I know why they quit after 3 years, amazing that they all lasted this long." Then I interviewed for another company and utterly bombed. It became suddenly clear to me that I had been an idiot. Of course nearly all of those candidates were perfectly good programmers. They had had shit interviewing days, probably mostly due to nerves, but they probably would have mostly been perfectly good employees. How frickin' arrogant I had been for concluding that people who couldn't solve incredibly high stakes algorithm riddles on a whiteboard in 45 minutes with enough speed and flair were somehow not qualified to be my coworkers.

leafboi 6y ago
You've been arrogant for years and you know what? So have I. I and many, many people in this industry have been doing this for years. What's different from you and many other people is that you admit and face your bias rather than justify it. I'm seriously curious what google interview board members have to say about this study. People like Gayle Laakmaan have been saying things to justify the whole process for years; but now that there's actual science, what do they have to say in the face of science?
- MattGaiser 6y ago
  From what I have read from Gayle Laakmaan, they know this throws away many good engineers, but it is acceptable to them because it doesn’t let bad ones through.
  - SquishyPanda23 6y ago
    This is essentially the point of a lot of hiring and performance evaluation theory. E.g. it's acceptable (but not ideal) not to promote talented commanders. It's catastrophic to promote someone to General who isn't ready or is unsuited.
    - redisman 6y ago
      Software engineers are not commanders or generals and it is NOT difficult to fire someone in the United States of America. Everyone in this industry has a at-will contract.
      - edmundsauto 6y ago
        However, high rates of employees getting fired is bad for culture. People are always anxious about their jobs - if they see a few colleagues fired for nonperformance, a number of them will be driven to anxiety. (I am one of these people, and being anxious about job security ironically makes me much worse at my job)
        redisman 6y ago
        Right but I also do think that FAANG is over-estimating how many of and how bad these "bad apples" aka. slighly above average developers would be and how terribly difficult all the work they do is.
        ZephyrBlu 6y ago
        When you have your pick of the bunch, of course you're going to look at slightly above average as "bad". I'm not sure how much engineer skill matters though. One slightly above engineer might be fine. But if half your org is made up of slightly above average engineers, I feel like there will be a knock-on effect.
        redisman 6y ago
        I don't know maybe my view of slightly above average is inflated but I think of that bunch (which I might be a part of) as being easily pulled in by good technical leadership. If only to make their life ultimately easier / less painful. You don't need 60-70% amazing engineers to do that. But I guess they can do whatever they want. They have infinite money and unfortunately a good reputation (in many cases unwarranted). They've become like the Harvard or Yale of tech. Oh you went to Google, great come on in and join us.
  - leafboi 6y ago
    But they're not aware that the filter is just anxiety. Google is basically using anxiety to filter good candidates and eliminate false positives which works in a sense but is still highly illogical. Why not use a technical filter to filter for technical candidates? Anxiety seems like a pointless filter.... how does that even eliminate false positives?
    - mgkimsal 6y ago
      it would seem it might be 'letting in' a whole load of people who don't have appropriate anxiety responses. There are some situations where anxiety is perfectly normal, and perhaps even useful, but if you screen out people who have normal anxiety, what impact does that have on your company operations and culture?
      - UncleOxidant 6y ago
        I'm a pretty anxious person, so much so that I've pretty much retired instead of doing anymore technical interviews. I had a discussion with a very anxious, but brilliant software developer a few years back and we came to the conclusion that as long as we don't let our anxiety get too far out of hand it's actually kind of a superpower in the job setting. That's because that niggling anxiety you get in the back of your head as you're coding generally makes you more careful about how you're designing and testing your code. You're more careful about security, safety and correctness. Whenever I get anxious while coding I stop and ask myself if maybe it's a message that I need to listen to - maybe it's trying to tell me to tread carefully because I'm entering an area that's potentially problematic. People without that niggling sense of anxiety always in the background, the folks who are easily going to ace the programming interview because their anxiety levels are so low, those folks, I theorize, are potentially not going to be so careful. Now you could argue that that's a plus in many situations - a startup that needs to get code out the door right away, for example. But it really depends on the domain. For critical systems in applications like healthcare, avionics or robotic control I think the anxious coder is the one you want. Companies that completely weed out the anxious programmers, as you imply, will have a different culture with perhaps too much emphasis on risky behavior.
    - 6y ago
  - candu 6y ago
    I've definitely repeated that line in the past to justify tech industry interviewing practices - but sometimes it goes beyond "setting a high bar" to something more toxic: an interviewer using the interview as a chance to show off how smart _they_ are, rather than assess the candidate; deliberately creating high-stakes "pressure cooker" environments because, you know, that's just how we work here and they should get used to it; and so on. These things then get rolled into the same justification: after all, we're an exclusive club of ultra-smart 10x ninja pirate Jedi, which of course means we should have the default assumption that others don't belong in this club. I wonder now: for every "bad one" not let through by this sort of process, how many other "good ones" look at it and say "no thanks"? How many hear about this sort of hazing and are dissuaded from applying in the first place? How many experience it one too many times and just quit the industry altogether? How many of those "bad ones" are even objectively bad, and not just having a bad day or intimidated by a process rife with both intentional and unintentional hostility? In other words: are we actually assessing what we claim to assess with _any_ predictive accuracy, and is the collateral damage to company reputation and the pool of available candidates - a damage often hidden to the individual companies that impose this process - even worth it?
    - RogerL 6y ago
      I think it goes far beyond that. I'd bet dollars to donuts that you will find both protected and unprotected groups over represented in the false negative pile. Do women have more test anxiety then men? If so, guess what your process is selecting for. Do minorities have more self doubt than majorities. Same thing. And so on. And that doesn't address the file drawer effect. I'm 54. I can code a binary tree, hash table or what have you, if I have to, but I am not as practiced as somebody fresh out of school, because that heavy lifting is done by libraries, and I'm busy contributing original mathematical algorithms that no one ever asks about because they don't have the background to understand the explanation. So I don't go on FAANG type interviews. I know I will fail, and if I don't my offer will be predicated on that apparently lower performance. At best I will have an utterly miserable experience. So I self select myself out, mostly on age. This is not good, for so many reasons.
      - 6y ago
- triceratops 6y ago
  Gayle Laakman specifically has a business empire dedicated to help people get through the process. Regardless of the actual merits of the process her opinion is going to be biased.
  - leafboi 6y ago
    I don't think it's relevant. Her business is designed to get you to game and pass the interview regardless of whether or not the interview is effective. Therefore her business interests are orthogonal to her opinions on "interviews." She may still be biased, but I don't think business interests color her bias.
  - notacoward 6y ago
    Quite a racket, being part of setting up this gauntlet and then selling books on how to get through it. Some might call that a conflict of interest, but there's no such thing as ethics for the nobility so to hell with what the peasants think.
- deeg 6y ago
  I'm not a googler (but I've interviewed there) and I disagree somewhat with the original premise. I think whiteboarding does filter out bad candidates but also filters out good candidates who fail the anxiety test. Google, with their massive pipeline, probably doesn't care about the false negatives enough to change; they still find enough people to hire. It's the companies with smaller pipelines that need to scoop up these good candidates.
  - ghaff 6y ago
    In general, hiring practices probably optimize for filtering out bad (or at least somewhat speculative) hires over passing on a potentially really good candidate (especially if there are any concerns to go along with the overall positives). Of course, if the pipeline is massive (whether it's jobs, schools, etc.) this tendency gets amped up even more and anyone who doesn't come across as pretty much perfect on all dimensions--whether they are or not--is going to get dinged.
  - collyw 6y ago
    I used to be reasonably good at algorithmic stuff in university 20 years ago. Since then I hardly ever practice. It's not that I am bad at them, now, but its just so hit and miss whether an answer will come to me in time, you might as well toss a coin. If I was doing algorithmic stuff every day I have no doubt I would be better. Usually what happens is I get out of an interview and a an answer (or a better answer than I gave) pops into my head. Like I say, might as well toss a coin.
    - cutemonster 6y ago
      It seems you cannot see FAANGs perspective on this There are other people who always fail those coin tosses
- u67583 6y ago
  She will just say that the process is designed to minimize false positives and the expense of more false negatives. A bad hire is more expensive than a no hire. The problem is this isn't what gets you the smartest people on the planet. A small number might be interested in DS&A to that level, but most are not. They will learn enough to know how to google what they need and move on to what they are interested in. Smart people are constantly getting job offers from coworkers and bosses who move to other companies if they don't start their own. The few smart people who do put in the effort necessary to go to the FAANG companies always leave after getting the golden sticker on their resume. They leave behind them a residue of SAT preppers who have PhD's in inversing binary trees.
  - apta 6y ago
    > She will just say that the process is designed to minimize false positives and the expense of more false negatives. A bad hire is more expensive than a no hire. That's what they keep saying. However, it remains to be proven that regurgitating answers on a whiteboard in 45 minutes implies that the candidate is not a false negative, or even a true positive to begin with.
    - edw 6y ago
      We don't care about reality, merely perceptions. "Well I humiliated the person for an hour in front of a whiteboard" is the new "Nobody gets fired for buying IBM."
    - u67583 6y ago
      Someone who able to immediately understand and write out the solution to 80% of hard DS&A questions is at least able to write code. The question is if this is honestly better than generating your own FizzBuzz. I don't think so. I have heard rumors that Google has studied employee performance predictions based on interview score and found no correlation. I would bet this is an open secret and no one knows what to replace it with that isn't enormously expensive.
      - Apocryphon 6y ago
- lallysingh 6y ago
  I interviewed a lot of people while I was at Google, and sometimes the people were clearly, clearly too anxious to interview. Like one fresh-grad who's hands were shaking. I thought about how much pressure the kid must have been under. You try to help them relax, but you don't have much time, and the whole thing is just so unnatural. Other places I've since been at, and interviewed with, give you a laptop, a problem to solve, and some time. You can focus on the problem instead of the situation much better, and I think that really helps. As an interviewer, it also helps keep some distance from the interviewer. It's too easy to try to micromanage the interview and keep the candidate uneasy. But there's a natural "don't interrupt someone when working" instinct that keeps interviewers more distant when the candidate's programming. Coderpads on video conference, I think, are pretty good when the candidate has a good space to work in. They're in comfortable territory and you can see them by their keystrokes. The interviewer feels like they're getting more accurate data about how the candidate really operates. I just wish it could do keyboard shortcuts better -- emacs users like me hate seeing Ctrl-N bring up a new window. The issue of IDE/compiler/keyboard/keybindings is also there, but that's easier to work with.
  - BlahGod420 6y ago
    Microsoft interview. I was just graduating college, and was super anxious walking in to my first interview. The interviewer realized that writing on the whiteboard was going to be awkward for the problem he was asking me to solve so he let me just sit down at his computer while he hung out to to the side and watched me work in notepad. I think that was the best way to do that interview, because the second I started writing code my brain flipped in to code-writing mode and everything relaxed. One of the better interviews in my career.
    - taurath 6y ago
      Nowadays that's "favoritism" in an interview and it wouldn't fly. Everyone must pass through the same meatgrinder (that, surprise, fails people other than white men more often).
- _curious_ 6y ago
  Over the past few years in tech, I have interacted with and observed (as a fly on the wall) a wide variety of recruiters, hiring managers, etc. from companies as small as a dozen (usually around the time a founder/CEO brings in external "support"). There exists an incredible amount of arrogance and ego among them by-in-large. The best are humble and curious while maintaining clear and direct communication. To be fair, they are often tasked with making important judgement calls sans complete information, though that's the fault of the leadership/culture as to a poor approach.
- Bekwnn 6y ago
  At the start of my third year as a student, I biked through a record-worthy rainfall to my first interview with a small local games studio. Showed up completely soaked, but sat down relaxed and feeling reasonably confident. (I had done a handful of unity and opengl projects.) The interview started with a bit of small talk, I chatted with one of the guys about Brood War and Starcraft 2. Later during the technical interview they asked me about the difference between private, protected, and public and said I was the only student they had interviewed who had answered correctly which was wild and honestly stunned me for a moment. They liked how in one of my examples of scripting something I had written some fun dialog and I mentioned I did writing as a hobby which seemed like a plus. I talked about which classes I enjoyed the most and how they were challenging/interesting. I did not get a job offer and learned from a friend that I had come off as "depressed and disinterested" (I don't think they realized he was going to relay that info to me...) All I can do is guess that it's a combination from showing up completely drenched and sharing how I enjoyed those "challenging" classes made it seem like I would get quickly bored of scripting... After that, I bombed an interview for a QA role because I went into it completely unprepared for just how much it would differ from a programming interview. Point being those first two experiences got in my head and I basically had anxiety over anything job-hunt related for the next 2.5 years. When I did get a job, I was extremely happy with the interview process (even though I felt I did poorly on it). Here's more or less how it was structured (TL;DR): - Office tour/chat with a programmer who had referred me - quick 5 minute introduction to senior programmers in charge of the technical interview - 1 hour alone in a meeting room with a laptop and 4 written questions (a generous amount of time) - ~15 minutes reviewing my answers with the senior programmers - importantly, they gave me a chance to talk about my answers and when I got something wrong they would simply state that it had an error and see if I could spot it - 15 minutes on C++/memory/performance/behavior quirks (important stuff in AAA games) - ~30 minutes talking about stuff I had worked on - occasionally they would mention something related I hadn't heard about and explain it while gauging how well I could follow along Basically, based on my own interview experience/anxiety if I had to choose an interview method, it would be very similar to what I just mentioned. Seeing a familiar face and the introduction followed by the alone time did a lot to ease my anxiety. The time where I felt most comfortable was talking about the stuff I had done because I was very familiar with all of it/it was easy to talk about. The process seemed less focused on where I had gaps in my knowledge and more focused if I had a decent amount of knowledge in general and if I had the ability to recognize and correct the gaps in my knowledge. Sorry if it's a bit of an info dump, but it's something I think back to a lot.
- cmrdporcupine 6y ago
  I've trained for interviewing twice at Google. I don't volunteer to give the interviews, though, because the interview I was trained to give, I would never pass. And sadly, this is common and recognized at Google, was mentioned in interview training, and is just said to be part of the fact that the bar gets higher, or something, mumble mumble. I find this disturbing.
  - chillacy 6y ago
    Every year I've noticed the questions get harder too. A hard question in 2012 (off the top of my head, 2 pointer solution to linked list cycle detection) might be considered an easy question today.
PopeDotNinja 6y ago
Thank you for posting this.
mpalczewski 6y ago
My experience has been quite opposite. I worked for a FANG and conducted over 100 interviews. Most of that time I thought I was asking really hard questions and wasn't sure I would have been able to answer them if I hadn't seen the question before. I later interviewed at a different FANG, surprised myself and answered harder questions than I typically gave and answered them better than most of the people we hired. Not sure what to make of that.
- Apocryphon 6y ago
  Looks like being an interviewer taught you a thing or two about the test content.
- onepointsixC 6y ago
  That sounds like when you spend a lot of time exposed to and walking through certain types of problems led you to getting good at solving those types of problems.
roldie 6y ago
The same is true for design/ux jobs interviews. Well, at least for me. I got laid off a couple of months ago, and have been interviewing pretty steadily since then. I have yet to receive an offer. I already know where my strengths and weaknesses are. I'm fine with 1 on 1s and all that, but when it comes to the technical part of the interview process like a take-home design project or a live design challenge, I usually fail. I know I have the skills. My work has always been well-received, and I've always received good marks on reviews and feedback, but I haven't been able to translate it to the interview process. I've tried to assess where I go wrong, and I think I panic and put too much effort into trying to figure out what they want to see or come up with something innovative rather than just doing the work and following my normal approach. The stress of the time crunch (and sometimes not knowing anything about the product or problem) only add to my inability to improve in this space. -- When I've sat on the other side of the table, I know that most interview processes aren't that well-structured or set up to actually evaluate the candidate. Even when there's a good process, it's often too easy for one person to influence the results. So sometimes I tell myself that it was a crappy interview process and it just wasn't set up for someone like me to succeed. But I still end up stewing over it and feeling depressed for a few days.
- ludamad 6y ago
  The depression hits those hardest who put their identity into what they do. Often, I don't realize how dependent I am on positive feedback until it hits. Lately, I've tried to remember in those moments that I am a diverse person and that if I looked in the mirror and saw the worst developer ever I would be OK
  - dbattaglia 6y ago
    If you’ve been looking for a while I think it’s totally normal to get some deep depression regardless of how you identify. Interviewing is stressful and draining and feels incredibly arbitrary. Also, at least in the US, your employment is absolutely tied to your quality of life; unemployment benefits are a joke and you’re on your own after they run out. I’d be depressed as well. Not saying I disagree with you though, I think identifying heavily with your job makes it even worse.
mycodebreaks 6y ago
Additionally, companies doing common pool hiring are worsening the situation even further. One bad interview day or one failure to solve complex riddle means that you're not good for any teams within that company until cool-off time passes which is typically from 6 months to 1 year. The system of cool-off period is equally brutal.
schreiaj 6y ago
I was on the other side - I flew out to FB during a vacation earlier this year. I got there, could explain the solution but something was off and I kept losing the thread when I went to convert it to actual code. The interviewers didn’t know I’d gotten a call from my cat sitter that morning and one of my cats had to go in for an emergency check up. (He ended up being fine but didn’t know that at the time). Later that week I got the rejection from FB and then, 15 minutes later the positive response from Google. Really made me realize how much impact the day has on an interview outcome.
- fermienrico 6y ago
  I mean this would apply to going on a first date as well. First impression is what matters and once the impression has been ruined, all bets are off. It is not specific to the interview process.
  - 300bps 6y ago
    Rescheduling a date or an interview at the last minute doesn’t make a great first impression either.
    - linkpuff 6y ago
      It doesn't give a good first impression, but failing miserably is somehow even worse...
    - fanimalmanimal 6y ago
      I rescheduled the second date with my now wife at the last minute. Worked out well for us, but I was so tired from work that there’s no way that date would have gone well (busy period of a project at the time).
    - jarjoura 6y ago
      I would LOVE to get my 2 hours back in a day because of a last minute interview cancelation. The only person who would be truly irritated is the recruiter, who's job depends on meeting candidate quotas. Even then, they want you to be successful. Trust me anyone reading this, if you are not feeling well, or something is distracting you, please, please, do feel free to reschedule your interview, even last minute. Once you go through the process, and it's a no-hire, that is recorded in the system and you won't be allowed to try again for some extended period of time. At my company, it's 1 year.
monksy 6y ago
I'm pretty angry with the person that you were. I'm frustrated with the people who look up a question, see the exact solution and walk through and then expect the candidate seeing the problem statement for the first time to walk through it in the same way. There are questions being asked that full academic papers have been written on. What's even worse is typically I get interviewers that are not experienced+prepared enough to give hints or work with you. I am happy that you've had an epiphany to see where you were wrong. If you ever are in a situation to build a quality team. Interview people for the skills to work with others+ teach others, look to optimize, experience, and that they're willing to learn. You'll have a fairly good group of candidates to pick from as that don't do well in these coding interrogations.
- StavrosK 6y ago
  I bomb on technical interviews the same way because my mind just freezes and can't get through even simple problems. I had the same question you mention. "This is a problem a paper was written on, are you expecting me to derive a whole paper from first principles in half an hour, or are you expecting me to have seen it before? If it's the latter, why not let me Google, as I normally would?" I feel that saying "I would solve this problem with <algorithm>" should be good enough, and if I'm asked to implement it, I should be able to copy paste the Wikipedia pseudocode and start converting.
  - monksy 6y ago
    The funny thing about this is: They're not looking for someone that is eager enough to show they're willing to work through it even though they have no idea to proceed. They are looking for someone that got lucky enough to be ready to answer that particular problem, but won't stand up to them that the ask was a bit too much for a reasonable interview that is intended to see if you're a fit for the company and skilled enough to get the work done. They aren't looking for someone that will dress them down to tell them that's incredibly insulting to ask something that took an academic a long time to come up with a solution for that. [Although a rough approach and fairly unfriendly. That shows a lack of desperation, confidence on the knowledge, and a good understanding of the difficulty of the task at hand (heck that's a good signal for won't underestimate points during planning)] (There's a singly linked list question that amazon used to ask that qualifies for this)
yamazaki 6y ago
That's why I think take-home exercises are a much better way to evaluate candidates. Give them the exercise and enough time and you will figure out: 1) How good they are 2) How much they actually care about the job offer -- the more detail and the more passion they put in the exercise, the more into the job they are.
- legopiece 6y ago
  Totally agreed. I've been in the position to evaluate several take-home exercises during the years and they always produced good results
  - eNTi 6y ago
    Doesn't that tell you that the method of hiring is flawed in the first place? If you care to weed out bad candiates, what help are 100% perfectly fine take-home exercises? The only thing that tells you is, that all of your candidates are viable in the first place. Just go into an interview with THAT assumption and ask the right questions. Why do so many companies assume that people who try to get hired for a certain job don't meet the basic requirements? That gotta be the rule not the exception? That's just a bad faith assumption. Just make sure your hire fits into your culture and give them sufficient probation time to grow into your codebase.
    - cutemonster 6y ago
      > > produced good results > what help are 100% perfectly fine take-home exercises? The only thing that tells you is, that all of your candidates are viable in the first place. I think you might have interpreted that, in a different way than what was meant.
  - reagent_finder 6y ago
    Could you provide a bit more info? How long were the exercises? Were the applicants evaluated more based on their results or possible writeups? How much did their CV weigh compared to the take-home exercises?
- 6y ago
u67583 6y ago
It's not just nerves either. All interviews, but especially FAANG ones, are random. The interview might be racist, sexist, etc. They might have gotten divorced that day. The question they ask you is something you haven't heard of but they spent their PhD on. You can even do everything correctly, but the interviewer doesn't like the way you did it. The leetcode stuff is just masochism. You will spend X months beating DS&A into your brain until someone can pullout a random question and you immediately know what questions to ask, what steps to take, and how to write it out on a whiteboard.
- VRay 6y ago
  I agree with you for the most part, but Google goes out of its way to force the interviewer to just hand in an emotionless, gender-neutral description of the candidate's code and coding performance to a hiring committee that makes the decision This kinda bit me in the rear when I applied to Google a couple of times. As a nerdy American male, aged 22 to 40, with above-average people skills (for nerds) I got along great with everyone I talked to. But the hiring committee would get a sloppy page of half-functional garbage code, along with a note like "Seems like a great candidate". I found another FAANG company I fit into a lot better anyway, so it all worked out great
- bananaface 6y ago
  It's difficult to remove that randomness from the process. As I see it the only reliable approach for both sides, given that structure, is volume - you just do/conduct a lot of interviews and evaluate/get evaluated on the top percentile.
bumby 6y ago
I've heard HR optimizes processes that limit Type I errors (false positive) at the expense of Type II errors (false negative). I've often wondered if this is because, from the HR perspective, false positives are much more costly. I.e., Those who would be helped by limiting the false negatives are project managers who are too downstream in the process for HR to care.
- foolmeonce 6y ago
  I think the problem is HR itself. Few companies should be large enough to warrant full time HR, but even small companies need many.. HR are specialist in expanding the disconnect between people the company thinks it needs and people who are willing to work for it.
  - bananaface 6y ago
    You say that, but look through this thread. HR has a solid understanding of what a given company's large-scale objectives are when hiring. As evidenced by most replies in this thread, technicians on the ground do not.
    - foolmeonce 6y ago
      The evidence is that it is a hard problem that is not solved. No amount of people who can't do the task demonstrate the existence of experts who can. Google and Microsoft have shown us examples of failing at simple HR tasks for years or decades with budgets for HR that dwarf a small companies entire payroll. What virtually every attempt shows is that it is better to hire people who are roughly qualified and see what happens, managing the results instead of filtering. Having an HR strategy for hiring leads to creating biases (i.e. requirements based on your current work force) that gets you a group of overly similar and therefore collectively incompetent work force.
- timClicks 6y ago
  Yes this. Hiring the wrong person can be ridiculously expensive, especially if they linger on in a role for years corroding the culture.
fragmede 6y ago
Where engineering fields have a disproporationate number of individuals with ASD (née aspergers), and where anxiety plays a large part of the syndromes, it's no surprise that many, many good engineers are terrible at interviewing.
marta_morena_25 6y ago
I am focusing on the algorithmic part, which is the only thing I can influence in my company's interviews. I wish we would evaluate candidates with some pair programming, but that's never going to happen. > incredibly high stakes algorithm riddles Yeah there you go. This is your problem (Google/Facebook I assume?). It's more than questionable to expect candidates to solves complex algorithmic problems on a whiteboard in 45 minutes. You should ask moderate algorithmic questions that offer many solution approaches and accept solutions that are "good enough". It is not about having a candidate gaining some magic insight that some MIT student had 30 years ago during his master thesis (and reproducing it in 20 minutes lol). It's about giving a reasonably complex problem, that is not too easy but also not too difficult and allows you to focus evaluation on: * Does the candidate write proper code that isn't far from compiling? (If they can't, they don't have the experience. It's like not being able to write without a spell/grammar checker. Small mistakes are fine. Big mistakes indicate lack of understanding.) * Does the candidate have a structured approach to problem solving (all the time I see people starting to write code immediately and getting completely lost in what the problem even was. This is a red flag to me and baffles me each time again.). * Does the candidate debug his code and walk me through. Does he find obvious bugs while doing so and can he convince me that his code works? (If not, and that happens often, its another red flag) * Can he rank the speed of his solution with other theoretical solutions? Let's say they found an N^2 algorithm. I usually ask if there is anything faster (even if there isn't). This shows if they have some decent fundamentals in CS and are able to think about the boundaries of an optimal solution and how far they are from it. This is something, people without a CS major usually can never do and unfortunately also not too many with a CS major. It's kinda relevant though, if you optimize for performance and have no clue what the theoretical limitations are, then you are grasping for straws. There is one big secret for getting A LOT out of easy questions: I start to modify the problem statement and see if they understand how this changes their solution and their algorithm. People who don't have a good grasp of CS will fail miserably at this task, because this isn't something you can memorize.
- aprdm 6y ago
  pivotal does pair programming interview. The morning with one person in a theoretical problem and afternoon with another in a real problem. I liked the experience and the process, in the morning it was a blast. We really clicked. In the afternoon I had to use the same setup as the guy I was collaborating with -- Vim with his bindings and Golang. I had never used Golang before and even tho I was proficient with vim his binding were quite opinionated. I felt the guy from the afternoon had 0 interest in being programming with me. He wasn't collaborating and was looking at his cellphone the whole time. The problem was to write a functional test for a CLI that would spawn a web service in Golang, parse some json and run some assertions. Golang had some quirks with JSON and new line encoding that I spent my whole afternoon with. It is something he could have unblocked me as it a very specific problem, instead he kept telling me to read the official golang docs, not even to google the error. As someone being interviewed I followed what he asked me to do and worked in his environment but it wasn't a representative of how I would have worked. That said, I feel it could work! I just should be able to judge the person who pair programmed with me instead of just being judged :) the person in the morning would be a 10/10 and in the afternoon a 4/10.
markandrewj 6y ago
It's also sort of ironic how studies repeatedly show high preforming teams, are cognitively diverse teams. Even though research shows this, the hiring strategy of most technology companies, is hiring new employees with the same skills, and traits, as current employees. https://hbr.org/2017/03/teams-solve-problems-faster-when-theyre-more-cognitively-diverse https://hbr.org/2017/03/teams-solve-problems-faster-when-the...
- CobrastanJorji 6y ago
  This is a critical point that a lot of hiring misses. We talk about building great teams, but the hiring requirements are static and never seem to consider who's currently on the team and what mindsets or backgrounds are missing.
lumost 6y ago
Senior/Principal Engineers at FAANGs may not even code all that much in their day to day. The difficult decision that gets faced when interviewing those folks is whether they could walk into a fresh environment, and stack, and immediately earn the trust of their team. In practice whiteboard interviews assess this pretty well. A new senior engineer must immediately be shipping optimal, tested, and well designed code. Otherwise you'll have Junior Engineers coaching Senior Engineers and the Junior Engineers will just get frustrated and leave. Worst case, you'll have an "architect" who never learns how to actually deliver independently in the environment.
- mianos 6y ago
  Any significant system will take months to learn. Your statement is probably only true for some trivial system. A senior engineer comes with years of experience designing and coding systems that took years to develop and run at scale. Given time to learn they should be just as good at solving day to day bugs but if you assign them that you are wasting your time and money on experience. If you don't value experience you are wasting your time and money on experience. It's pretty normal to have more junior engineering staff help new senior staff learn the ropes. It's also common for those less experienced staff to learn from the more experienced people even in that situation. I'm not saying senior hires should be respected from the first second because they are over 30 or have a long resume.
  - lumost 6y ago
    Learning the ropes of a new company is fair and being slower at first is to be expected, but explaining that code reviews need to be tested to a senior hire isn't as fair. Similarly a new senior hire should be able to hop into a code review and catch problems/suggest improvements early in the process. These two behaviors aren't as dependent on knowledge of the system as they are on core coding competencies. The whiteboard interview reasonably works to assess these, but it requires a lot of prep and is prone to false negatives.
ghostofdarwin09 6y ago
Have done over 1,000 interviews for a FAANG competitor that IPO'ed in the past 10 years. Completion time (in minutes) of a coding puzzle is essentially the only objective measurement taken during these coding puzzles, and is sadly the primary datapoint fed into the hiring manager's decision. The hiring managers usually adjust the cutoff based upon whatever quota they want and/or if they're expecting people to leave. I've worked directly with a VP of Engineering and that's really all he wanted to hear. The whole process is missing a feedback loop to the evaluators, resulting in the OP's situation. In my own situation, it took several years after that mess of being forced to shotgun candidates to pick apart what in the experience was actually predictive of success and what wasn't. To this day, the most successful hires from my perspective were those who just really wanted the job and wanted to contribute to the product; definitely no strong correlation with "leetcode" ability. It's not just that the coding quizzes are poorly administered, but that the hiring mangers and leadership industry-wide have been obstructive to getting evaluators feedback (for starters, what did a candidate's other offers look like? where were they 3 months after the interview?) and especially tight-lipped on sharing interview questions. That last bit is particularly obnoxious because people monetize their insider knowledge either through things like Rooftop Slushie or they take a more Gayle Laakmann angle. (Just to be clear: while many questions are "protected under NDA," many questions are also stolen from other companies-- interviewers asking them are already violating their own NDAs when asking them, or potentially when feeding the question bank of their new employer). What you can do is go to your manager in your 1:1 and ask for interview feedback. Ask what happened to candidates 3-6 months after the interview, even if they were hired (perhaps not just to your team). Start to get feedback, and then work from there. You'll probably do better interviews, and at least curtail some of the information arbitrage culture in the C-suite.
- bananaface 6y ago
  Occam's razor is: algorithm tests are specialised IQ tests, and that version of IQ is actually a very reliable indicator of performance (compared to the other signals available). I'm not exactly sure I buy it, but it seems like the simplest explanation.
tchaffee 6y ago
The best advice I ever got about interviews is to figure out ways to prove yourself wrong about what you think about the candidate. Although it's good advice for a candidate who seems too perfect, this advice really shines when someone is bombing.
- cmonnow 6y ago
  That advice seems like unnecessary mental gymnastics. Just take an unseen technical problem, solve it for the very first time in front of a colleague, then double your time as the expected time for candidates in an interview. When you're under time-pressure, you actually spend more time thinking about how much time you have left, rather than thinking about how to solve the problem.
  - tchaffee 6y ago
    It's not mental gymnastics. The point is to challenge yourself as an interviewer to reveal a diamond in the rough. Some people suck at interviews and are great at coding. I've hired a lot of them and we've made a lot of money together. I've never had to fire anyone either so I'm not getting false positives either. > Just take an unseen technical problem, solve it for the very first time in front of a colleague, then double your time as the expected time for candidates in an interview. That gives very poor signal in my experience due to the time pressure. Your process is now selecting for people who are good at taking tests instead of selecting for good engineers.
- deleted 6y ago
  [deleted]
aantix 6y ago
I call these high stakes interviews "the perfect dismount". You can feel the pressure mount - any algorithm that doesn't run on the first try or second (with a couple of quick fixes) and you're being mentally discounted. The same for silence - if you're thinking through something, take abnormally too long, you're discounted. The Perfect Dismount. A 10.0 is what's needed to land a FAANG job.
- 1qaz2wsx3edc 6y ago
  I just pulled out my laptop and if they aren't cool with the solution I google'd in 30 seconds, they can test my critical thinking in another manner. That was my critical thinking and resolve under pressure. These are nothing but shit test. What are shit tests? When somebody fucks with your head to see how you will react, what you are experiencing is typically a (series of) shit test(s). Everyone has been shit tested, gets shit tested and will continue to be shit tested; We use shit tests to make value judgements about people, likewise they can be used to determine how people cope under pressure. The underlying mechanism of shit tests is to test your mettle.
xwolfi 6y ago
What some of us do now is at home exercises with no deadline and setup the interview to do a code review of it after it's given back. It gives so many advantages: - people will have some fun trying to solve a real issue / build a little software - they will show how good they are at stack overflow, general methodology, cleanliness, test coverage, deployment and even git (how many we see who can't even gitignore their project files, make a build script that works, or test for real) - horrible candidates who can't even cheat will not be able to lie their way around a fake resume, cheaters will bomb the code review quite fast - candidate will also discover their future team mates general work attitude during the review and if the reviewer is good, will lock the candidate faster than "how many billard balls can you put in a Boeing 747" type of interview. - candidate will even LEARN during the code review => you get away with something out of the interview even if you fail Since I've been interviewed that way, doing my little project on my wife's pregnancy bed smiling like an idiot at solving the challenge, then fell in love with my manager showing me new tricks during the review, I'll never do any other kind of interviews myself.
- tchaffee 6y ago
  I recently did one of these where I was paid at half the hourly rate of the job offer. There was an initial unpaid assignment that was difficult but totally related to most engineers' day to day work. That took less than 30 minutes. Anyone who passed that got the paid assignment which took a few hours.
  - bananaface 6y ago
    If I had options I wouldn't even do a 30-minute assignment. I'd just go with someone else. I'm reading about employers giving assignments a lot in this thread, but what do you do about the fact that the people you really want just don't have a reason to waste that time?
    - tchaffee 6y ago
      There was no interview. Not even a phone call. After I submitted the 3 hour paid assignment they hired me by giving me access to Slack and we just started working together. One of the smoothest and easiest "interviews" I've ever done and I got paid for everything except for a 30 minute challenge that helped solidify my understanding of git. > people you really want just don't have a reason to waste that time I'm "really wanted". In the past week I have had to say no to two clients calling me for follow up work. Where do you think I wasted my time?
nathanvanfleet 6y ago
Couple that with 45 five times over! I was flown down for a Facebook interview from the east coast. It was my first tech interview and it was with facebook. I was so exhausted by it, and then the next day I had an interview at Uber. I started that one already pretty tired.
Cthulhu_ 6y ago
I much preferred our style of (technical) interviews (I took on a few dozen over the years). First there's a review of the CV, Linkedin, and github, if that looks good, a first interview - just get to know the person, very casual. If that clicks, second interview is the technical interview - we did that by giving the candidate homework, 4-8 hours worth of tasks that are close to their day-to-day work, usually something with a REST API, some basic math/arithmetic, and a front-end / forms, and plenty of room for the candidate to play with. It was received pretty positively; especially early on (2012-2015) we had a lot of candidates indicate they had never done anything with JSON or REST before. (later on they mentioned having done nothing with XML before, lol). And we got to see some interesting solutions and creativity; one guy we hired did it all in J2EE, while we were a Spring fanclub. But the code was sound, he showed that he understood how it worked, etc. The conversation during the technical interviews were entertaining as well.
- cutemonster 6y ago
  > basic math/arithmetic Can I ask for some example(s) of what type of questions you asked?
arethuza 6y ago
I learned this lesson a few years back when I interviewed for the CTO role of a educational software company - the main part of the interview was preparing a presentation on how to launch a new product which I had to prepare and present to the management team. That went very well and I was feeling pretty good. Then the CEO had a quick chat and happened to ask me a very simple technical question and my brain would not work - I completely failed to do it even though it was trivial. I think that's how I discovered that mental context switching is a real thing - I had spent a few hours preparing and giving a presentation and then when asked a simple technical question those parts of my brain were completely offline. I think the shock of not being able to do it had a big effect on me and I went to bits (possibly the first time I've ever done that).
- touristtam 6y ago
  > I think that's how I discovered that mental context switching is a real thing You had to go to that level to understand that? I am glad you did realize it, but I am surprised it was that late in your career.
  - arethuza 6y ago
    I'd probably heard about it but I'd never had it really hit me like that before.
    - cutemonster 6y ago
      How did the CEO react / say? If I may ask
ryder9 6y ago
you're an arrogant prick
- dang 6y ago
  We've banned this account for repeatedly breaking the site guidelines. Please don't create accounts to do that with. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
soamv 6y ago
I'm so glad this realization is the top comment on HN. I think Fizzbuzz can be actually a reverse test: if an experienced programmer can fail fizzbuzz in an interview, then maybe it's the interviewer who screwed up.
justinlloyd 6y ago
For three years or so I taught week long corporate training classes at Apple, Microsoft, Facebook, eBay, PayPal, Cisco and Intel. Every week, week after week, real rocket-science level Android and iOS deep-dive in to the guts of the operating system classes dealing with firmware and device drivers and file systems. In the classes we didn't build apps, we built operating system components. Small to large classes, thousands of software engineers from senior and up, over the course of those three years. I would stand up in front of 80 or more engineers, go in to esoteric aresa of the operating and talk eloquently and at length about the structures and code found there, and live code on a projector, answering questions about the code and debugging the code of everyone in my class as they followed along. Day-after-day. 40+ hours a week. It was intense. I became an independent advisor to teams and a consultant for some of the groups on how to bring up Android on new devices, create device drivers, and so forth. Some of those classes, I wondered how some of the people I was teaching was actually able to hold down their job. Months later, after I stopped teaching, I interviewed at Intel and PayPal and Cisco. I bombed every interview. I was, by all accounts, unable to program my way out of a wet paper bag. Everyone has off days.
lazysheepherd 6y ago
I've done my first programmer hiring for my startup several years back. Thankfully I've came across Guerilla Guide to Interviewing[1] article by Joel Spolsky, and that helped greatly. I've interviewed 6 candidates within a week, and hired one. Never regretted of the outcome. I've set up a test code so: an input variable, comparison variable, and an empty function. Function takes input variable as an input, and output of which is compared with comparison variable. Interviewee would be asked to fill in the body of the function, and play with it until function gives the expected output. I've set up a computer with two screens, put IDE on one, and Google on the other. Two chairs, and some coffee. First I've chatted with the interviewee for about 10 minutes, tryin to make them comfy as possible. Then before the test, I've stressed very much that I am also a programmer, and I know how awkward it is to be coding while someone watching, and that'd alone would make me do silly mistakes, so I was expecting same from them and that was completely OK. Afterwards, I've encouraged them to use Google in plenty, and feel free to stay silent or explain as they go. So I got to assess their fluid intelligence, their ability to break the task down and progress efficiently, their English proficiency[2] (if they use Google in English), their usage of keywords, their choice among in stack overflow responses, etc. At the end I've rejected a guy with 8 years of experience on his CV, and hired a junior. Looking back, that turned out to be an amazing decision, best I could have made, for work went good with the junior and I've had the (mis)fortune of working side by side with the 8yr guy several years later. PS 1: Task was to write a recursive function to travelse a multidimensional array, and find out whether the first letter of every "value" was a capital letter. PS 2: The work was to maintain and develop mid-scale SaaS project along with me. 1: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... 2: Country's mother language was not English, and English proficiency was not good on average.

leafboi 6y ago

You've been arrogant for years and you know what? So have I. I and many, many people in this industry have been doing this for years. What's different from you and many other people is that you admit and face your bias rather than justify it. I'm seriously curious what google interview board members have to say about this study. People like Gayle Laakmaan have been saying things to justify the whole process for years; but now that there's actual science, what do they have to say in the face of science?

MattGaiser 6y ago
From what I have read from Gayle Laakmaan, they know this throws away many good engineers, but it is acceptable to them because it doesn’t let bad ones through.
- SquishyPanda23 6y ago
  This is essentially the point of a lot of hiring and performance evaluation theory. E.g. it's acceptable (but not ideal) not to promote talented commanders. It's catastrophic to promote someone to General who isn't ready or is unsuited.
  - redisman 6y ago
    Software engineers are not commanders or generals and it is NOT difficult to fire someone in the United States of America. Everyone in this industry has a at-will contract.
    - edmundsauto 6y ago
      However, high rates of employees getting fired is bad for culture. People are always anxious about their jobs - if they see a few colleagues fired for nonperformance, a number of them will be driven to anxiety. (I am one of these people, and being anxious about job security ironically makes me much worse at my job)
      - redisman 6y ago
        Right but I also do think that FAANG is over-estimating how many of and how bad these "bad apples" aka. slighly above average developers would be and how terribly difficult all the work they do is.
        ZephyrBlu 6y ago
        When you have your pick of the bunch, of course you're going to look at slightly above average as "bad". I'm not sure how much engineer skill matters though. One slightly above engineer might be fine. But if half your org is made up of slightly above average engineers, I feel like there will be a knock-on effect.
        redisman 6y ago
        I don't know maybe my view of slightly above average is inflated but I think of that bunch (which I might be a part of) as being easily pulled in by good technical leadership. If only to make their life ultimately easier / less painful. You don't need 60-70% amazing engineers to do that. But I guess they can do whatever they want. They have infinite money and unfortunately a good reputation (in many cases unwarranted). They've become like the Harvard or Yale of tech. Oh you went to Google, great come on in and join us.
- leafboi 6y ago
  But they're not aware that the filter is just anxiety. Google is basically using anxiety to filter good candidates and eliminate false positives which works in a sense but is still highly illogical. Why not use a technical filter to filter for technical candidates? Anxiety seems like a pointless filter.... how does that even eliminate false positives?
  - mgkimsal 6y ago
    it would seem it might be 'letting in' a whole load of people who don't have appropriate anxiety responses. There are some situations where anxiety is perfectly normal, and perhaps even useful, but if you screen out people who have normal anxiety, what impact does that have on your company operations and culture?
    - UncleOxidant 6y ago
      I'm a pretty anxious person, so much so that I've pretty much retired instead of doing anymore technical interviews. I had a discussion with a very anxious, but brilliant software developer a few years back and we came to the conclusion that as long as we don't let our anxiety get too far out of hand it's actually kind of a superpower in the job setting. That's because that niggling anxiety you get in the back of your head as you're coding generally makes you more careful about how you're designing and testing your code. You're more careful about security, safety and correctness. Whenever I get anxious while coding I stop and ask myself if maybe it's a message that I need to listen to - maybe it's trying to tell me to tread carefully because I'm entering an area that's potentially problematic. People without that niggling sense of anxiety always in the background, the folks who are easily going to ace the programming interview because their anxiety levels are so low, those folks, I theorize, are potentially not going to be so careful. Now you could argue that that's a plus in many situations - a startup that needs to get code out the door right away, for example. But it really depends on the domain. For critical systems in applications like healthcare, avionics or robotic control I think the anxious coder is the one you want. Companies that completely weed out the anxious programmers, as you imply, will have a different culture with perhaps too much emphasis on risky behavior.
  - 6y ago
- candu 6y ago
  I've definitely repeated that line in the past to justify tech industry interviewing practices - but sometimes it goes beyond "setting a high bar" to something more toxic: an interviewer using the interview as a chance to show off how smart _they_ are, rather than assess the candidate; deliberately creating high-stakes "pressure cooker" environments because, you know, that's just how we work here and they should get used to it; and so on. These things then get rolled into the same justification: after all, we're an exclusive club of ultra-smart 10x ninja pirate Jedi, which of course means we should have the default assumption that others don't belong in this club. I wonder now: for every "bad one" not let through by this sort of process, how many other "good ones" look at it and say "no thanks"? How many hear about this sort of hazing and are dissuaded from applying in the first place? How many experience it one too many times and just quit the industry altogether? How many of those "bad ones" are even objectively bad, and not just having a bad day or intimidated by a process rife with both intentional and unintentional hostility? In other words: are we actually assessing what we claim to assess with _any_ predictive accuracy, and is the collateral damage to company reputation and the pool of available candidates - a damage often hidden to the individual companies that impose this process - even worth it?
  - RogerL 6y ago
    I think it goes far beyond that. I'd bet dollars to donuts that you will find both protected and unprotected groups over represented in the false negative pile. Do women have more test anxiety then men? If so, guess what your process is selecting for. Do minorities have more self doubt than majorities. Same thing. And so on. And that doesn't address the file drawer effect. I'm 54. I can code a binary tree, hash table or what have you, if I have to, but I am not as practiced as somebody fresh out of school, because that heavy lifting is done by libraries, and I'm busy contributing original mathematical algorithms that no one ever asks about because they don't have the background to understand the explanation. So I don't go on FAANG type interviews. I know I will fail, and if I don't my offer will be predicated on that apparently lower performance. At best I will have an utterly miserable experience. So I self select myself out, mostly on age. This is not good, for so many reasons.
    - 6y ago
triceratops 6y ago
Gayle Laakman specifically has a business empire dedicated to help people get through the process. Regardless of the actual merits of the process her opinion is going to be biased.
- leafboi 6y ago
  I don't think it's relevant. Her business is designed to get you to game and pass the interview regardless of whether or not the interview is effective. Therefore her business interests are orthogonal to her opinions on "interviews." She may still be biased, but I don't think business interests color her bias.
- notacoward 6y ago
  Quite a racket, being part of setting up this gauntlet and then selling books on how to get through it. Some might call that a conflict of interest, but there's no such thing as ethics for the nobility so to hell with what the peasants think.
deeg 6y ago
I'm not a googler (but I've interviewed there) and I disagree somewhat with the original premise. I think whiteboarding does filter out bad candidates but also filters out good candidates who fail the anxiety test. Google, with their massive pipeline, probably doesn't care about the false negatives enough to change; they still find enough people to hire. It's the companies with smaller pipelines that need to scoop up these good candidates.
- ghaff 6y ago
  In general, hiring practices probably optimize for filtering out bad (or at least somewhat speculative) hires over passing on a potentially really good candidate (especially if there are any concerns to go along with the overall positives). Of course, if the pipeline is massive (whether it's jobs, schools, etc.) this tendency gets amped up even more and anyone who doesn't come across as pretty much perfect on all dimensions--whether they are or not--is going to get dinged.
- collyw 6y ago
  I used to be reasonably good at algorithmic stuff in university 20 years ago. Since then I hardly ever practice. It's not that I am bad at them, now, but its just so hit and miss whether an answer will come to me in time, you might as well toss a coin. If I was doing algorithmic stuff every day I have no doubt I would be better. Usually what happens is I get out of an interview and a an answer (or a better answer than I gave) pops into my head. Like I say, might as well toss a coin.
  - cutemonster 6y ago
    It seems you cannot see FAANGs perspective on this There are other people who always fail those coin tosses
u67583 6y ago
She will just say that the process is designed to minimize false positives and the expense of more false negatives. A bad hire is more expensive than a no hire. The problem is this isn't what gets you the smartest people on the planet. A small number might be interested in DS&A to that level, but most are not. They will learn enough to know how to google what they need and move on to what they are interested in. Smart people are constantly getting job offers from coworkers and bosses who move to other companies if they don't start their own. The few smart people who do put in the effort necessary to go to the FAANG companies always leave after getting the golden sticker on their resume. They leave behind them a residue of SAT preppers who have PhD's in inversing binary trees.
- apta 6y ago
  > She will just say that the process is designed to minimize false positives and the expense of more false negatives. A bad hire is more expensive than a no hire. That's what they keep saying. However, it remains to be proven that regurgitating answers on a whiteboard in 45 minutes implies that the candidate is not a false negative, or even a true positive to begin with.
  - edw 6y ago
    We don't care about reality, merely perceptions. "Well I humiliated the person for an hour in front of a whiteboard" is the new "Nobody gets fired for buying IBM."
  - u67583 6y ago
    Someone who able to immediately understand and write out the solution to 80% of hard DS&A questions is at least able to write code. The question is if this is honestly better than generating your own FizzBuzz. I don't think so. I have heard rumors that Google has studied employee performance predictions based on interview score and found no correlation. I would bet this is an open secret and no one knows what to replace it with that isn't enormously expensive.
    - Apocryphon 6y ago
lallysingh 6y ago
I interviewed a lot of people while I was at Google, and sometimes the people were clearly, clearly too anxious to interview. Like one fresh-grad who's hands were shaking. I thought about how much pressure the kid must have been under. You try to help them relax, but you don't have much time, and the whole thing is just so unnatural. Other places I've since been at, and interviewed with, give you a laptop, a problem to solve, and some time. You can focus on the problem instead of the situation much better, and I think that really helps. As an interviewer, it also helps keep some distance from the interviewer. It's too easy to try to micromanage the interview and keep the candidate uneasy. But there's a natural "don't interrupt someone when working" instinct that keeps interviewers more distant when the candidate's programming. Coderpads on video conference, I think, are pretty good when the candidate has a good space to work in. They're in comfortable territory and you can see them by their keystrokes. The interviewer feels like they're getting more accurate data about how the candidate really operates. I just wish it could do keyboard shortcuts better -- emacs users like me hate seeing Ctrl-N bring up a new window. The issue of IDE/compiler/keyboard/keybindings is also there, but that's easier to work with.
- BlahGod420 6y ago
  Microsoft interview. I was just graduating college, and was super anxious walking in to my first interview. The interviewer realized that writing on the whiteboard was going to be awkward for the problem he was asking me to solve so he let me just sit down at his computer while he hung out to to the side and watched me work in notepad. I think that was the best way to do that interview, because the second I started writing code my brain flipped in to code-writing mode and everything relaxed. One of the better interviews in my career.
  - taurath 6y ago
    Nowadays that's "favoritism" in an interview and it wouldn't fly. Everyone must pass through the same meatgrinder (that, surprise, fails people other than white men more often).
_curious_ 6y ago
Over the past few years in tech, I have interacted with and observed (as a fly on the wall) a wide variety of recruiters, hiring managers, etc. from companies as small as a dozen (usually around the time a founder/CEO brings in external "support"). There exists an incredible amount of arrogance and ego among them by-in-large. The best are humble and curious while maintaining clear and direct communication. To be fair, they are often tasked with making important judgement calls sans complete information, though that's the fault of the leadership/culture as to a poor approach.
Bekwnn 6y ago
At the start of my third year as a student, I biked through a record-worthy rainfall to my first interview with a small local games studio. Showed up completely soaked, but sat down relaxed and feeling reasonably confident. (I had done a handful of unity and opengl projects.) The interview started with a bit of small talk, I chatted with one of the guys about Brood War and Starcraft 2. Later during the technical interview they asked me about the difference between private, protected, and public and said I was the only student they had interviewed who had answered correctly which was wild and honestly stunned me for a moment. They liked how in one of my examples of scripting something I had written some fun dialog and I mentioned I did writing as a hobby which seemed like a plus. I talked about which classes I enjoyed the most and how they were challenging/interesting. I did not get a job offer and learned from a friend that I had come off as "depressed and disinterested" (I don't think they realized he was going to relay that info to me...) All I can do is guess that it's a combination from showing up completely drenched and sharing how I enjoyed those "challenging" classes made it seem like I would get quickly bored of scripting... After that, I bombed an interview for a QA role because I went into it completely unprepared for just how much it would differ from a programming interview. Point being those first two experiences got in my head and I basically had anxiety over anything job-hunt related for the next 2.5 years. When I did get a job, I was extremely happy with the interview process (even though I felt I did poorly on it). Here's more or less how it was structured (TL;DR): - Office tour/chat with a programmer who had referred me - quick 5 minute introduction to senior programmers in charge of the technical interview - 1 hour alone in a meeting room with a laptop and 4 written questions (a generous amount of time) - ~15 minutes reviewing my answers with the senior programmers - importantly, they gave me a chance to talk about my answers and when I got something wrong they would simply state that it had an error and see if I could spot it - 15 minutes on C++/memory/performance/behavior quirks (important stuff in AAA games) - ~30 minutes talking about stuff I had worked on - occasionally they would mention something related I hadn't heard about and explain it while gauging how well I could follow along Basically, based on my own interview experience/anxiety if I had to choose an interview method, it would be very similar to what I just mentioned. Seeing a familiar face and the introduction followed by the alone time did a lot to ease my anxiety. The time where I felt most comfortable was talking about the stuff I had done because I was very familiar with all of it/it was easy to talk about. The process seemed less focused on where I had gaps in my knowledge and more focused if I had a decent amount of knowledge in general and if I had the ability to recognize and correct the gaps in my knowledge. Sorry if it's a bit of an info dump, but it's something I think back to a lot.
cmrdporcupine 6y ago
I've trained for interviewing twice at Google. I don't volunteer to give the interviews, though, because the interview I was trained to give, I would never pass. And sadly, this is common and recognized at Google, was mentioned in interview training, and is just said to be part of the fact that the bar gets higher, or something, mumble mumble. I find this disturbing.
- chillacy 6y ago
  Every year I've noticed the questions get harder too. A hard question in 2012 (off the top of my head, 2 pointer solution to linked list cycle detection) might be considered an easy question today.

PopeDotNinja 6y ago

Thank you for posting this.

mpalczewski 6y ago

My experience has been quite opposite. I worked for a FANG and conducted over 100 interviews. Most of that time I thought I was asking really hard questions and wasn't sure I would have been able to answer them if I hadn't seen the question before. I later interviewed at a different FANG, surprised myself and answered harder questions than I typically gave and answered them better than most of the people we hired. Not sure what to make of that.

Apocryphon 6y ago
Looks like being an interviewer taught you a thing or two about the test content.
onepointsixC 6y ago
That sounds like when you spend a lot of time exposed to and walking through certain types of problems led you to getting good at solving those types of problems.

roldie 6y ago

The same is true for design/ux jobs interviews. Well, at least for me. I got laid off a couple of months ago, and have been interviewing pretty steadily since then. I have yet to receive an offer. I already know where my strengths and weaknesses are. I'm fine with 1 on 1s and all that, but when it comes to the technical part of the interview process like a take-home design project or a live design challenge, I usually fail. I know I have the skills. My work has always been well-received, and I've always received good marks on reviews and feedback, but I haven't been able to translate it to the interview process. I've tried to assess where I go wrong, and I think I panic and put too much effort into trying to figure out what they want to see or come up with something innovative rather than just doing the work and following my normal approach. The stress of the time crunch (and sometimes not knowing anything about the product or problem) only add to my inability to improve in this space. -- When I've sat on the other side of the table, I know that most interview processes aren't that well-structured or set up to actually evaluate the candidate. Even when there's a good process, it's often too easy for one person to influence the results. So sometimes I tell myself that it was a crappy interview process and it just wasn't set up for someone like me to succeed. But I still end up stewing over it and feeling depressed for a few days.

ludamad 6y ago
The depression hits those hardest who put their identity into what they do. Often, I don't realize how dependent I am on positive feedback until it hits. Lately, I've tried to remember in those moments that I am a diverse person and that if I looked in the mirror and saw the worst developer ever I would be OK
- dbattaglia 6y ago
  If you’ve been looking for a while I think it’s totally normal to get some deep depression regardless of how you identify. Interviewing is stressful and draining and feels incredibly arbitrary. Also, at least in the US, your employment is absolutely tied to your quality of life; unemployment benefits are a joke and you’re on your own after they run out. I’d be depressed as well. Not saying I disagree with you though, I think identifying heavily with your job makes it even worse.

mycodebreaks 6y ago

Additionally, companies doing common pool hiring are worsening the situation even further. One bad interview day or one failure to solve complex riddle means that you're not good for any teams within that company until cool-off time passes which is typically from 6 months to 1 year. The system of cool-off period is equally brutal.

schreiaj 6y ago

I was on the other side - I flew out to FB during a vacation earlier this year. I got there, could explain the solution but something was off and I kept losing the thread when I went to convert it to actual code. The interviewers didn’t know I’d gotten a call from my cat sitter that morning and one of my cats had to go in for an emergency check up. (He ended up being fine but didn’t know that at the time). Later that week I got the rejection from FB and then, 15 minutes later the positive response from Google. Really made me realize how much impact the day has on an interview outcome.

fermienrico 6y ago
I mean this would apply to going on a first date as well. First impression is what matters and once the impression has been ruined, all bets are off. It is not specific to the interview process.
- 300bps 6y ago
  Rescheduling a date or an interview at the last minute doesn’t make a great first impression either.
  - linkpuff 6y ago
    It doesn't give a good first impression, but failing miserably is somehow even worse...
  - fanimalmanimal 6y ago
    I rescheduled the second date with my now wife at the last minute. Worked out well for us, but I was so tired from work that there’s no way that date would have gone well (busy period of a project at the time).
  - jarjoura 6y ago
    I would LOVE to get my 2 hours back in a day because of a last minute interview cancelation. The only person who would be truly irritated is the recruiter, who's job depends on meeting candidate quotas. Even then, they want you to be successful. Trust me anyone reading this, if you are not feeling well, or something is distracting you, please, please, do feel free to reschedule your interview, even last minute. Once you go through the process, and it's a no-hire, that is recorded in the system and you won't be allowed to try again for some extended period of time. At my company, it's 1 year.

monksy 6y ago

I'm pretty angry with the person that you were. I'm frustrated with the people who look up a question, see the exact solution and walk through and then expect the candidate seeing the problem statement for the first time to walk through it in the same way. There are questions being asked that full academic papers have been written on. What's even worse is typically I get interviewers that are not experienced+prepared enough to give hints or work with you. I am happy that you've had an epiphany to see where you were wrong. If you ever are in a situation to build a quality team. Interview people for the skills to work with others+ teach others, look to optimize, experience, and that they're willing to learn. You'll have a fairly good group of candidates to pick from as that don't do well in these coding interrogations.

StavrosK 6y ago
I bomb on technical interviews the same way because my mind just freezes and can't get through even simple problems. I had the same question you mention. "This is a problem a paper was written on, are you expecting me to derive a whole paper from first principles in half an hour, or are you expecting me to have seen it before? If it's the latter, why not let me Google, as I normally would?" I feel that saying "I would solve this problem with <algorithm>" should be good enough, and if I'm asked to implement it, I should be able to copy paste the Wikipedia pseudocode and start converting.
- monksy 6y ago
  The funny thing about this is: They're not looking for someone that is eager enough to show they're willing to work through it even though they have no idea to proceed. They are looking for someone that got lucky enough to be ready to answer that particular problem, but won't stand up to them that the ask was a bit too much for a reasonable interview that is intended to see if you're a fit for the company and skilled enough to get the work done. They aren't looking for someone that will dress them down to tell them that's incredibly insulting to ask something that took an academic a long time to come up with a solution for that. [Although a rough approach and fairly unfriendly. That shows a lack of desperation, confidence on the knowledge, and a good understanding of the difficulty of the task at hand (heck that's a good signal for won't underestimate points during planning)] (There's a singly linked list question that amazon used to ask that qualifies for this)

yamazaki 6y ago

That's why I think take-home exercises are a much better way to evaluate candidates. Give them the exercise and enough time and you will figure out: 1) How good they are 2) How much they actually care about the job offer -- the more detail and the more passion they put in the exercise, the more into the job they are.

legopiece 6y ago
Totally agreed. I've been in the position to evaluate several take-home exercises during the years and they always produced good results
- eNTi 6y ago
  Doesn't that tell you that the method of hiring is flawed in the first place? If you care to weed out bad candiates, what help are 100% perfectly fine take-home exercises? The only thing that tells you is, that all of your candidates are viable in the first place. Just go into an interview with THAT assumption and ask the right questions. Why do so many companies assume that people who try to get hired for a certain job don't meet the basic requirements? That gotta be the rule not the exception? That's just a bad faith assumption. Just make sure your hire fits into your culture and give them sufficient probation time to grow into your codebase.
  - cutemonster 6y ago
    > > produced good results > what help are 100% perfectly fine take-home exercises? The only thing that tells you is, that all of your candidates are viable in the first place. I think you might have interpreted that, in a different way than what was meant.
- reagent_finder 6y ago
  Could you provide a bit more info? How long were the exercises? Were the applicants evaluated more based on their results or possible writeups? How much did their CV weigh compared to the take-home exercises?
6y ago

u67583 6y ago

It's not just nerves either. All interviews, but especially FAANG ones, are random. The interview might be racist, sexist, etc. They might have gotten divorced that day. The question they ask you is something you haven't heard of but they spent their PhD on. You can even do everything correctly, but the interviewer doesn't like the way you did it. The leetcode stuff is just masochism. You will spend X months beating DS&A into your brain until someone can pullout a random question and you immediately know what questions to ask, what steps to take, and how to write it out on a whiteboard.

VRay 6y ago
I agree with you for the most part, but Google goes out of its way to force the interviewer to just hand in an emotionless, gender-neutral description of the candidate's code and coding performance to a hiring committee that makes the decision This kinda bit me in the rear when I applied to Google a couple of times. As a nerdy American male, aged 22 to 40, with above-average people skills (for nerds) I got along great with everyone I talked to. But the hiring committee would get a sloppy page of half-functional garbage code, along with a note like "Seems like a great candidate". I found another FAANG company I fit into a lot better anyway, so it all worked out great
bananaface 6y ago
It's difficult to remove that randomness from the process. As I see it the only reliable approach for both sides, given that structure, is volume - you just do/conduct a lot of interviews and evaluate/get evaluated on the top percentile.

bumby 6y ago

I've heard HR optimizes processes that limit Type I errors (false positive) at the expense of Type II errors (false negative). I've often wondered if this is because, from the HR perspective, false positives are much more costly. I.e., Those who would be helped by limiting the false negatives are project managers who are too downstream in the process for HR to care.

foolmeonce 6y ago
I think the problem is HR itself. Few companies should be large enough to warrant full time HR, but even small companies need many.. HR are specialist in expanding the disconnect between people the company thinks it needs and people who are willing to work for it.
- bananaface 6y ago
  You say that, but look through this thread. HR has a solid understanding of what a given company's large-scale objectives are when hiring. As evidenced by most replies in this thread, technicians on the ground do not.
  - foolmeonce 6y ago
    The evidence is that it is a hard problem that is not solved. No amount of people who can't do the task demonstrate the existence of experts who can. Google and Microsoft have shown us examples of failing at simple HR tasks for years or decades with budgets for HR that dwarf a small companies entire payroll. What virtually every attempt shows is that it is better to hire people who are roughly qualified and see what happens, managing the results instead of filtering. Having an HR strategy for hiring leads to creating biases (i.e. requirements based on your current work force) that gets you a group of overly similar and therefore collectively incompetent work force.
timClicks 6y ago
Yes this. Hiring the wrong person can be ridiculously expensive, especially if they linger on in a role for years corroding the culture.

fragmede 6y ago

Where engineering fields have a disproporationate number of individuals with ASD (née aspergers), and where anxiety plays a large part of the syndromes, it's no surprise that many, many good engineers are terrible at interviewing.

marta_morena_25 6y ago

I am focusing on the algorithmic part, which is the only thing I can influence in my company's interviews. I wish we would evaluate candidates with some pair programming, but that's never going to happen. > incredibly high stakes algorithm riddles Yeah there you go. This is your problem (Google/Facebook I assume?). It's more than questionable to expect candidates to solves complex algorithmic problems on a whiteboard in 45 minutes. You should ask moderate algorithmic questions that offer many solution approaches and accept solutions that are "good enough". It is not about having a candidate gaining some magic insight that some MIT student had 30 years ago during his master thesis (and reproducing it in 20 minutes lol). It's about giving a reasonably complex problem, that is not too easy but also not too difficult and allows you to focus evaluation on: * Does the candidate write proper code that isn't far from compiling? (If they can't, they don't have the experience. It's like not being able to write without a spell/grammar checker. Small mistakes are fine. Big mistakes indicate lack of understanding.) * Does the candidate have a structured approach to problem solving (all the time I see people starting to write code immediately and getting completely lost in what the problem even was. This is a red flag to me and baffles me each time again.). * Does the candidate debug his code and walk me through. Does he find obvious bugs while doing so and can he convince me that his code works? (If not, and that happens often, its another red flag) * Can he rank the speed of his solution with other theoretical solutions? Let's say they found an N^2 algorithm. I usually ask if there is anything faster (even if there isn't). This shows if they have some decent fundamentals in CS and are able to think about the boundaries of an optimal solution and how far they are from it. This is something, people without a CS major usually can never do and unfortunately also not too many with a CS major. It's kinda relevant though, if you optimize for performance and have no clue what the theoretical limitations are, then you are grasping for straws. There is one big secret for getting A LOT out of easy questions: I start to modify the problem statement and see if they understand how this changes their solution and their algorithm. People who don't have a good grasp of CS will fail miserably at this task, because this isn't something you can memorize.

aprdm 6y ago
pivotal does pair programming interview. The morning with one person in a theoretical problem and afternoon with another in a real problem. I liked the experience and the process, in the morning it was a blast. We really clicked. In the afternoon I had to use the same setup as the guy I was collaborating with -- Vim with his bindings and Golang. I had never used Golang before and even tho I was proficient with vim his binding were quite opinionated. I felt the guy from the afternoon had 0 interest in being programming with me. He wasn't collaborating and was looking at his cellphone the whole time. The problem was to write a functional test for a CLI that would spawn a web service in Golang, parse some json and run some assertions. Golang had some quirks with JSON and new line encoding that I spent my whole afternoon with. It is something he could have unblocked me as it a very specific problem, instead he kept telling me to read the official golang docs, not even to google the error. As someone being interviewed I followed what he asked me to do and worked in his environment but it wasn't a representative of how I would have worked. That said, I feel it could work! I just should be able to judge the person who pair programmed with me instead of just being judged :) the person in the morning would be a 10/10 and in the afternoon a 4/10.

markandrewj 6y ago

It's also sort of ironic how studies repeatedly show high preforming teams, are cognitively diverse teams. Even though research shows this, the hiring strategy of most technology companies, is hiring new employees with the same skills, and traits, as current employees. https://hbr.org/2017/03/teams-solve-problems-faster-when-theyre-more-cognitively-diverse https://hbr.org/2017/03/teams-solve-problems-faster-when-the...

CobrastanJorji 6y ago
This is a critical point that a lot of hiring misses. We talk about building great teams, but the hiring requirements are static and never seem to consider who's currently on the team and what mindsets or backgrounds are missing.

lumost 6y ago

Senior/Principal Engineers at FAANGs may not even code all that much in their day to day. The difficult decision that gets faced when interviewing those folks is whether they could walk into a fresh environment, and stack, and immediately earn the trust of their team. In practice whiteboard interviews assess this pretty well. A new senior engineer must immediately be shipping optimal, tested, and well designed code. Otherwise you'll have Junior Engineers coaching Senior Engineers and the Junior Engineers will just get frustrated and leave. Worst case, you'll have an "architect" who never learns how to actually deliver independently in the environment.

mianos 6y ago
Any significant system will take months to learn. Your statement is probably only true for some trivial system. A senior engineer comes with years of experience designing and coding systems that took years to develop and run at scale. Given time to learn they should be just as good at solving day to day bugs but if you assign them that you are wasting your time and money on experience. If you don't value experience you are wasting your time and money on experience. It's pretty normal to have more junior engineering staff help new senior staff learn the ropes. It's also common for those less experienced staff to learn from the more experienced people even in that situation. I'm not saying senior hires should be respected from the first second because they are over 30 or have a long resume.
- lumost 6y ago
  Learning the ropes of a new company is fair and being slower at first is to be expected, but explaining that code reviews need to be tested to a senior hire isn't as fair. Similarly a new senior hire should be able to hop into a code review and catch problems/suggest improvements early in the process. These two behaviors aren't as dependent on knowledge of the system as they are on core coding competencies. The whiteboard interview reasonably works to assess these, but it requires a lot of prep and is prone to false negatives.

ghostofdarwin09 6y ago

Have done over 1,000 interviews for a FAANG competitor that IPO'ed in the past 10 years. Completion time (in minutes) of a coding puzzle is essentially the only objective measurement taken during these coding puzzles, and is sadly the primary datapoint fed into the hiring manager's decision. The hiring managers usually adjust the cutoff based upon whatever quota they want and/or if they're expecting people to leave. I've worked directly with a VP of Engineering and that's really all he wanted to hear. The whole process is missing a feedback loop to the evaluators, resulting in the OP's situation. In my own situation, it took several years after that mess of being forced to shotgun candidates to pick apart what in the experience was actually predictive of success and what wasn't. To this day, the most successful hires from my perspective were those who just really wanted the job and wanted to contribute to the product; definitely no strong correlation with "leetcode" ability. It's not just that the coding quizzes are poorly administered, but that the hiring mangers and leadership industry-wide have been obstructive to getting evaluators feedback (for starters, what did a candidate's other offers look like? where were they 3 months after the interview?) and especially tight-lipped on sharing interview questions. That last bit is particularly obnoxious because people monetize their insider knowledge either through things like Rooftop Slushie or they take a more Gayle Laakmann angle. (Just to be clear: while many questions are "protected under NDA," many questions are also stolen from other companies-- interviewers asking them are already violating their own NDAs when asking them, or potentially when feeding the question bank of their new employer). What you can do is go to your manager in your 1:1 and ask for interview feedback. Ask what happened to candidates 3-6 months after the interview, even if they were hired (perhaps not just to your team). Start to get feedback, and then work from there. You'll probably do better interviews, and at least curtail some of the information arbitrage culture in the C-suite.

bananaface 6y ago
Occam's razor is: algorithm tests are specialised IQ tests, and that version of IQ is actually a very reliable indicator of performance (compared to the other signals available). I'm not exactly sure I buy it, but it seems like the simplest explanation.

tchaffee 6y ago

The best advice I ever got about interviews is to figure out ways to prove yourself wrong about what you think about the candidate. Although it's good advice for a candidate who seems too perfect, this advice really shines when someone is bombing.

cmonnow 6y ago
That advice seems like unnecessary mental gymnastics. Just take an unseen technical problem, solve it for the very first time in front of a colleague, then double your time as the expected time for candidates in an interview. When you're under time-pressure, you actually spend more time thinking about how much time you have left, rather than thinking about how to solve the problem.
- tchaffee 6y ago
  It's not mental gymnastics. The point is to challenge yourself as an interviewer to reveal a diamond in the rough. Some people suck at interviews and are great at coding. I've hired a lot of them and we've made a lot of money together. I've never had to fire anyone either so I'm not getting false positives either. > Just take an unseen technical problem, solve it for the very first time in front of a colleague, then double your time as the expected time for candidates in an interview. That gives very poor signal in my experience due to the time pressure. Your process is now selecting for people who are good at taking tests instead of selecting for good engineers.
deleted 6y ago
[deleted]

aantix 6y ago

I call these high stakes interviews "the perfect dismount". You can feel the pressure mount - any algorithm that doesn't run on the first try or second (with a couple of quick fixes) and you're being mentally discounted. The same for silence - if you're thinking through something, take abnormally too long, you're discounted. The Perfect Dismount. A 10.0 is what's needed to land a FAANG job.

1qaz2wsx3edc 6y ago
I just pulled out my laptop and if they aren't cool with the solution I google'd in 30 seconds, they can test my critical thinking in another manner. That was my critical thinking and resolve under pressure. These are nothing but shit test. What are shit tests? When somebody fucks with your head to see how you will react, what you are experiencing is typically a (series of) shit test(s). Everyone has been shit tested, gets shit tested and will continue to be shit tested; We use shit tests to make value judgements about people, likewise they can be used to determine how people cope under pressure. The underlying mechanism of shit tests is to test your mettle.

xwolfi 6y ago

What some of us do now is at home exercises with no deadline and setup the interview to do a code review of it after it's given back. It gives so many advantages: - people will have some fun trying to solve a real issue / build a little software - they will show how good they are at stack overflow, general methodology, cleanliness, test coverage, deployment and even git (how many we see who can't even gitignore their project files, make a build script that works, or test for real) - horrible candidates who can't even cheat will not be able to lie their way around a fake resume, cheaters will bomb the code review quite fast - candidate will also discover their future team mates general work attitude during the review and if the reviewer is good, will lock the candidate faster than "how many billard balls can you put in a Boeing 747" type of interview. - candidate will even LEARN during the code review => you get away with something out of the interview even if you fail Since I've been interviewed that way, doing my little project on my wife's pregnancy bed smiling like an idiot at solving the challenge, then fell in love with my manager showing me new tricks during the review, I'll never do any other kind of interviews myself.

tchaffee 6y ago
I recently did one of these where I was paid at half the hourly rate of the job offer. There was an initial unpaid assignment that was difficult but totally related to most engineers' day to day work. That took less than 30 minutes. Anyone who passed that got the paid assignment which took a few hours.
- bananaface 6y ago
  If I had options I wouldn't even do a 30-minute assignment. I'd just go with someone else. I'm reading about employers giving assignments a lot in this thread, but what do you do about the fact that the people you really want just don't have a reason to waste that time?
  - tchaffee 6y ago
    There was no interview. Not even a phone call. After I submitted the 3 hour paid assignment they hired me by giving me access to Slack and we just started working together. One of the smoothest and easiest "interviews" I've ever done and I got paid for everything except for a 30 minute challenge that helped solidify my understanding of git. > people you really want just don't have a reason to waste that time I'm "really wanted". In the past week I have had to say no to two clients calling me for follow up work. Where do you think I wasted my time?

nathanvanfleet 6y ago

Couple that with 45 five times over! I was flown down for a Facebook interview from the east coast. It was my first tech interview and it was with facebook. I was so exhausted by it, and then the next day I had an interview at Uber. I started that one already pretty tired.

Cthulhu_ 6y ago

I much preferred our style of (technical) interviews (I took on a few dozen over the years). First there's a review of the CV, Linkedin, and github, if that looks good, a first interview - just get to know the person, very casual. If that clicks, second interview is the technical interview - we did that by giving the candidate homework, 4-8 hours worth of tasks that are close to their day-to-day work, usually something with a REST API, some basic math/arithmetic, and a front-end / forms, and plenty of room for the candidate to play with. It was received pretty positively; especially early on (2012-2015) we had a lot of candidates indicate they had never done anything with JSON or REST before. (later on they mentioned having done nothing with XML before, lol). And we got to see some interesting solutions and creativity; one guy we hired did it all in J2EE, while we were a Spring fanclub. But the code was sound, he showed that he understood how it worked, etc. The conversation during the technical interviews were entertaining as well.

cutemonster 6y ago
> basic math/arithmetic Can I ask for some example(s) of what type of questions you asked?

arethuza 6y ago

I learned this lesson a few years back when I interviewed for the CTO role of a educational software company - the main part of the interview was preparing a presentation on how to launch a new product which I had to prepare and present to the management team. That went very well and I was feeling pretty good. Then the CEO had a quick chat and happened to ask me a very simple technical question and my brain would not work - I completely failed to do it even though it was trivial. I think that's how I discovered that mental context switching is a real thing - I had spent a few hours preparing and giving a presentation and then when asked a simple technical question those parts of my brain were completely offline. I think the shock of not being able to do it had a big effect on me and I went to bits (possibly the first time I've ever done that).

touristtam 6y ago
> I think that's how I discovered that mental context switching is a real thing You had to go to that level to understand that? I am glad you did realize it, but I am surprised it was that late in your career.
- arethuza 6y ago
  I'd probably heard about it but I'd never had it really hit me like that before.
  - cutemonster 6y ago
    How did the CEO react / say? If I may ask

ryder9 6y ago

you're an arrogant prick

dang 6y ago
We've banned this account for repeatedly breaking the site guidelines. Please don't create accounts to do that with. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

soamv 6y ago

I'm so glad this realization is the top comment on HN. I think Fizzbuzz can be actually a reverse test: if an experienced programmer can fail fizzbuzz in an interview, then maybe it's the interviewer who screwed up.

justinlloyd 6y ago

For three years or so I taught week long corporate training classes at Apple, Microsoft, Facebook, eBay, PayPal, Cisco and Intel. Every week, week after week, real rocket-science level Android and iOS deep-dive in to the guts of the operating system classes dealing with firmware and device drivers and file systems. In the classes we didn't build apps, we built operating system components. Small to large classes, thousands of software engineers from senior and up, over the course of those three years. I would stand up in front of 80 or more engineers, go in to esoteric aresa of the operating and talk eloquently and at length about the structures and code found there, and live code on a projector, answering questions about the code and debugging the code of everyone in my class as they followed along. Day-after-day. 40+ hours a week. It was intense. I became an independent advisor to teams and a consultant for some of the groups on how to bring up Android on new devices, create device drivers, and so forth. Some of those classes, I wondered how some of the people I was teaching was actually able to hold down their job. Months later, after I stopped teaching, I interviewed at Intel and PayPal and Cisco. I bombed every interview. I was, by all accounts, unable to program my way out of a wet paper bag. Everyone has off days.

lazysheepherd 6y ago

I've done my first programmer hiring for my startup several years back. Thankfully I've came across Guerilla Guide to Interviewing[1] article by Joel Spolsky, and that helped greatly. I've interviewed 6 candidates within a week, and hired one. Never regretted of the outcome. I've set up a test code so: an input variable, comparison variable, and an empty function. Function takes input variable as an input, and output of which is compared with comparison variable. Interviewee would be asked to fill in the body of the function, and play with it until function gives the expected output. I've set up a computer with two screens, put IDE on one, and Google on the other. Two chairs, and some coffee. First I've chatted with the interviewee for about 10 minutes, tryin to make them comfy as possible. Then before the test, I've stressed very much that I am also a programmer, and I know how awkward it is to be coding while someone watching, and that'd alone would make me do silly mistakes, so I was expecting same from them and that was completely OK. Afterwards, I've encouraged them to use Google in plenty, and feel free to stay silent or explain as they go. So I got to assess their fluid intelligence, their ability to break the task down and progress efficiently, their English proficiency[2] (if they use Google in English), their usage of keywords, their choice among in stack overflow responses, etc. At the end I've rejected a guy with 8 years of experience on his CV, and hired a junior. Looking back, that turned out to be an amazing decision, best I could have made, for work went good with the junior and I've had the (mis)fortune of working side by side with the 8yr guy several years later. PS 1: Task was to write a recursive function to travelse a multidimensional array, and find out whether the first letter of every "value" was a capital letter. PS 2: The work was to maintain and develop mid-scale SaaS project along with me. 1: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... 2: Country's mother language was not English, and English proficiency was not good on average.