[HN Gopher] Big Tech Coding Interview Framework - Pt 1. Inspect
       ___________________________________________________________________
        
       Big Tech Coding Interview Framework - Pt 1. Inspect
        
       Author : ckcheng
       Score  : 71 points
       Date   : 2021-11-06 17:42 UTC (5 hours ago)
        
 (HTM) web link (fangprep.substack.com)
 (TXT) w3m dump (fangprep.substack.com)
        
       | 908B64B197 wrote:
       | What the author describes... is called drafting a spec.
       | 
       | It's something that's taught to first year engineering students
       | (map and understand all the constrains of a problem before
       | attempting to solve it, or else pay the price later...).
        
         | theshadowknows wrote:
         | I was brought in to a project on Friday to help figure
         | something out. The gist of the project is that we have a system
         | which generates tons of event data. Basically interaction
         | logging. And until recently the system sent those logs to some
         | other systems via nightly files. But someone in the business
         | decided it made more sense to do it "real time" and so some
         | folks have been diligently coding away and have built their
         | solution only to find there was a gigantic miss:
         | 
         | The system is generating thousands, sometimes tens or hundreds
         | of thousands of events per hour. And the api that is to receive
         | this data can only receive 100 "records" (events) per request,
         | and the system that generates the data can't do any sort of
         | multi threading or multiple requests simultaneously...it can
         | just fire off one request after another..
         | 
         | I did the math and on our busiest day this process would take
         | something like 827 years to send all of the event data...
         | 
         | I say all of this to highlight your point that it's a
         | foundational skill to gather requirements..and yet I'm working
         | with sr engineers that created this mess...
        
           | 908B64B197 wrote:
           | > and yet I'm working with sr engineers that created this
           | mess...
           | 
           | Engineers or "Engineers"? I'm asking because there's a trend
           | in this industry to call everyone engineer (6 months bootcamp
           | front-end engineer). But then you see things like that...
        
       | voz_ wrote:
       | I do not find this useful or correct. Furthermore, the author has
       | another post that says to avoid Cracking the Coding Interview,
       | which is actually a stellar book (even for those who are not
       | interviewing).
        
       | eyelidlessness wrote:
       | I have generally avoided or balked at typical coding interview
       | questions. They're very seldom representative of real work, and
       | have more value for helping big companies avoid lawsuits than
       | helping anyone else evaluate candidates or prospective jobs.
       | 
       | That said... the article offers good advice for people going
       | through the process. I'd add that it's not much different from
       | type- and test-driven development. Which, conceptually, might
       | help readers who are reading this advice and feeling overwhelmed
       | by the idea of trying to gather the information discussed while
       | "buying time to think of a solution".
       | 
       | Which is to say, if that feels like a lot of cognitive load on
       | top of trying to navigate "soft skills" and/or other challenges
       | in an interview, you may find it more grounding if you map the
       | advice to ways you already work.
       | 
       | Another way to look at it that occurred to me: it doesn't feel
       | very different from a _very short_ sprint (or new Kanban card or
       | choose your working cycle abstraction).
       | 
       | 1. Planning meeting to clarify user intent, acceptance criteria,
       | whatever you need to get started.
       | 
       | 2. Definition of smaller tasks and any feedback loop that might
       | entail.
       | 
       | 3. Implementation and its own feedback loop.
        
       | m0zg wrote:
       | I think it's ridiculous and dumb that otherwise smart people take
       | months out of their busy lives to train these bullshit skills
       | they'll never use outside these "interviews". FWIW, I never
       | prepare for more than a couple of days, and my batting average is
       | pretty good, albeit not perfect. And I'm not a genius by any
       | means. I just line up the interviews from least to most desirable
       | (so I get some "interview training" in), and go with the flow.
        
       | jurassic wrote:
       | I give a lot of FAANG interviews these days, and I'm stunned how
       | many people skip this important step of understanding the
       | problem, asking clarifying questions to surface important
       | constraints, and making a plan before launching off into
       | implementation. It's not rocket science.
        
         | reducesuffering wrote:
         | Because common expectations are two complex algorithmic
         | problems finished coding up in 45 minutes? "Show me the
         | incentives and I will show you the outcome." and "It's not
         | rocket science."
        
           | dilyevsky wrote:
           | Common at fb maybe not at any sane place I've ever
           | interviewed with
        
       | ruraljuror wrote:
       | > Asking questions like: "Can strings be multi-character?" can
       | provide you with critical information to the problem.
       | 
       | I don't understand this example, which immediately leads to
       | imposter syndrome kicking in because this is supposed to be
       | basic, right? But as I gain more experience I begin to expect
       | this is just poorly written.
       | 
       | So can anyone help me understand what is meant by this question?
        
         | dialogbox wrote:
         | I believe that means, even if it's a string not char, that is
         | used to contain a single character only. So all length of the
         | strings are 1.
        
         | sharkbot wrote:
         | I think the author is referring to characters in a Unicode
         | string that are combined to form a composite glyph.
         | 
         | For instance, a large number of emojis are formed by combining
         | two Unicode characters with a zero width joiner character. Skin
         | tones are a notable instance, along with gendered occupation
         | glyphs (female doctor, say).
         | 
         | It would be a simplifying (and usually correct) assumption to
         | ignore such composite characters in a basic processing task.
        
           | ruraljuror wrote:
           | This is a great explanation and perhaps this is the author's
           | intent. I think this example is so specific it is not a good
           | way to start. It is better to start by eliminating broad
           | categories and narrow in: can we assume ascii or do we allow
           | unicode?
        
       | ckcheng wrote:
       | The series relates to recent
       | https://news.ycombinator.com/item?id=28896343 which was just a
       | Google spreadsheet
        
       ___________________________________________________________________
       (page generated 2021-11-06 23:00 UTC)