[HN Gopher] Forced to settle for a nonideal job? Here's how to m...
       ___________________________________________________________________
        
       Forced to settle for a nonideal job? Here's how to make the most of
       it
        
       Author : Lwepz
       Score  : 16 points
       Date   : 2021-12-04 20:35 UTC (2 hours ago)
        
 (HTM) web link (www.science.org)
 (TXT) w3m dump (www.science.org)
        
       | axegon_ wrote:
       | I was in a job I absolutely hated up until not that long ago.
       | Initially I was very happy with it - as a developer, I loved the
       | fact that there were no calls lasting hours filled with made-up
       | acronyms and the usual "we should", "we must" and all that. But
       | to be honest there were other red flags from the very beginning
       | which I completely ignored(and I shouldn't have). The tech stack
       | was horrible: infrastructure was 2010-ish at best, the
       | deployments were absolute rat shit(45 minutes to deploy a new
       | version on single digit number of servers, just deploy, which
       | included no tests and no builds), the code was equally horrible -
       | linters were a no-go(the so-called head of engineering had his
       | own understanding of how code should be formatted), open a random
       | file and you will see every anti-pattern known to man. Dependency
       | tree was 500 lines long. Every common problem had a custom
       | solution instead of the freely available industry standard ones.
       | And speaking of the code, it felt like seeing the large perl
       | codebases with 30k+ line files from the mid 2000's: mixing
       | paradigms in a way which only makes sense to the person who came
       | up with them and no one else. Needless to say that a few months
       | into it I hated every single bit of it. Worst of all is that for
       | one reason or another, the developers were not only fine with all
       | this, they had picked up every single last bad habit - mixing
       | functional and object oriented programming, the wretched
       | formatting, everything invented past 2010-11 was considered
       | witchcraft and so on. I admit, I tend to swear when I don't like
       | something I work with. But here I was swearing all day, every day
       | from the depths of my throat. I can't describe how awesome it
       | felt to do a $find -iname {company_name} | xargs rm -rf after my
       | last day.
       | 
       | Two very important lessons:
       | 
       | 1. Never EVER ignore red flags. Ask about tech stack, procedures,
       | code-reviews, opinions on basic programming principles and
       | everything you can think of. Generally the interviewers should be
       | asking these questions but it's equally important to see how they
       | see the world. A simple thing to keep in mind is that if someone
       | thinks they know better than the veterans in the industry with
       | dozens of textbooks on the subject, chances are they are morons.
       | If you see something odd, ask more questions. For instance why
       | use mercurial over git: If you get an answer such as "well we
       | evaluated the two options and there really wasn't any benefit to
       | git and only made things more complicated" - run for your life.
       | In the case described here, it turned out that the head of
       | engineering didn't know how to use git and was confused by it.
       | 
       | 2. Ask as many questions about the tech stack as possible - there
       | are 3 possible options: One is the company uses what it uses
       | because it was inherited from someone else and they stuck with
       | it. Two, they picked some technology because they wanted to use
       | it and not because they had to. Three is they picked what seemed
       | the most appropriate but are willing to explore alternatives.
       | Ideally you should be looking for the third option.
        
       | flyingchipmann wrote:
       | 1. found out that the current position is not worth it 2. keep
       | working as usual (don't overwork) and spend rest of the time
       | interviewing 3. ??? 4. profit
        
       ___________________________________________________________________
       (page generated 2021-12-04 23:00 UTC)