11 ms·

> but I'm positive I'd fail a FAANG interview w/o advance prep I work for a FAANG company in a senior position and I know I will fail FAANG interviews w/o adva

• hinoki 4y ago
  I work for a FAANG company in a senior position and I did fail FAANG interviews w/o advanced prep. The second try I practiced.
  • codetrotter 4y ago
    What kind of practice did you do? Leetcode exercises or something else?
    • oh_sigh 4y ago
      I've worked at 75% of FANGs. My method was basically just bone up on algorithms and data structures by going onto the Wikipedia list and trying to implement them on pen and paper. Practice thinking out loud, practice space management(no backspacing on pen and paper). Be honest if you've heard a question before. Know how to analyze runtime of your algorithms. I chose to interview in python, even though I know other languages better, because it is fairly dense relative to, say java or c++ and easier to write by hand.
      • GoOnThenDoTell 4y ago
        > Be honest if you've heard a question before Why so?
        • MAGZine 4y ago
          If you waste your only evaluation period on a question obviously regurgitating an answer, interviewers notice and can't evaluate you fairly. If they just want to watch you program, they might still ask you to go ahead, at least you've put the ball in their court. If they think you weren't forthcoming, that might be an automatic rejection
          • linspace 4y ago
            > can't evaluate you fairly. What's the meaning of fair? Several people admit you need to prepare, and then it seems you should not prepare too much? It looks like a date.
        • deleted 4y ago
          [deleted]
        • mattm 4y ago
          I can't reply to the sibling commenters but providing a contrarian opinion. I'm an interviewer and there's no way for me to tell who is just really good vs who has seen the exact question before. Telling the interviewer just gives them information that goes against you so I wouldn't recommend doing this.
          • ignoramous 4y ago
            I guess, it is okay telling your interviewer depending on your comfort level, as most never change the question regardless. That said (and as another commentator points out [0]), if an interviewer asks you call out questions you know of from before, then you most certainly should (unless you can sell the bluff...). [0] https://news.ycombinator.com/item?id=31067269 https://news.ycombinator.com/item?id=31067269
          • kitd 4y ago
            Does honesty go against you in interviews these days? I'm getting old.
            • weatherlite 4y ago
              It does in this case yes, how would you see it as an advantage? You have to pass X number of algo/data structure, your being honest will only make them find a different question. If you get the different question wrong guess what you are out. It is what it is.
              • bornfreddy 4y ago
                If the hiring process is set to punish honesty, then maybe by being honest you avoid working at places with such a process and consequently with the people who passed it? Note that I'm not saying that FAANGs are like that (I have no opinion on that).
                • weatherlite 4y ago
                  It's not punished but it's not massively rewarded either
        • roganartu 4y ago
          When you’re an interviewer and you’ve asked the same question enough (tens of time is plenty, really) you’ve seen it all and it’s really obvious when someone has seen the question before. People who haven’t seen the question before always stumble somewhere. There’s something they didn’t notice at first and need to account for, their solution is not structured optimally for the follow ups, they iterate over some possible solutions while thinking out loud to eliminate them etc. It’s honestly not that hard to tell when someone is pretending they haven’t seen it before.
          • naiwenwt 4y ago
            As an interviewer I find it easy to catch candidates who are regurgitating a memorized answer, but catching people who know the answer in-and-out is really hard. I've had the exact same experiences on the interviewing side of the table as well. I think interviewers tend to overestimate their ability to catch people who have seen the question before and miss on tons of candidates who are good at answering seen questions.
          • saagarjha 4y ago
            It's actually not all that hard to stumble on the question at predictable spots. My process for solving a question I've seen before and one that is new to me actually doesn't differ all that much: as several clarifying questions at the start to confirm I understand the problem, then write a quick-n'-dirty solution as fast as possible. In this first pass I usually don't pay too much attention to things like bounds, which you wouldn't memorize anyways even if you knew the solution. Then I run a pass to polish the solution up, present it, then think of edge cases and how I'd test the solution. The only real difference is that I very rarely pretend not to have seen a question (I have done it twice, both in situations where it was clear the interviewer was out of questions and running down a list of things from memory, and I just wanted to humor them). You'd think that I'd be more sure of myself when I actually know the answer, but when I don't actually know what I'm doing I will usually come to the answer as I ask those clarifying questions and start stating the facts that usually score "this person at least has the gist of the problem" points, like "oh this is a graph and we're doing something with distance, let's see if Dijkstra is the right thing to apply".
        • gigatexal 4y ago
          I don’t work at a FAANG but I hope to one day. But I do interview for Data Engineering roles from time to time for my and other teams. I think by saying you’ve seen this problem before it shows honesty. It shows character. Those are points that, at least for me, are positives and I like to hear it. I’ll still go ahead with the question just to make sure but if something typically takes 30 mins and you finish in 10 then I’ll move on to a different question to fill the gap.
        • aneeshnl 4y ago
          Interviewer here. When a programmer goes through a question fast and jumps right into the solution, there is two possibilities. One is candidate already knows the question. Two is candidate is exceptional programmer. If the other part of the interview doesn't match up to this, then we will assume the first case. I definitely place candidates who are being honest upfront above others. They will be reliable and trustworthy, which is important quality for programmers.
          • bg24 4y ago
            First principle that every interview guide teaches you is to take time to understand the questions. A candidate who has spent months preparing for a FAANG interview will highly unlikely rush into answering a question, even if they have seen the question before. One reason for folks to jump right into the solution is the interview anxiety - which is both due to lack of practice and trying to compare oneself to folks preparing for months ahead of interviews.
        • Bahamut 4y ago
          As someone who has done a lot of interviewing from the interviewer side at my current FAANG, it's usually obvious when someone has seen the question before - in the debriefs, the candidates who were honest have it noted out loud to the debrief panel & it makes them look good due to integrity, and those who were dishonest also get it noted as a significant negative. Perhaps I evaluate differently than a lot of interviewers, but I'm primarily interested in figuring out if a candidate has the traits/skills that I'm looking for in a potential coworker - for us, the traits matter more than the skills even.
          • weatherlite 4y ago
            It's better to fake having not seen it than failing an unseen before question. No amount of honesty points will save you from failing a question. Sure if you are good enough that you pass unseen questions regularly go with honesty. If you are not, better to fake it. If FAANGs have problems with candidates knowing the questions maybe they should think of different interviews?
            • Bahamut 4y ago
              My coding question I give (in the occasion I am called upon to ask one to candidates) typically is not particularly unique, but practical - if someone wants to study for it, it doesn't really give them a notable edge given all the possible branching questions. The most notable tell if people did see the question prior though is if they jump right into talking about the problem without asking qualifying questions, implying that they are quite familiar with the problem & don't need me to qualify it & don't think to verify scenarios with me. For my non-coding problems, I just create it from scratch depending on the position/needs & spend a bit of time navigating the scenario myself and store the question in my notes. As to failing a question, failing a single question isn't necessarily a deal breaker in itself - it's showing a pattern of not meeting the bar that is. I may rate someone a 2 out of 4 if they didn't go into sufficient depth in a particular question I asked, but I probably won't stay in the way of hiring them if they did ok otherwise and that failure was just an aberration. Loss of integrity is perception that is likely to sour people on any upside of hiring though, and overcoming that bar is incredibly difficult - if someone is clearly rehearsed on a particular question and is dishonest about it, they're probably not getting a 3 or 4.
        • randomswede 4y ago
          If this is the first time, at the same company, it (probably) does not matter, that much. When I was an interviewer for a (second) technical phone interview at Google, one candidate performed pretty bad at one question. Later that week, or maybe the following week, that very interview was in the pre-HC meeting and one of the other pHC members pointed out that I had repeated a question from the first phone interview. At which point I pointed out that I had not been provided a list of previously asked questions, the candidate had not highlighted it, and the candidate's response was still sub-par. Not mentioning the repeat counts against character and responsibility. Not performing better at a repeat question a week later counts against competence. That was an easy "let's not bring this candidate on-site" decision.
    • hinoki 4y ago
      I did problems from Elements of Programming Interviews, on paper, while talking out loud about what I was doing. I would have used a white board if I had one, or a google doc (non-ide text editor) if I were practicing for a remote interview loop. I tried to do one problem a day, capped at 45 minutes, plus a bit of time to confirm my answer if I got it, or understand the answer of I did not. My goal was to practice things the interviewer is looking for, in a setting that is as close as possible to an interview (no ide, time pressure, etc.) * Alternative approaches to solve the problem. * Test cases, including walking through some. * Runtime/space complexity analysis. I didn’t have a good study plan for design interviews, but I’m better at YOLOing those :)
  • teaearlgraycold 4y ago
    I YOLO’d the Google interview two times. First time I failed. Second time I somehow passed. It can be done. Might have gotten a higher level with studying but I don’t think I would have ever studied.
    • randomsilence 4y ago
      Off-topic: If YOLO and you want to join Google, wouldn't that be motivation to study?
      • Bahamut 4y ago
        Unless you view it as not worth the effort. I've done two onsites with Google in the past essentially YOLOing it (I only study my interview failures because I view otherwise as an inefficient use of my time) - first time did terrible, second time almost passed if I didn't completely bomb my very last session. The second time ended up not really mattering because two different teams in two different orgs for my current non-Google FAANG wanted to hire me after onsites done on back to back days (side note: that was almost 15 hours of interviewing in two consecutive days - that's a lot of time, I only was able to do it because I was funemployed at the time). I actually appreciate it very much if a candidate didn't study & focus more on giving the best answers to their capability when I interview them - the questions I give them are usually questions that no amount of studying would have prepared them for, so already taking the mindset of trying to respond thoughtfully & earnestly to problems & situations that change on a whim puts them a step ahead.
      • teaearlgraycold 4y ago
        I studied for the interview I wanted (by being a thoughtful software engineer in my day job) and not for the interview they offered (which would require me to either be a professional leetcoder or some algo/performance expert). If they didn’t want a good software engineer then they’d have to pass on me. I made it clear in every session that I was thinking through the problem, asked good questions, and when there were aspects I could write concrete code for I did. If you score by solution competence and performance I think I aced 2 of the coding sessions and did pretty mediocre in the other 2. My interviewers must have been willing to go a bit off of the default mode of operation as I managed to get an offer. I don’t know if interview performance has anything to do with negotiating power, but I was able to get damn near the highest possible total compensation my level allows for without a competing offer.
  • 0x20cowboy 4y ago
    Do any of the interview questions you had, or studied for, have anything to do with your day to day job?
    • FranksTV 4y ago
      I got a job as a front end developer. We had a ton of streaming data and needed to index it in the front end. The "right" solution would be to fix it in the back end so that we didn't fetch all that data when it wasn't needed, but that wasn't possible because of the horrific project/product management. So I had to build binary search trees to index the data so we could work with it fast enough to have a reasonable user experience. So yeah -- you will need some of this stuff. You're constantly going to be searching for things, reversing things, looking for patterns. it won't be so clear and abstract, as a leetcode puzzle but the reason why I had to write that binary tree was because whoever came before had clearly never considered using one and was doing everything completely wrong. It was a disaster and made the codebase insane. If they filtered in the hiring process for people who know the basics then things would have been a lot more performant, and they wouldn't have burned so much time working around the performance issues caused by his terrible solution.
      • 0x20cowboy 4y ago
        Interesting, thanks for that.
      • dolni 4y ago
        I would add to this that while knowledge of computer science algorithms and data structures is _absolutely_ useful, being able to implement a binary search tree RIGHT NOW, in under an hour, is not necessary for... pretty much any job anywhere.
      • mithr 4y ago
        I absolutely agree that hiring folks who are aware of the basics is important -- essentially, you want engineers who are aware of the space of possibilities. In my view, what makes folks dislike typical coding interviews is that in the real world, what you need is a solid understanding of what algorithms exist and when to use them/what to look for, rather than the knowledge of how to build one on-the-fly. To solve the issue you described, you don't need to know offhand how to implement a binary search tree on a whiteboard. You do need to know how to identify indexing as a bottleneck, and how to broadly think about a solution. You could then search for indexing strategies and, having studied them at some point in the past, you'd be able to pretty quickly refresh your memory and find the one that's a good fit for the problem at hand. For this reason, I've always thought these exercises would be much better off as essentially "open book" rather than real-time whiteboarding problems -- because that reflects how engineers actually work. That's also what I've pushed for in my own workplaces, and we've had good success finding talented folks, and heard positive feedback about this aspect of the process.
• actually_a_dog 4y ago
  Which is patently ridiculous, IMO.