[HN Gopher] Subverting the software interview (2021)
       ___________________________________________________________________
        
       Subverting the software interview (2021)
        
       Author : g0xA52A2A
       Score  : 130 points
       Date   : 2023-01-15 16:44 UTC (6 hours ago)
        
 (HTM) web link (nliu.net)
 (TXT) w3m dump (nliu.net)
        
       | thoughtpalette wrote:
       | Great writing, hilarious.
       | 
       | I feel like we all could know someone who fits these
       | characteristics.
        
         | jeffrallen wrote:
         | I worked with a guy who implemented map and reduce in C++ as a
         | subtask of some other task. It was, of course, a header-only
         | templated monstrosity.
         | 
         | He called it "fun.hpp".
         | 
         | "Fun" times, indeed, working with him.
        
           | djmips wrote:
           | OMG.
        
       | imperialdrive wrote:
       | I'm crying from laughter - this is simply fantastic! Mucho thanks
       | to author and OP for making my morning!!!
        
       | WalterBright wrote:
       | > You have a tendency to overengineer things.
       | 
       | Overengineering is an actual problem. For a tiny example, I'll
       | see things like:                   enum MAGIC = 67;  //
       | explanation         ...         foo(MAGIC);
       | 
       | The use of MAGIC is the only one, and is far removed. A better
       | solution is:                   foo(67);  // explanation
       | 
       | because it improves locality.
       | 
       | I also see things like an object fleshed out with all kinds of
       | member functions that are never used.
        
         | sokoloff wrote:
         | In a code review, I'd given a junior programmer advice to avoid
         | magic constants and use defines instead (c, not c++).
         | 
         | Resubmission came back with:                 #define SEVENTEEN
         | 17
         | 
         | Last I spoke with him, he was a Java instructor.
        
         | maxbond wrote:
         | I think I can see what you're getting at that you view this as
         | a premature abstraction, but I don't think I'd call it over
         | engineering. I'd call it a stylistic difference.
         | 
         | If `MAGIC` was sufficient to understand what the significance
         | of the number was and `// explanation` was the citation or
         | derivation, then I'd be fine with this, especially if there
         | were a bunch of other constants with explanations with similar
         | derivations or citations (eg a bunch of trig or constants from
         | the same standard); then it'd be preserving a different sort of
         | locality.
         | 
         | If `MAGIC` wasn't sufficient to capture the purpose of the
         | constant & such a name wasn't readily available, so that you're
         | always going to want to read `// explanation` (rather than only
         | in the case you think the value is wrong), then I'd agree with
         | you.
         | 
         | Concrete(ish) examples: if 67 terminated the Foo section of the
         | Bar binary file format, even if we only used it once, I'd
         | prefer to see END_OF_FOO rather than read a comment. Reading
         | comments is context switching, at least for me. Names help me
         | stay in the headspace of the programming language.
         | 
         | If 67 was the result of an ad-hoc calculation which only made
         | sense in the context of this particular program (how many
         | angels can dance on the head of an Acme brand pin executing our
         | trademarked choreography) while, and so there wasn't a great
         | name for that calculation, or at least not a name that would
         | make sense unless you've already read the derivation, then I'd
         | agree in that case.
         | 
         | That being said, I have absolutely seen overengineering or
         | misengineering cause real problems.
        
       | [deleted]
        
       | cntainer wrote:
       | Probably didn't pass the interview. The implementation was rather
       | simplistic and low quality.
       | 
       | Here's a better enterprise version:
       | https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
       | 
       | Though the fact that it was written some years ago might be a
       | weakness. Some interviewers might prefere a more modern,
       | distributed solution.
        
         | smoyer wrote:
         | What about observability?
        
           | BLanen wrote:
           | I was thinking of making a modern distributed spaghetti
           | version some time.
           | 
           | FizzService, BuzzService, FizzBuzzService, CountingService,
           | etc
        
         | jeffrallen wrote:
         | A multi core one, with lockless data structures.
        
           | classified wrote:
           | Better, with CRDTs.
        
         | pfoof wrote:
         | This github org needs more leetcode examples in that style
        
         | ARandomerDude wrote:
         | This is brilliant and spot on.
        
         | MikeDelta wrote:
         | Or serverless
        
       | billsmithaustin wrote:
       | Another in this genre: https://aphyr.com/posts/342-typing-the-
       | technical-interview
        
         | ryukafalz wrote:
         | This (along with several others) is linked at the top of the
         | article.
        
       | gunnr15 wrote:
       | So good.
        
       | singron wrote:
       | Everything makes sense to me until the Dual definitions:
       | newtype Dual a = Dual {getDual :: a}       instance Semigroup s
       | => Dual s where         (Dual a <> Dual b) = Dual (b <> a)
       | instance Monoid m => Dual m where         mempty = Dual (mempty)
       | 
       | These are declaring instances of Dual, but they are providing
       | method definitions for Semigroup and Monoid as if they were
       | declaring instances for those types. I plugged this into ghc and
       | I couldn't get this to compile either way. This isn't using an
       | extension or some more obscure language than haskell is it?
        
         | tczMUFlmoNk wrote:
         | Likely meant to be lifting instances of Semigroup and Monoid
         | through Dual:                   newtype Dual a = Dual {getDual
         | :: a}              instance Semigroup s => Semigroup (Dual s)
         | where             (Dual a) <> (Dual b) = Dual (b <> a)
         | instance Monoid m => Monoid (Dual m) where             mempty =
         | Dual (mempty)
        
       | tra3 wrote:
       | Gorgeous. I'm not versed well enough in the theory to validate
       | his code, but I know enough to see where he's going with this.
       | 
       | As an aside, there's a lot of rightful complaining about the
       | interview process. I've been on both sides and it sucks either
       | way.
       | 
       | As a hiring manager for a small company, we never had the
       | 'process' that bigger companies have, so it was always a seat of
       | the pants decision. Not my favourite thing to do.
       | 
       | As an interviewee, I've struggled with people's favourite
       | questions, you know the ones that you ask so much that it starts
       | sounding like an easy question in your head?... I'm productive, I
       | ship software but interviewing is so incredibly stressful and
       | always makes me feel like I don't know much.
       | 
       | Anyhow, if I was interviewing the OP for a typical web app CRUD
       | position or monolith to micro services refactor or some other
       | common role, I'd think twice. Clearly he's very smart. Is he able
       | to "deliver value" vs optimizing code? I know the post was tongue
       | in cheek, but in the real interview setting you gotta demonstrate
       | how you're a smart team player and allude to your capabilities.
       | It's kinda like dating I guess. You can't show how much of a real
       | person you're on the first date.
        
         | congoe wrote:
         | You could have at least clicked on the LinkedIn link before
         | assuming the author was a guy...
         | https://www.linkedin.com/in/naomi-w-liu/
        
           | classified wrote:
           | The name Naomi might have been a dead giveaway.
        
             | dandellion wrote:
             | It can be a male name, here's a random example I found in
             | Google: https://earth.stanford.edu/events/energy-seminar-
             | naomi-hiros...
        
           | tra3 wrote:
           | My bad, should've used "their".
        
         | johnbcoughlin wrote:
         | > validate his code
         | 
         | > by Naomi Liu
        
           | guntherhermann wrote:
           | A name does not imply sex. Even if it did, the parent wrote
           | multiple paragraphs and you get hung up on something as
           | inconsequential as this.
           | 
           | Take a day off.
        
             | Zacharias030 wrote:
             | [dead]
        
           | PostOnce wrote:
           | https://en.wikipedia.org/wiki/Naomi_Uemura
        
       | guntherhermann wrote:
       | Beautifully written, great read.
        
       | [deleted]
        
       | lazyant wrote:
       | > how their work ethics share the same ability to resist
       | deformation as their play habits
       | 
       | "We work hard, we play hard" in case anyone missed it :-)
        
       | andrew_ wrote:
       | great read. entertaining and engaging, wonderful creative writing
       | with nerd flair.
        
       | thatjoeoverthr wrote:
       | I'm smiling as I read from top to bottom.
        
       | tomxor wrote:
       | * * *
        
       ___________________________________________________________________
       (page generated 2023-01-15 23:00 UTC)