14 ms·

I would pass the shit out of this question because it's right in my wheelhouse, but I don't consider myself a particularly exceptional programmer. I have a CS d

• jokethrowaway 5y ago
  In my team I need someone like you to deliver features, not someone that can leetcode. I don't remember the last time I had to check an algorithm in Wikipedia. Probably 2-3 years ago. Most of the time it will be debugging some arcane crap or adding to an existing codebase, anyway.
  • bornfreddy 5y ago
    Algorithms are funny this way. Most of the time you don't need them, but when you do (and if you don't, you can't tell it when), it is a world of difference. Still, just knowing they exist and how to formulate the search is usually enough.
  • treffer 5y ago
    100% this. I have "The Art of Computer Programming" on my book shelf, and I think I had to pull it out 2-3 times over the course of _years_. I am sure one was a reference in the golang source code. And I once wanted to check multi-way merge sorts (tournament sort).
• ankrgyl 5y ago
  I think "necessary but not sufficient" is an accurate way of capturing our goals for the interview question. Some really great candidates felt just like you do about the question, and we learned over time how to present it to senior candidates in a way that did not (at least in my experience) trigger that reaction. That said, there were also plenty of candidates who came to the question guns ablazing with the same attitude, and then failed miserably. I'm not saying that's you -- but rather that it worked out in practice to be a fairly good filter for whether people actually had (enough of) that skillset.
  • Diesel555 5y ago
    > but rather that it worked out in practice to be a fairly good filter for whether people actually had (enough of) that skillset. How did you rate your negatives to judge the filter was correct? You know the "Positive" status, you know your true and false positives from the interview question (People you hired that performed well or didn't. Or said another way, the predicted value was positive while true value was positive or negative). But did you know your true and false negatives (the people you didn't hire that would have been good or bad. Or said another way, the predicted value was negative but true value was positive or negative)? Did you know the candidates you rejected who would have been good at fulfilling the roll at your company (False Negatives)? To be clear, I don't know the false negatives either and the interview question may be the best litmus test for the behavior desired, minimizing false negatives and maximizing true positives. But I just don't know for sure if the question did work out in practice to be a good filter of people with that skillset without a true negative dataset. The Precision is good, but the recall/sensitivity may not be. Then again, you probably know how the candidates you hired performed before you used the new question and after - which may be an indicator on false negatives. Also, that does seem like a really fun interview question to answer for me. Kudos. EDITED: Changed the question at the same time the response came from OP. Original post asked if they hired those who failed the test to know more about the negatives. They did.
    • ankrgyl 5y ago
      We did hire people that failed the test.
• throw1230 5y ago
  > 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 advanced prep.
  • hinoki 5y 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 5y ago
      What kind of practice did you do? Leetcode exercises or something else?
      • oh_sigh 5y 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 5y ago
          > Be honest if you've heard a question before Why so?
          • MAGZine 5y 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
• and0 5y ago
  > That doesn't mean I need to understand the entire code base, but if I'm modifying a portion of the code base, I'm loath to touch it till I understand what it's doing. This is also me. I get flack for spending too long on what seem like "small" fixes but I can't be sure (especially in spaghetti code) until I've dug through it. On a couple occasions, different companies unfortunately, I caught flack for spending too long trying to understand critical finance code. As in, how we were billing every single customer. But it always yielded results, and a week later I'm in a meeting explaining how abc original implementation would have broken xyz, but the scowls never really go away. It's frustrating.
  • lukeck 5y ago
    This is why diversity of thought is important in teams. Some people will be the “ship, ship, ship type who make sure that the team is meeting its goals. Some will be detail oriented, may frustrate the first type but will ensure the team is producing quality results. Some people like to be on the bleeding edge and bring you techniques to the team. Others like to clean up tech debt or bring incremental improvements to old solutions. All of these are valuable even if they at times frustrate each other. These are generalisations. There are likely far more “types” and different people will act as different types in different situations. Having a mix isn’t sufficient though. The team also needs to find ways to prioritise and manage conflict to get the best approach in place for any given situation.
    • pards 5y ago
      > diversity of thought Thank you. I've never had a phrase to adequately describe how I like to balance teams and "diversity of thought" fits well.
  • jseban 5y ago
    I'm in the same camp, I don't even understand why programming is done under constant artificial time pressure, why are programmers constantly hounded and stressed for no particular reason? Nobody is really waiting for this task, it's an old well-known bug, or just a new additional feature but OMG HOW LONG, ARE WE DONE YET!?? Edit: same thing in this interview question, the whole point is super quick performance and working under time pressure, and making changes to code bases that you don't have time to understand, why?
• irjustin 5y ago
  > I'm positive I'd fail a FAANG interview w/o advance prep This is okay and to be frustrated at it, but it's important to recognize why it's happening. FAANGs go through an incredible number of candidates with only a few slots (comparatively) and the point is to simply make the bar higher and higher. Just like a pragmatic engineering - you have a 'good enough' candidate set. For me, the problem is when smaller startups copy the format - expecting candidates to jump through all the same hoops. If a FAANG has 1:100 position to interview candidates ratio, a startup will be lucky to have 1:5 (it's incredibly expensive/time-consuming for a startup to interview). Running the same test likely means you're rejecting a lot of potentially good candidates who didn't want to go through a 'FAANG' interview.
  • b112 5y ago
    FAANGs go through an incredible number of candidates with only a few slots (comparatively) and the point is to simply make the bar higher and higher. This doesn't fit the "we can't find candidates, so we need more H1B's" narrative. Supposedly, there are many open slots, unfilled, so purposefully failing people which can do the job, which meet the minimum requirements, should not be the outcome. Instead of raising te bar, as you say, due to candidates o'plenty.
    • irjustin 5y ago
      > This doesn't fit the "we can't find candidates, so we need more H1B's" narrative. I disagree. In fact, this validates it. On the basis of a world-wide talent pool vs a domestic. If you know there are stronger candidates elsewhere then you absolutely want to test away the domestic candidates. Thinking about it from a hiring manager's perspective. You don't lower your standards just because a specific pool of candidates can't meet your criteria when you can widen the pool - as far as you are able. If the H1B candidates were tested on a 'easier/weaker' test the I would 100% agree with you, but I'm assuming things equal here. And, ignoring any thing related to domestic vs foreigner workforce, "people taking our jobs" debate.
      • Scarblac 5y ago
• ta183858 5y ago
• matwood 5y ago
  I don't know if I would have passed the exact question, but something like this is also in my wheelhouse. The other thing that I value very highly is consistency in any given code base. However things are already done, is how I'll keep doing them, unless there is a good reason to change. And to your point, that reason cannot be I don't understand the code. IMO, too often people want to make big changes w/o understanding (b/c understanding can be hard), and end up missing the reasons why the code was hard to begin with.