[HN Gopher] Lessons learned from the recent job hunt
       ___________________________________________________________________
        
       Lessons learned from the recent job hunt
        
       Author : edent
       Score  : 148 points
       Date   : 2022-05-08 09:40 UTC (13 hours ago)
        
 (HTM) web link (www.jvt.me)
 (TXT) w3m dump (www.jvt.me)
        
       | nijave wrote:
       | I've always found system design interviews to be a bit... weird.
       | Designing a complex system generally takes at least a few days
       | (at smaller places) up to weeks or months at larger places. In
       | addition, the solutions always seem to be biased towards
       | solutions that fit with existing technology/knowledge (which is
       | good).
       | 
       | It's not very easy to encapsulate domain knowledge and research
       | heavy questions into a small interview slot so some of these can
       | feel quite contrived.
        
         | jandrewrogers wrote:
         | If you've done complex system design for a long time then it is
         | possible to breeze through these interviews almost on
         | autopilot. The key is not the "design" _per se_ but asking
         | questions that rapidly constrain the design space and
         | understanding the implications of second-order effects. If you
         | do this regularly, like I do, it feels like a straightforward
         | mechanical process rather than something that requires hard
         | thinking. Muscle memory. System design is largely independent
         | of a specific app or tech stack.
         | 
         | I tend to burn through these interviews so quickly that we have
         | time leftover. It was always the easiest part of the FAANG
         | interview process for me.
        
           | anonymousDan wrote:
           | Can you give an example of what you mean by 'understanding
           | the implications of second order effects'?
        
             | sixstringtheory wrote:
             | That comment made me think of things like data relations
             | that would require indexing or lookups on foreign keys/IDs.
             | Or bottlenecks in components that perform hefty
             | transformations due to the design of the data structures or
             | unbalanced data sources, like where you need to merge
             | infrequent but large chunks of data with smaller but much
             | more numerous chunks from another async source.
        
           | bluejellybean wrote:
           | The thought of these questions, and engineering more
           | generally, boiling down to intelligent dialog trees hit me
           | like a ton of bricks a few months ago. I've been investing
           | time into deeply thinking about these trees, and it has been
           | one of those things that have made me feel like I've 'leveled
           | up' in my career journey. It's very validating to read your
           | comment, and it makes me feel like I'm on the right track.
           | Aside from plenty of practice, do you have any good reference
           | material or advice to share on improving this skill set?
        
         | mirceal wrote:
         | as with other things: it helps to understand the format and to
         | know what to expect.
         | 
         | also, when I am asking a system design question I am not
         | looking for a perfect design or even a design in particular. at
         | the end of the interview I ask myself the question: given
         | enough time could this person evolve what they have into a
         | design that would work in the wild?
        
         | scarface74 wrote:
         | As someone who does "system design" for a living - I specialize
         | in application development, but I get pulled into the
         | architecture side also - if you give me a set of requirements
         | including your requirements for scalability, high availability,
         | disaster recovery, do you need immediate vs eventual
         | consistency, networking requirements etc, I can usually walk
         | through and diagram an ugly (not aesthetically pleasing)
         | whiteboard solution relatively quickly. I can get you a good
         | diagram in a half a day. Most of the time, the actual
         | implementation is not too far off my initial design.
         | 
         | Knowing how to do system design is no different than knowing
         | how to do DS&A (which I've never had to do at any developer
         | interview between 8 jobs over 25 years). It's all about
         | recognizing patterns.
         | 
         | What really amazes me about the software engineering interview
         | process at larger companies is that they are given theoretical
         | system design scenarios instead of asking them to walk through
         | their real world experience.
         | 
         | Both in the latter part of my interviewing in the real world at
         | small companies who needed someone with experience to help them
         | scale and my interview for my current cloud consulting position
         | at $BigTech, they wanted to make sure I had real world
         | experience and understood the consequences and trade offs of my
         | choices.
        
         | [deleted]
        
         | Der_Einzige wrote:
         | System design is the blind leading the blind. An interviewer
         | whose never written and wouldn't recognize a "scalable
         | architecture" before asks a candidate to design one in front of
         | them. The candidate pretends to write a scalable architecture,
         | and the interviewer pretends to know when it's correct.
         | 
         | System interview skills are best taught with a class on how to
         | use "Microsoft Visio".
        
         | golergka wrote:
         | > Designing a complex system generally takes at least a few
         | days (at smaller places) up to weeks or months at larger places
         | 
         | That's designing it completely. In the interview, you're not
         | expected to produce the final result; more importantly, it's
         | not even about the result, but about the thought process and
         | conversation.
        
           | spyspy wrote:
           | Please. I've been asked why I didn't use specific features of
           | kafka in my solution and "because I've never used it before
           | only these other pubsub systems" was not the right answer.
        
             | lbriner wrote:
             | Without the context, it is hard to know what this means. If
             | they are a company that heavily uses Kafka, then there
             | could well be an expectation that you would have researched
             | it and at least learned enough to have an informed
             | discussion.
             | 
             | Other employers might expect someone who is "Senior" to
             | know about what different languages offer. As others have
             | said, the title "Senior" means different things to
             | different people and not all skills are transferable.
             | 
             | As others have said, if they don't do interviews well,
             | don't sweat it, you probably don't want to work there
             | anyway!
        
             | golergka wrote:
             | The fact that somebody found a way to misuse a tool (system
             | design interview) doesn't mean that there's something wrong
             | with the tool itself.
        
             | simplehuman wrote:
             | That anecdote only means the interviewer was bad
        
               | yunohn wrote:
               | The point is that the open ended question of system
               | design can lead to nonsensical expectations - No True
               | /Interviewer/ fallacy or not.
        
           | snidane wrote:
           | It's a maximally open question which turns into a guessing
           | game where you are trying to match what the interviewer has
           | on their mind at a given point. Some of them just want you to
           | collect requirements, which makes them feel smart because
           | they didn't go too much into details in a short time, others
           | want you to actually describe how you'd implement that
           | something and you have to come up with an imaginary users,
           | imaginary infrastructure and all the world around it just to
           | ground your concocted solution into it.
           | 
           | Some (big tech) companies tell you to prepare for the test,
           | because they try to standardize the system deaign open ended
           | question. They end up selecting those that dedicated weeks of
           | time learning for their version of the test. For the others
           | it's a psychological game trying to predict what is on the
           | mind of the person asking the questions.
        
             | lbriner wrote:
             | This is a very negative view of what an interview is. Most
             | interviews, however carried out, couild be described as
             | "trying to predict the mind of the person asking the
             | questions" but most interviewers are trying to get a
             | realistic view of the applicant with very little objective
             | information.
             | 
             | The bigger the company, the more likely people have
             | "trained" up to try and give themselves an advantage over
             | others. I don't think companies are necessarily looking for
             | people who have dedicated weeks of learning, but that
             | learning can certainly make the applicant look smarter than
             | they might be.
        
       | polote wrote:
       | It always baffles me that companies which struggle hiring, can
       | take the decision to reject a candidate like him during the
       | screening process ...
        
         | lloydatkinson wrote:
         | Reminds me of this
         | https://twitter.com/mxcl/status/608682016205344768?lang=en
        
         | ChuckNorris89 wrote:
         | This is way more common than you think and it seems like it's a
         | tragedy of the commons.
         | 
         | Companies struggle to hire, yet have crazy demands and
         | interview practices that filter out good candidates with
         | potential, because they're looking for the 'perfect candidate',
         | whatever that means to them.
         | 
         | From my experience, the whole shortage in this industry is
         | mostly companies being too picky, because they're afraid of the
         | small chance of letting in a less ideal candidate. And I'm not
         | even talking about unicorns/FAANGs/big-tech, but regular
         | companies.
        
           | ushakov wrote:
           | yeah but we need to pretend there's a shortage, so we can
           | import cheap slave-like labour from third-world countries
        
             | scarface74 wrote:
             | There is nothing "cheap" about how much companies pay most
             | H1Bs compared to the average salary in the US.
             | 
             | Now the policies and regulations around how they are
             | treated is a different story.
        
         | lbriner wrote:
         | What is baffling? OP explains that they didn't have certain
         | things on their CV. If I was hiring for a JS app and the
         | applicant was all Java or .Net, it is no disrespect to them to
         | filter them out at the CV stage.
         | 
         | I can only speak for myself but as a Dev of 20 years, mainly in
         | .Net (but with Java, Obj-C, PHP and JS experience) I wouldn't
         | dream of applying for a JS job because despite the trope, it is
         | not easy for a Senior to switch languages and just pick it up.
        
           | BlargMcLarg wrote:
           | I'm going to rail against this. The far majority of tools are
           | not so obscenely complex you can't learn the majority of it.
           | The far majority of jobs are not so obscenely difficult you
           | need the bleeding edge implementations available in those
           | tools. Looking online, the amount of information available to
           | do what you want is insane. There's almost always someone who
           | has already done things, especially for technologies older
           | than a few years.
           | 
           | This is even more problematic considering this selection is
           | done on framework and library level as well, and many other
           | tools. At the same time, making a tech stack is much like
           | creating an ice cream cone with thousands of flavors,
           | decorations and even cones available.
           | 
           | Language agnosticism and general intelligence should be
           | applauded far more than the industry currently does. Many
           | toolmakers are doing their best to make using their tools as
           | seamless as possible, and they are doing a good job at it.
        
             | dotBen wrote:
             | Sure, and if I may I'll politely rail back as a former
             | hiring manager... :D
             | 
             | I have no doubt that the senior software engineer with
             | plenty of .net/python/whatever experience _could_ pick up
             | the needed JS if they were given the position. But there 's
             | going to be extended ramp up time as they familiarize
             | themselves, they won't know the libraries let alone their
             | intricacies and idiosyncrasies etc, they won't have a lot
             | of language specific fresh approaches and experience to
             | inject into the team (which I'm looking for in a senior+
             | role). I would rather just hire someone who already has the
             | deep bench of JS experience at the same level.
             | 
             |  _Language agnosticism and general intelligence should be
             | applauded far more than the industry currently does._
             | 
             | The reason for this is because I'm not hiring for the craft
             | of software engineering, which your perspective aligns
             | with, I'm hiring to achieve business objectives quickly,
             | efficiently and to a high standard. Not realizing that most
             | hiring businesses are optimizing for the latter and not the
             | former is what trips a lot of career software engineers up.
             | You see yourself as a craftsperson, the employer sees you
             | as a resource to achieve their business objectives.
        
               | fn-mote wrote:
               | > I would rather just hire someone who already has the
               | deep bench of JS experience at the same level.
               | 
               | I love frank advertisements. Just put your real
               | requirements up front and don't interview anybody who
               | doesn't (claim to) fill them. Then it's fair to call
               | bullsh*t.
               | 
               | No complaints about the salaries you have to offer or the
               | thin pool of applicants, though. It's all a tradeoff.
               | 
               | I guess I'd like an evaluation as a hiring manager: does
               | it work? Are you able to hire the people you want? If
               | it's working none of this HN bellyaching matters.
        
               | DeathArrow wrote:
               | That's quite correct. You want an expert in X, you should
               | pay the high price he will ask. Unless you settle for an
               | expert in Y and give him time to get good in X.
        
               | cagey wrote:
               | Reading this
               | 
               | > But ... they won't know the libraries let alone their
               | intricacies and idiosyncrasies etc
               | 
               | triggered a related thought (also closely related to
               | recent "how do you learn effectively?" and "I'm
               | exhausted/burned out, what do I do?" HN threads):
               | 
               | In my most recent job-search, I found this _type_ of
               | expectation /requirement (specifically regarding deep
               | (down to idiosyncratic) _library_ (aka _framework_ )
               | knowledge & experience) to be the most off-putting. The
               | likelihood that I will have used a specific library in
               | the ecosystem your team/company has chosen in its pursuit
               | of "teh hotness" is (to put it mildly) low, but I'm
               | certain that my resume will be discarded, or worse, an
               | interview process spun up but doomed because I'll be
               | unable to regurgitate library documentation chapter and
               | verse (much less idiosyncrasies (many of which may be
               | version specific).
               | 
               | The proliferation of libraries/frameworks seems to be
               | exponential; how would I ever acquire deep knowledge of
               | the complete set of same that are considered "today's
               | hotness" (both today and of the past N years) in an
               | language ecosystem which I have extensive experience and
               | familiarity with? My current employer/team has made its
               | language and framework choices, and I'm bound to them for
               | (typically) years, and I focus (for years) on being
               | productive in that context. Am I expected (in the context
               | of my next job) to have spent my non-working hours
               | gaining/maintaining knowledge of both the contemporaneous
               | competing frameworks (which current employer/team didn't
               | choose, but came in close second, etc.) as well as each
               | "new hotness" that comes along? The alternative appears
               | to be that my future employment possibilities are
               | continually being reduced/narrowed as the set of
               | libraries/frameworks in popular use expands
               | (exponentially) while my knowledge remains tightly
               | focused within the domain. Even if I was willing to make
               | an investment in self-study to learn a new
               | library/framework well, given the above-described
               | circumstance, what would be my criteria to make a wise
               | choice? And if presented with the same question 6 months
               | later, what is the likelihood I would make the same
               | choice? I'm pretty sure the answer is not "100%".
               | 
               | In practice, I simply did not apply to the vast majority
               | of job listings which I would have considered myself
               | otherwise a good fit (i.e. could immediately grow into),
               | due to this factor.
        
               | scarface74 wrote:
               | If my company is using a standard tech stack -
               | React/Angular on the front end, Java/Spring or C#/.Net
               | Core on the backend or some similar popular framework - I
               | can throw a rock at a recruiter and they can find me
               | plenty of "good enough" developers who can "hit the
               | ground running" well enough to do your standard full
               | stack CRUD app
               | 
               | On the hiring side, why should I invest time for you to
               | "grow" and do negative work in the beginning just for you
               | to leave for another job?
               | 
               | Yes, I realize it's the company's fault for not offering
               | competitive salaries to incentivize you to stay. But
               | often as the (hypothetical) manager, that's out of my
               | hands.
        
               | DeathArrow wrote:
               | > I can throw a rock at a recruiter and they can find me
               | plenty of "good enough" developers who can "hit the
               | ground running" well enough to do your standard full
               | stack CRUD app
               | 
               | But those developers might cost you quite a lot. My
               | current employer has trouble hiring new people. Speaking
               | with recruiters and hiring managers from a few companies
               | (as I'm in the process of changing jobs) they told me
               | it's hard to fill their positions.
        
               | BlargMcLarg wrote:
               | >I'm hiring to achieve business objectives quickly,
               | efficiently and to a high standard
               | 
               | Don't misunderstand, I do understand the point of view
               | from hiring managers. But in the current job market,
               | where people change jobs rapidly to actually obtain said
               | knowledge while at the same time technology continues to
               | change rapidly (often repeating the cycle rather than
               | actually innovating), surely it should be evident this
               | isn't going to be efficient if not sustainable in the
               | long run.
               | 
               | If anything, you're giving people the exact arguments why
               | we shouldn't trust companies to act for the good of the
               | industry long term.
        
               | scarface74 wrote:
               | The .Net and Java ecosystems haven't changed that much in
               | the past decade. On the front end, it seems to have
               | calmed down.
        
               | DeathArrow wrote:
               | .NET changed quite a lot.
        
               | DeathArrow wrote:
               | >The reason for this is because I'm not hiring for the
               | craft of software engineering, which your perspective
               | aligns with, I'm hiring to achieve business objectives
               | quickly, efficiently and to a high standard. Not
               | realizing that most hiring businesses are optimizing for
               | the latter and not the former is what trips a lot of
               | career software engineers up. You see yourself as a
               | craftsperson, the employer sees you as a resource to
               | achieve their business objectives.
               | 
               | You put it in an interesting way. But FAANGs and big tech
               | are businesses, too. They would want to achieve their
               | business objectives, too. Still they hire someone who is
               | not proficient in a particular language / framework if he
               | is a good developer. Maybe the time it takes for them new
               | hire to ramp up is worth.
        
           | sdevonoes wrote:
           | > it is not easy for a Senior to switch languages and just
           | pick it up.
           | 
           | This surprises me. I have 15 years of experience in the
           | field, and it was many years ago when I got my degree in
           | computer science. Back in the day, they thought me algorithms
           | and what not using pseudocode (!)... nowadays I can easily
           | pick up any tool (programming language, framework) in, I
           | don't know, a month? Of course I won't be the best developer
           | out there with 1 month only, but pretty much I can be
           | productive. Sure, if one is switching from, let's say Python
           | to Haskell, then the learning curve is higher than if you
           | switch from Python to Ruby or JavaScript. Still, it still
           | amazes me seeing some developers call themselves "PHP
           | developer" or "Kubernetes architect".
        
             | scarface74 wrote:
             | Languages are easy, it's the ecosystem, framework and best
             | practices that take time.
             | 
             | Any developer can pick up Java or Swift in a month. That
             | doesn't mean you could turn them lose and tell them to
             | write a mobile app by themselves or lead a project doing so
             | in a month.
             | 
             | A "JavaScript developer" is useless as a front end
             | developer if they don't know the clusterf^ _#_ of the
             | modern front end ecosystem
             | 
             | I was a "C# developer" until 2020. That implies I knew the
             | ecosystem, frameworks, corner cases, best practices, what
             | could go wrong at scale if you used the different
             | frameworks incorrectly etc.
             | 
             | What I _didn't_ have to do - ever in the last 12 years of
             | my career - is reverse a binary tree on the whiteboard
             | while juggling bowling balls while riding a unicycle on a
             | tightrope. I went into smaller companies and got hired
             | based on my expertise.
             | 
             | Even now, I didn't have to go through the DS&A grind to get
             | into BigTech where I code everyday because I was able to
             | sell myself as an "enterprise developer who knew how to
             | lead projects and talk to customers and I specialize in
             | architecting solutions on their cloud platform". Does it
             | limit my optionality? Definitely. I'll be working on that
             | over the next couple of years.
        
       | mgaunard wrote:
       | There are two types of interview processes:
       | 
       | 1) get tested with irrelevant general-purpose problem-solving
       | questions before knowing what the role and team are,
       | 
       | 2) get presented the opportunity and assess fitness before doing
       | relevant technical challenges.
       | 
       | As a candidate you only want to spend time on 2), not 1).
       | 
       | As a company 1) is convenient because it ensures people are
       | somewhat decent before you bother your hardworking engineers.
        
         | dotBen wrote:
         | (former hiring manager here) depends on seniority of role and
         | candidate. If you are interviewing for an Eng I or Eng II role
         | (or even more junior, if the company does that) at a large tech
         | company you are likely going to get a 'blind interview' (where
         | its yet to be decided which project you will work on) and then
         | if you are successful, assigned a team based on need within the
         | organization.
         | 
         | It's the reality of how large organizations keep their teams
         | stable with employee turnover and also slightly grow them. Yes,
         | teams will work to fill their roles directly too but often the
         | team will show up for work on a Monday morning to find that
         | they have a new member of their team who they've never met but
         | is an 'extra bonus' or the headcount has been filled anyway.
         | 
         | If you are likely to be interviewing for Eng I/II you should
         | not be surprised if parent's option 1) is the route you are
         | presented with - I think it's wrong to say "you only want to
         | spend time on 2)" as it's unrealistic for early career folks
         | and they risk missing out on exceptional opportunities to get a
         | foot in the door.
        
           | mgaunard wrote:
           | I'd say there are many more advantages to working for a small
           | rather than large organization.
           | 
           | Those would be most likely to take a tailored approach to
           | hiring even for juniors.
           | 
           | Though of course you should do a bit of large ones as well to
           | see what it's like and put it on your CV.
        
             | angarg12 wrote:
             | Sadly many small companies don't have the means to support
             | juniors. Some don't hire them at all.
             | 
             | For the folks out there, the easiest way to join FAANG is
             | as a new grad. Whether you want to do it or not is your
             | decision to make.
        
               | axpy906 wrote:
               | > For the folks out there, the easiest way to join FAANG
               | is as a new grad.
               | 
               | By this, I would assume you mean the year of prep that
               | goes into being able to pass the interview process at
               | those companies.
        
         | dominotw wrote:
         | 1 is faang which have way higher pay than 2
        
           | mgaunard wrote:
           | You're unlikely to be paid that well if you're a replaceable
           | commodity that went through a standardized hiring process.
        
             | scarface74 wrote:
             | Return offers for interns at the BigTech companies are in
             | the mid to high 100s. That already puts them at the top 10%
             | of earners in the US.
             | 
             | Everyone is a replaceable commodity at a company of any
             | size. I've never heard of any company going out of business
             | because one key person left.
        
               | epicureanideal wrote:
               | > I've never heard of any company going out of business
               | because one key person left.
               | 
               | Companies don't die that quickly. It may not be one
               | person but it might be a handful of high performers who
               | leave over time due to a toxic culture. And even then it
               | may take literally years for a VC cash infused zombie
               | company to actually cease operations. One of the problems
               | of having so much cash is bad decisions don't reveal
               | themselves until much later.
        
             | angarg12 wrote:
             | Check https://www.levels.fyi/. The bimodal compensation
             | landscape is real.
        
             | 1270018080 wrote:
             | If only that were the case
        
             | pyb wrote:
             | It sounds like this should be the case in theory, but the
             | reality is the other way around!
        
       | dominotw wrote:
       | i've been doing this last 1 month too. Its a bizzaro world out
       | there.
       | 
       | 1. long application forms that takes a long time to fill with no
       | response or acknowledgment after. eg:
       | https://automattic.com/work-with-us/
       | 
       | 2. recruiters who insist on scheduling on phone call when it can
       | just be an email/text.
       | 
       | 3. endless rounds or interviews with all sorts of weird stuff,
       | 1. Take home assignments               2. hackerrank puzzles
       | 3. pair programming on 'real world' problem               4. Open
       | a PR to Open source repo                5. leetcode puzzles with
       | stuff like dynamic programming.             with 2 mediums/ 1 hr
       | speed.               6. 'system design' interviews url shorterner
       | with caching/replication/sharding/consistent hashing
       | 7. 'behavior interview' .pre made answers  to what was your
       | biggest mistake. how do you resolve confilict with teammates.
       | 8. Debugging sessions to find  bugs in existing code.
       | 9. 'real world case study', 1 hr presentation of challenging
       | problem you've solved in ur career.                 10. 1 hr
       | 'life story' interview where you showcase your passion for work
       | and life.                11. product design interviews. how will
       | you improve our shitty product.
        
       | tomxor wrote:
       | > then in the coding exercises you were asked what the O(n)
       | complexity of time/space were
       | 
       | I usually ask people to roughly describe what is meant by
       | computational complexity (sometimes I slot it into the
       | conversation when discussing some code they wrote), or what big O
       | notation is for... assuring them I'm not looking for a formal
       | definition but an understanding and applicability. I probably
       | wouldn't do a great job actually using big O notation to express
       | complexity myself if asked on the spot; however I believe a basic
       | understanding of the underlying concept is invaluable and
       | separates juniors from everyone else.
       | 
       | Is this not considered reasonable these days?
       | 
       | [edit]
       | 
       | To clarify, I think the author _was_ being asked to express their
       | code in big O, I 'm just wondering what people think about ask
       | about big O and complexity in general.
        
         | returningfory2 wrote:
         | > Is this not considered reasonable these days?
         | 
         | There's currently a backlash against LeetCode style interviews,
         | and I think one part of this backlash is that dismissing
         | anything that feels LeetCodey (like asking about time
         | complexity) is considered reasonable.
        
           | twofornone wrote:
           | I abhor everything leetcode (and suck at their puzzles), but
           | I would call O(n) basic foundational theory. Competence in
           | engineering requires an intuitive understanding of at least
           | time complexity. Given that this is software "engineering",
           | it's probably fine if the candidate isn't familiar with big O
           | specifically but they should at least be able to reason about
           | scaling complexity on an interview, I think.
        
         | armchairhacker wrote:
         | Big O is important. I actually have to frequently understand
         | whether my function runs in logarithmic or linear or quadratic
         | or exponential time relative to some value.
         | 
         | I can see an issue if you're asking for a weird big O which
         | really isn't useful in practice, like "oh, we were expecting
         | this weird algorithm which is O(log log n), not something O(log
         | n)", or having to calculate the big O of one of those weird
         | algorithms.
        
           | PheonixPharts wrote:
           | Big O, by definition, assumes as n -> [?].
           | 
           | This can be a really poor assumption in real world software
           | that can bite both ways. Some "expensive" algorithms in terms
           | of big O terms can be pretty efficient given real world data
           | sizes. Additionally that C term that drops off at infinity
           | can matter quite a lot if your real world problem size is
           | small (meaning theoretically efficient algorithms can have a
           | very high upfront cost).
           | 
           | Reasoning about actual runtime performance is far more
           | important and intersects with the interesting/useful parts of
           | computational complexity theory. Besides, in every interview
           | I've been in they don't really mean "Big O", because I've
           | never been required to produce a recurrence equation proving
           | it, nor have I been confident the interviewer would even
           | understand such an answer.
           | 
           | Understanding performance is hugely important in real world
           | software, but Big O is a tiny part of that in practice.
        
             | charcircuit wrote:
             | You don't need a recurrence relation to prove it. You can
             | use a simple algebra where you are able to combine the
             | complexing of algorithms. For example an O(n) algorithm
             | followed by an O(n^2) algorithm will be O(n^2). In an
             | interview I describe how the complexity of these simpler
             | algorithms get combined into my final answer. I assume that
             | the interviewer and I can agree on some basic stuff like
             | looping over an array is O(n), inserting into a heap is
             | O(log(n)), etc.
        
           | camgunz wrote:
           | It's important but like, it generally boils down to "do you
           | have nested loops" and "are you using a binary tree". A lot
           | of system behavior isn't defined by these kinds of decisions
           | because your N is small. Rather, it's defined by say TCP
           | backoffs or queue sizes, or the broad architecture of the
           | system (must you wait for consensus, do you use Salesforce
           | SObjects as a cache before dumping into Postgres--a real life
           | example--what is your "needs rerendering" trigger). I think
           | it's useful for a programmer to have this kind of basic
           | knowledge of code, but the amount of play it gets in
           | interviews is pretty disproportionate to its importance.
        
             | dominotw wrote:
             | what about db table scan vs index. that happens all the
             | time.
        
               | camgunz wrote:
               | I guess this is more of a "do you know about database
               | indexes" question, but I think if it less of a gotcha and
               | more of a jumping off point into a discussion you can
               | take it in a number of directions:
               | 
               | - time vs. space tradeoffs
               | 
               | - insert vs. select tradeoffs
               | 
               | - Oh yeah they're binary trees also, with those
               | implications
               | 
               | - What's reasonably distributable (downsides of UUIDs)
               | 
               | - at what point might you have query performance issues
               | you can address w/ indexes
               | 
               | But like, again practically speaking I think this is just
               | an experience test question. I think I'd prefer something
               | like "on your resume you have Postgres experience dating
               | back 7 years, tell me what you think about it, what its
               | strengths and weaknesses are, and why you would or
               | wouldn't use it".
               | 
               | ---
               | 
               | Maybe you have thoughts about this too, but I'm also
               | starting to develop some thoughts around whether to
               | consider interviews quizzes/tests or conversations.
               | Thinking about it, I've always approached my interviews
               | (on both sides of the table) as conversations--even
               | questions with simple answers. I guess that's why my
               | answer here is "this should be a discussion about
               | databases" and less "table scans vs. index scans in 30
               | seconds go". It's totally OK to drill down into specifics
               | and be technical, but this is potentially your first
               | interaction with a new colleague, and you should be
               | collegial, not domineering and inscrutable right? I think
               | we get so worried about hiring a faker that we justify
               | anything to avoid it.
        
           | jameshart wrote:
           | The emphasis placed on big-O in interviews is weird though.
           | Accidentally quadratic code happens, sure, but the way the
           | industry uses it as an interviewing shibboleth makes it feel
           | like this is a safety critical issue; as if at some point a
           | developer used an O(n log n) algorithm when an O(n) algorithm
           | existed and _people died_.
           | 
           | Complexity can be insidious, and it can lead to annoying bugs
           | you only discover in pathological data cases, but it is in no
           | way as important in software development as _correctness_.
           | 
           | Code that runs slow over pathological input is nowhere near
           | as dangerous as code that goes into an infinite loop over
           | pathological input.
           | 
           | Your O(log n) recursive tree traversal is beautifully
           | efficient. Too bad it stack overflows with trivial tree
           | depths.
        
             | rdw wrote:
             | > Code that runs slow over pathological input is nowhere
             | near as dangerous as code that goes into an infinite loop
             | over pathological input.
             | 
             | In my experience, these are not actually that different.
             | Even in straightforward web development on smallish data
             | sets, it's pretty easy to write something that runs "fast
             | on my machine" but is so slow on production-sized data that
             | it is effectively infinite.
        
               | jameshart wrote:
               | Yes, as I say, clearly it happens. But when it does the
               | results are no worse than any other bug.
               | 
               | And it's far more common, and more dangerous, in my
               | experience, to see a loop that assumes it must eventually
               | reach a terminal condition that isn't actually
               | guaranteed.
               | 
               | I just don't think the risk of hiring someone who
               | misestimates the time complexity of an algorithm is
               | sufficiently great that it's worth explicitly filtering
               | for. Why is this the one piece of hard won experience or
               | academic knowledge that we need a candidate to have
               | _before_ they join our company, given that it's something
               | that can be taught in a single CS101 lecture, and in
               | practical terms, something I can explain to a competent
               | developer in about ten minutes?
        
             | ryandrake wrote:
             | Even weirder: A lot of companies who are obsessed with
             | big-O and algorithm complexity don't ask candidates even
             | basic questions that require them to think across many
             | orders of magnitude, in terms of time and storage. I'd
             | argue that being flexible enough and able to visualize
             | things across, say, ten orders of magnitude, is a more
             | critical programming skill than knowing big-O.
             | 
             | Even basic questions: Answer with either the word
             | nanoseconds, microseconds, or milliseconds: What's the
             | order-of-magnitude latency of CPU cache lookup? Reading 1MB
             | from spinning disk? Reading 1MB from memory? A round trip
             | packet to a server 1km away? A GPU clearing a 4K screen? A
             | mutex lock? Answer with kilobytes, megabytes, or gigabytes:
             | What's the order-of-magnitude size of a digitized photo? A
             | song? A movie? A graphics frame buffer? Wikipedia? Google's
             | homepage? A typical bootloader? A Windows app executable
             | file? A typical CPU L1 cache? L2 cache?
             | 
             | Too many junior developers can only answer a few of these,
             | even with the answers having three orders of magnitude
             | granularity! But we constantly ask them to belt out the
             | best and worst case big-O complexity of a binary tree.
        
         | semiquaver wrote:
         | There's been a move away from requirements for CS degrees in
         | software development over the last decade or so, but that
         | shouldn't mean that key concepts like asymptomatic complexity
         | are not needed, only that they are sometimes understood at a
         | more intuitive and less academic level.
         | 
         | The author is a senior engineer, I have no doubt that they
         | could describe difference between a linear and polynomial-time
         | algorithm and the potential concerns with the latter even if
         | they might not use that terminology because of a trend against
         | academic-sounding lingo.
        
         | umvi wrote:
         | I feel like a lot of leetcode grinders don't actually
         | understand big O. Sure, they will produce the correct answers
         | to your questions like a well-oiled Chinese Room, but they lack
         | true understanding. It's almost mechanical: "O(1) is
         | faster/better than O(n) which is faster/better than O(n^2)"
         | etc. O(1) is hashmap, O(n) is a for loop, O(n^2) is a nested
         | for loop, etc.
         | 
         | So if an O(1) solution exists, the candidate will almost
         | certainly converge on it. Yet the part not being understood is
         | that big-O is just an upper bound that you may never see unless
         | your datasets grow to huge sizes. Sometimes an O(n)
         | implementation is actually better or faster than an O(1)
         | implementation or sometimes O(n^2) is better/preferable than
         | O(n). It depends on a lot of things - the size of the data
         | being handled, the expected scaling of the data, who is going
         | to be maintaining the code, etc. A straightforward, highly
         | readable O(n^2) function that operates on small datasets is
         | almost certainly preferable to an unholy O(n) incantation that
         | is unreadable but technically scales better.
        
           | PheonixPharts wrote:
           | > well-oiled Chinese Room
           | 
           | Wow, this is really the perfect description of the general
           | understanding of algorithms and computational complexity in
           | the post-leet code era.
           | 
           | I've found that far less people in software understand and
           | are curious about algorithms than there were 15 years ago,
           | despite the fact that almost everyone studies them now for
           | interviews.
           | 
           | I wonder how many people asking questions about computational
           | complexity could tell you what the pumping lemma is, or how a
           | regular language differs from pushdown automata. Or, more
           | important, if they could answer the question "what is Big
           | Omega for this problem?" or if they are really asking "what
           | is big theta?". I'm still tempted sometimes to refresh on
           | recurrence equations to provide the actual answer for these
           | things rather than just applying some heuristic. Of course,
           | in my experience, doing something like that would get you a
           | failing score since they wouldn't know what you're doing and
           | therefore assume you are wrong and an idiot "I can't believe
           | that guy didn't even understand Big O".
        
             | sideshowb wrote:
             | > I've found that far less people in software understand
             | and are curious about algorithms than there were 15 years
             | ago
             | 
             | Maybe because so many SW job descriptions these days seem
             | to consist of plugging library into framework, and anyone
             | interested in algorithms would be bored?
             | 
             | Not saying that's what you're recruiting for, but the
             | industry has expanded massively while I'm guessing the
             | number of algorithm heavy jobs has stayed roughly constant.
        
             | eastbound wrote:
             | > I've found that far less people in software understand
             | and are curious about algorithms than there were 15 years
             | ago, despite the fact that almost everyone studies them now
             | for interviews.
             | 
             | It may explain why no-one succeeds my interview test, but
             | then I wonder what I should test on if I want someone
             | correctly smart.
             | 
             | My interview test is simply to find a string in a string
             | and return true. It takes two _for_ and one _if_ , everyone
             | fails, I generally stop them after one hour when there are
             | booleans scattered everywhere. The way I give the exercise
             | is "Please program a .contains(), without using .indexOf(),
             | and no need to optimize anything, I'm not looking for
             | anything fancy." A 49 years old java programmer even
             | complained that the test isn't fair because it's stressful
             | to program in front of people, so now I take the habit of
             | sitting in the next room, but then people try to overdo it
             | and deal with UTF-8 before having the basic algo working.
             | 
             | I'm pulling my hair wondering what's this parallel world
             | I'm in, or whether I'm introducing a bias which makes
             | everyone fail (2 interviewees per month for 5 months).
        
               | Gunax wrote:
               | If they are over-complicating it, then you are not
               | communicating the problem well.
               | 
               | Maybe change the problem to an array of ints. It's the
               | same solution but you will not have anyone asking about
               | UTF and text direction.
        
               | justinlloyd wrote:
               | > "Please program a .contains(), without using
               | .indexOf(), and no need to optimize anything, I'm not
               | looking for anything fancy."
               | 
               | If that is the statement that was given to me, I would
               | clarify the interviewer is not looking for optimal run-
               | time or anything fancy like handling UTF-8 or right-to-
               | left -- because an interviewer often says "nothing fancy"
               | and then will nitpick the fact the code you wrote on the
               | whiteboard doesn't follow precise PEP-8 standards or use
               | idiomatic Ruby or doesn't adhere to the latest C++-23
               | syntax -- and then I would write a total of six or seven
               | lines of code C code (variable declarations, return
               | statement, etc), which would be two for-loops and an if-
               | statement. I could probably get that down to just the
               | for-loops if I want to be "fancy" and bury the
               | conditional in the for-loop test itself.
               | 
               | I think the real problem is, we tend, in an interview
               | situation, to overthink what the interviewer is asking
               | for at times. I see this in a lot of take home tests
               | people do when applying to companies, then ask me if they
               | have done enough before submitting to the company they
               | are interviewing with. That said, I've dealt with
               | interviewers that give the take home test, or the white
               | board test, and then complain that the candidate didn't
               | go far enough by adding on un-asked for stuff. "Going the
               | extra mile" as they say. The crux of the problem is the
               | vagaries of interviewing style.
        
               | weaksauce wrote:
               | I think a lot could be mitigated if interviewers supplied
               | a take home test _and_ a different example take home test
               | with an answer that showed the format of what they were
               | actually looking for with depth /complexity/testing/etc.
        
               | TacticalCoder wrote:
               | > ... but then people try to overdo it and deal with
               | UTF-8 before having the basic algo working.
               | 
               | Wait... We all know (?) that Java was conceived before
               | Unicode 3.1 came out and somehow thought that 16 bit
               | chars would forever be enough to hold unicode codepoints
               | and hence Java strings are now a mess of both char and
               | codepoint methods but... What's UTF-8 got _anything_ to
               | do with your question, even _after_ a basic algo is
               | working?
               | 
               | If I'm using Java's charAt(...) on both strings, what's
               | the encoding got anything to do with matching if the
               | substring is present? Who cares that one character may
               | have a codepoint encoded using more than one Java char
               | primitive? It's either encoded the same in both strings
               | or it won't match right?
               | 
               | I'm confused.
               | 
               | EDIT: you said it's not fancy, so you're not looking for
               | people to match combining codepoints in one string
               | matching another codepoint in the other string or things
               | like that right?
        
               | weaksauce wrote:
               | Either you aren't screening candidates that have no
               | obvious coding skills or the job description is wildly
               | off the mark. That's a pretty easy coding test for basic
               | strings.
        
               | foobarian wrote:
               | Hey! That's my question :-) I've been doing pretty much
               | exactly this for the past 10 years. A common solution
               | I've seen is a single while loop with gnarly logic inside
               | to monkey with the string index, rewind when no match,
               | etc. Then imagine that kind of code in your business
               | critical backend.
        
               | throwanem wrote:
               | If you've just failed ten interviewees in a row, then
               | either your sourcing is broken, or you're doing
               | interviews wrong. Might be both, can't be neither.
               | 
               | Granted, I don't think it's all that hard a problem, and
               | while I'm not at keys to check I think off the top of my
               | head it should be solvable for constant strings in linear
               | time - not like you're asking for sequence alignment or
               | anything like that.
               | 
               | But if it demonstrates something relevant to the role and
               | ten in a row can't hack it, then your pipeline's not
               | finding you good candidates and that needs to be fixed.
               | 
               | And if it's _not_ relevant - which is highly plausible,
               | as who ever needs to or even _should_ reimplement heavily
               | optimized standard library functions, especially for as
               | hairy a type as strings - then why even ask it in the
               | first place?
               | 
               |  _edit, at keys_ : Yeah, it's simple to do this in linear
               | time with constant strings (ie no backtracking):
               | const cases = [           {             subject:
               | "now is the time for all good men to come to the aid of
               | their country",             searchFor: "n to come t",
               | expect: true,           },           {
               | subject:               "now is the time for all good men
               | to come to the aid of their country",
               | searchFor: "time flies",             expect: false,
               | },           {             subject: "short skirt",
               | searchFor: "looooooooong jacket",             expect:
               | false,           },           {             subject:
               | "symbolized as [?]v and pronounced delta-vee",
               | searchFor: "[?]v",             expect: true,           },
               | ];                  function contains(subject, searchFor)
               | {           let searchIdx = 0;                    for
               | (let i = 0; i < subject.length; i++) {             if
               | (subject[i] === searchFor[searchIdx]) {
               | searchIdx += 1;                        if (searchIdx + 1
               | === searchFor.length) {                 return true;
               | }                        continue;             }
               | // We found a mismatch between subject and search
               | // strings. Return to the first char of the search
               | string;             // we'll have to try to find a new
               | match             searchIdx = 0;           }
               | return false;         }                  function
               | assertEqual(expected, actual) {           if (expected
               | !== actual) {             throw new Error("Assertion
               | failed");           }         }
               | cases.forEach((testCase, i) => {           const {
               | subject, searchFor, expect } = testCase;           try {
               | assertEqual(contains(subject, searchFor), expect);
               | console.log(`PASS: case ${i + 1}`);           } catch (e)
               | {             console.error(`FAIL: case ${i + 1}`);
               | }         });
               | 
               | It's trivial in quadratic time too, of course, although I
               | would expect a candidate for a senior role to be able at
               | least to find the linear solution, if not to start there
               | outright.
               | 
               | In entire fairness, I have to admit that we do use
               | problems of similar complexity (both cognitive and
               | algorithmic) for our first tech session, which I
               | frequently administer. In my experience, people tend to
               | handle stuff like that pretty well, even with
               | considerably less experience than it sounds like your
               | candidates have. But - and I think this is crucial - none
               | of those problems involves operating on strings.
               | 
               | As another commenter here suggested, you definitely need
               | to express this in terms of Array<number> or some similar
               | contrived type that's obviously _not_ as complicated as
               | strings, because anyone who 's been around for a while
               | will certainly have been burned often enough by string
               | complexity that they're not likely to assume they _can_
               | treat it purely as an array of bytes iso8859-1 style. I
               | certainly wouldn 't assume that!
               | 
               | To be clear, I would _ask_ if I could safely assume that
               | for the purposes of the problem, or more likely I would
               | look at the tests around the problem and see if any of
               | them included obviously non-Latin-1 chars and thus cue me
               | that they need special handling. (If I can 't see the
               | tests while I'm writing the code that's supposed to pass
               | them, you'd better believe I will ask about _that!_ )
               | 
               | I wouldn't necessarily ding a candidate for _not_ asking,
               | though. For one thing, this is all pretty basic info, and
               | would certainly be available in  "real life" - so if it
               | isn't available in the interview, then the interview
               | isn't a sufficiently accurate representation to produce a
               | clean signal.
               | 
               | For another, and for the same reason, the perceived power
               | differential between panelist and candidate has to be
               | taken into account. You're not going to get a clean
               | signal if you bring your ego into the session, or
               | otherwise give the candidate cause to feel more
               | intimidation than the context naturally inspires.
               | 
               | Some folks are more confident than others, sure - but
               | it's a _technical_ interview, and confidence isn 't
               | really of interest beyond the baseline of not seeing a
               | candidate dissolve into a puddle of flop sweat. (And, in
               | any case, if that _does_ happen then it 's at least as
               | much my fault as anyone's, because if I'm not able to
               | help people be comfortable enough to even function on my
               | team or in my engineering org, then I'm not doing my job
               | right!)
               | 
               | So yeah, granted, I haven't interviewed with you and I
               | don't know any details beyond what you've chosen to
               | describe, so take this advice for whatever you find it to
               | be worth. But, especially in a language like Java which I
               | gather makes it more necessary to account for utf8
               | weirdness in strings than the languages I more commonly
               | work with, I definitely think you'll see a significant
               | improvement with just that one simple change of not
               | _using_ strings where you really don 't need to in the
               | first place. That might not be the only thing that needs
               | attention - I suspect your pipeline may need some love,
               | too - but I'm fairly confident it's an excellent place to
               | start.
               | 
               | (For what it's worth, my experience with tech interviews
               | extends well beyond the candidate's role; I've been
               | participating in them as a panelist for a good few years
               | now, and lately have been doubling up my sessions as
               | mentoring/shadowing opportunities for other engineers and
               | EMs who want to improve their own panelist skills.
               | Granted, I've approached this discussion largely from the
               | candidate's perspective - but then too, I'd argue very
               | firmly that if you're _not_ considering how your
               | interviews might go from the candidate 's perspective,
               | then _that 's_ something you need to work on, too.)
        
               | foobarian wrote:
               | Speaking for our org, but it's because most business
               | logic in our backends is about the same level or more
               | complicated than String.contains.
        
               | throwanem wrote:
               | Is it, though? I think real cases might frequently be
               | _less_ complicated, in Java at least. As is evident from
               | the candidate experiences that the original commenter
               | describes, there 's a lot more complexity in strings than
               | is immediately obvious.
               | 
               | I agree with 'Gunax that that's likely to be tripping
               | people up - as I mentioned in the comment to which you're
               | replying, albeit in a somewhat recent edit, this has not
               | nothing to do with why our own similar interview problems
               | _don 't_ revolve around any operation on strings.
        
               | PheonixPharts wrote:
               | > A 49 years old java programmer even complained that the
               | test isn't fair because it's stressful to program in
               | front of people, so now I take the habit of sitting in
               | the next room
               | 
               | Whether programmers like it or not, live coding has
               | become a standard for interviews these days. I can see
               | anyone still unfamiliar with this doing poorly, I used to
               | do awful at these until I realized this is just part of
               | the game, but it's not unreasonable to expect candidates
               | to be able to do whiteboard/live coding.
               | 
               | However, you just sitting in the other room, tells me you
               | _also_ have a lot to learn about the structure of live
               | coding interviews. Every major Big Co. that does these
               | has a very well established flow, including providing
               | helpful clues to the candidate. Most companies provide
               | training to all interviewers to make sure this process is
               | smooth, repeatable and fair to candidates.
               | 
               | Common tips are to: first make sure the candidate
               | understands the question, make sure they are thinking out
               | loud the entire time. You don't let the candidate go too
               | far down the wrong path. Most important you have a list
               | of anticipated questions with stock answers to help stuck
               | candidates, as well as a list of stock prompts to help
               | them get on the right track if they are lost.
               | 
               | For example, in your challenge, if a candidate is stuck
               | you might ask as simpler subproblem "so how would you
               | find out if a sting contained the letter 'a'?" and if a
               | candidate starts heading down the wrong path, prompt with
               | "hmmm... I think I see where you're going, but I
               | recommend you back up a bit and rethink this part here"
               | 
               | It sounds like you're in a small shop so I highly
               | recommend you enlist a few friends (especially some that
               | have done interviewing at large companies) to help you
               | work out the kinks in the interview itself.
        
               | Beldin wrote:
               | > ... _I wonder what I should test on if I want someone
               | correctly smart._
               | 
               | Why would you want that? Look for someone who can (and is
               | happy/eager to) learn *from you*.
               | 
               | Edit: smart isn't bad, but it's not much of a signal -
               | there are plenty of ways to be smart but not very
               | productive. Moreover, any test in an interview setting
               | well be extremely limited. Ability & willingness to grow
               | seems a lot more useful (and at least equally well
               | testable).
        
             | majormajor wrote:
             | > I've found that far less people in software understand
             | and are curious about algorithms than there were 15 years
             | ago, despite the fact that almost everyone studies them now
             | for interviews.
             | 
             | I would argue people who prep with LeetCode aren't studying
             | algorithms at all, they're doing something much closer to
             | memorizing.
             | 
             | I've seen people who I assume did a bunch of cramming like
             | that because they'll be like "oh this is [xyz]" and throw
             | out a solution in a hurry, and then I ask them to modify it
             | in a non-standard way, and it's almost as if the idea that
             | an off-the-shelf regurgitation of the "normal" solution for
             | a problem not being able to handle a modified scenario is
             | something they've never thought about.
             | 
             | Like "oh this is a search problem" -> "what if [something
             | that essentially boils down to the graph potentially having
             | cycles]?" -> [head expodes instead of thinking about, say,
             | tracking what nodes have already been seen]
        
           | zahllos wrote:
           | My favourite approach to big-O questions to to reply O(exp^n)
           | to everything. When asked I point out that whatever it is,
           | exp^n surely bounds it. This'll go either two ways. The
           | interviewer will reflect on whether it is a least upper bound
           | or not (and whether my statement is right) which makes for an
           | interesting discussion about the other types of Landau
           | notation. Or they'll get angry.
           | 
           | Ultimately I'm not convinced based on my own personal
           | experience that many of the people _asking the question_
           | truly understand either. I see it in a somewhat negative
           | light because I feel it is essentially a cargo culted
           | interview technique - recite a few 0()s, yeah we all did CS
           | degrees, great (or not). If you actually try to get into the
           | weeds...
           | 
           | I also don't think understanding big O notation is a great
           | predictor of success of a software engineer. As well to ask
           | if the series 1/n converges versus 1/n^2. What I'd rather see
           | is that they can actually implement a solution. Take an ORM
           | for example - a junior candidate knows how to use it and
           | maybe how to debug it. A senior candidate might know that
           | ORMs often emit very poorly optimised SQL and have some ideas
           | on how to fix it. Example picked arbitrarily, ORMs aren't
           | even my area.
           | 
           | Even in my actual area of specialty the number of industry
           | programmers who understand say what an elliptic curve with
           | complex multiplication actually is, or even undergrad group
           | theory, is quite limited. And they don't need to - I mean it
           | is ideal if they do, but you can still implement ecc without
           | much theoretical knowledge. There's also a bunch of "not
           | academic" knowledge on various implementation techniques that
           | academics might not know or care about.
           | 
           | Brings me back to my ORM point. I'd much rather the person
           | understands how the tools might fit together and more
           | importantly learns any gaps or asks questions and identifies
           | performance issues in the whole.
           | 
           | That's not to say that time and space bounds don't matter.
           | They do. But 99% of my use of this knowledge has been to
           | answer interview questions.
        
             | yobbo wrote:
             | It is an upper bound for something, but not _the_ upper
             | bound for that algorithm.
        
               | zahllos wrote:
               | Told you it drives people nuts.
               | 
               | So big-O implies that the runtime is "dominated" by the
               | term in brackets, or put another way, if I say something
               | is O(n^2) I'm stating that as n->infinity the runtime of
               | the algorithm |R| <= c * n^2, where c is some constant.
               | 
               | This is still true of exp^n, since |R| <= c _n^2 <=
               | d_exp^n. Or at least based on my analysis background I'd
               | expect this behaviour. It is of course a little pointless
               | to say the algorithm is O(exp^n), but that's a different
               | issue. It is still an asymptotic upper bound.
               | 
               | I just checked my copy of Sipser. Example 7.3 on page 249
               | if you care. They give an example that f_1 is O(n^3) and
               | state it is O(n^4) also, since n^4 is also an (asymptotic
               | bound) bound.
               | 
               | But this is not the point. I have no formal computer
               | science education at all (my background is mathematics,
               | some logic if that counts, but I've never studied
               | algorithms) but many interviewers insist on this one
               | specific area of CS, and yet if you attempt to engage
               | them on the meaning of the things then unless you are
               | very lucky they will a) make some excuse about how they'd
               | have to check, their degree is a while ago, or b) they're
               | actually only reciting also.
               | 
               | I'm strongly of the view this is a massively cargo-culted
               | interview question of questionable to no value for most
               | software engineering jobs, given that interview time is
               | very limited and there are many more important factors to
               | evaluate.
        
               | randomtwiddler wrote:
               | You seem to be missing the entire point of this kind of
               | question. Yes, you are providing an upper bound. But as
               | you yourself admit, your answer is useless. The point of
               | big o is to put the lowest reasonable bound on an
               | algorithm so they can be compared.
               | 
               | Your approach is basically interview trolling.
               | 
               | I don't use big o in interviews. That's more the domain
               | of big data than the web slots I typically fill. I'm more
               | interested in the depth of understanding they display in
               | the techs they claim to know.
        
               | randomtwiddler wrote:
               | A follow up. I'm more interested in a devs understanding
               | of memory complexity than time complexity. Every single
               | production performance issue I've seen out side of
               | academic questions had been due to memory management
               | issues.
        
             | dhd415 wrote:
             | I suspect that lots of people ask for O(n) when they mean
             | Th(n) instead which specifies both an upper and lower
             | bound. For example, specifying Th(n^3) as the running time
             | for a bubble sort would be incorrect whereas O(n^3) would
             | be imprecise but not incorrect.
        
           | ThrustVectoring wrote:
           | Most of the value of understanding computational complexity
           | of code is that you get a little voice saying "hey, this is
           | probably going to cause issues on larger data sets" after
           | writing something that passes tests and works on small pieces
           | of trial data. A Chinese-Room understanding of O(n^2) vs O(n)
           | and O(1) is _plenty_ for noticing these, and may actually
           | out-perform a more thorough understanding; what you want is
           | to notice things going quadratic as you rush through a code
           | review or slam out a feature, and that is almost entirely
           | reliant on pure pattern recognition.
        
           | jtagen wrote:
           | Upper bound? I thought it was a tight asymptotic lower bound.
        
       | germinalphrase wrote:
       | There is a lot of questioning and helpful back-and-forth in this
       | thread, so I'll toss myself in:
       | 
       | I have been working as a high school English teacher since 2012.
       | Without a doubt, large parts of this job reinforce and feed my
       | core values. I am acutely aware that my job, and the
       | relationships that I develop, matter in a meaningful way;
       | however, my engagement with the job has shifted over the last
       | three or four years, and I recognize that it is time for me to
       | step away from the classroom.
       | 
       | I am not jaded, burned out, or coasting on my commitments. I am
       | merely looking for the next door to open come June.
       | 
       | If anyone is willing to connect about UX/UXR, Product Management
       | - my email is in profile.
        
       | cjvirtucio wrote:
       | >Knowing that I had two offers, and that I had gone through a
       | very long process with them and having received an offer, I knew
       | that I was a candidate they'd like to hire. This is the perfect
       | time to get that extra worth, as you hold a lot of the chips,
       | especially with two offers.
       | 
       | This has always been really hard for me to do, particularly if I
       | actually am happy with the offer. It could be imposter syndrome,
       | where I often feel like I don't "deserve" it.
        
         | throwaquestion5 wrote:
         | I would try to disassociate my work income from my personal
         | worth as a worker. We always leave some money on the table, but
         | can always do all the steps we can to reduce how much we are
         | leaving on it.
         | 
         | In case I have an offer that I'm actually happy with,
         | personally I'm the opposite. I already reached my expected
         | range, failing to negotiate for more doesn't worry me so I can
         | do it more confidently, which may kind of help me in a way.
         | Don't ask for too little tho, they may notice they can get you
         | less than what you are asking by holding firm.
        
       | mattbee wrote:
       | Well done on landing the position but I wouldn't expect your
       | transparency to be reciprocated from Deliveroo.
       | 
       | I tipped a driver PS15 through the app the other day, he turns up
       | and thanks me for the PS7.50. Shows me his end of the
       | transaction: Tip, PS7.50.
       | 
       | I was so embarrassed I ran to find a fiver. I guess watch your
       | contract and payslip eh.
        
       | durnygbur wrote:
       | hahaha booking.com, I got rejected after screening call.. they
       | must be swarmed with geniuses, or they are probing the market for
       | current salaries, or they're looking for someone ready to
       | relocate to Amsterdam for 65k EUR. What an enigma.
        
       | tacrolimus wrote:
       | Just sent two-week notice last week. ~30 applications, 3 offers.
       | I was interviewing with both tech and "non-tech" (software
       | engineer/research role at traditional STEM companies). The stark
       | difference is that for tech companies the track record carries
       | little weight (me with 10+ years dev experience, proprietary and
       | open-source), while in "non-tech" companies the decisions almost
       | solely based on my experience (projects, publications, etc). For
       | the latter all I needed to do is either give a presentation or a
       | round of 1-1s chatting about my work. The tech company interviews
       | gave me an impression of being replaceable: passing these tests
       | then we'll welcome you as a screw of our well-oil machine. What
       | gets me most is that I was still got asked behavior questions
       | like "do you think you are a team player?". (I decided to be
       | snarky on that FANNG interviewer and told her "I like being left
       | alone". I was put off by the fact that she's wearing a mask in
       | our 1-1 zoom meeting anyway).
        
         | throwaway83242 wrote:
         | >> I was put off by the fact that she's wearing a mask in our
         | 1-1 zoom meeting anyway
         | 
         | This is unfair. I was in the woman's shoes recently. Somone in
         | her family may be having Covid!
        
           | tacrolimus wrote:
           | She's in the company office (glass doors/walls, people moving
           | in the background, etc). From my view it seems I was on a
           | projector.
        
       | BlargMcLarg wrote:
       | >Time consuming
       | 
       | >The only company that gave me any compensation for the interview
       | process was GitPod
       | 
       | >Another thing to note is that I ended up not really preparing
       | for the interviews. I feel like this is a bit of an arrogant move
       | by me
       | 
       | And that's how they get you. You invest into what's essentially a
       | second full time job, without any guaranteed compensation, yet
       | somehow you feel _you yourself_ are the arrogant one for not
       | doing more. That 's not even highlighting all the other emotional
       | effects the process had on the author, and the author is by no
       | means "average" in their methodology.
       | 
       | Let's push back against this, please.
        
         | PartiallyTyped wrote:
         | I have been trying to find a job for the past 2-3 months, and
         | the psychological toll that it has taken on me is enormous.
         | 
         | I planned on going for a PhD, but eventually got tired of
         | academia and of practically starving. I am finishing my
         | master's in December. I have sent out my CV for review in
         | r/cscareerquestionsEU, I have received good feedback, I have
         | been told that my CV is strong and that I may be suffering from
         | my own successes.
         | 
         | Most of the responses by companies are flat out rejections
         | without any information as to how or why. I have been told that
         | I am overqualified for positions. By others that I was
         | underqualified. I have been given excuses of the form "we are
         | looking for somebody who has more experience with XYZ tech" as
         | if there is some kind of barrier that prevents somebody from
         | learning said tech.
         | 
         | At this point I am practically begging for anything to not
         | starve and pay the bills.
         | 
         | I am really sorry for venting here, but I am at a breaking
         | point.
        
           | erikerikson wrote:
           | I was right where you are about 18 years ago. Take heart. I
           | still have challenges finding roles even with excellent
           | credentials, patents, open source projects, successful
           | companies, massive successes, and demonstrated excellence. It
           | is always a bit wrenching.
           | 
           | I have a brother in law struggling in a similar position to
           | yours.
           | 
           | Something helpful that I've learned being on both sides of
           | the table many times is how much of a random process it can
           | be. The bulk of the effect has nothing to do with you. I find
           | that infuriating but it also has helped me deal with the
           | petty, arbitrary, and sometimes just evil experiences to be
           | patient for the right fit.
           | 
           | Feel welcome to reach out. Contact in profile.
        
             | DeathArrow wrote:
             | Nice to wanting to help the guy.
             | 
             | I feel that being trained as a software developer is not
             | enough to find a good job. You have to seriously train in
             | job finding. How to write your CV, where to find listings,
             | to which position to apply, what questions are asked on
             | interviews for the positions you are interested in, what to
             | tell on a interview, what not to tell.
             | 
             | I've changed my job 3 years ago after a long time with a
             | company. I was scared about the process, but after some
             | preparation and a few interviews I began to do well. I kind
             | of knew what I will be asked and replied to interviewers
             | what they wanted to know. After 2 years I changed my job
             | again and it was easy. Now, I am at it again and I doesn't
             | seem too difficult. I do better than many engineers.
             | Probably I am not a better developer than them, but I am
             | better prepared for the interviews. Even the way you talk
             | and how you project your confidence matters. If you "read"
             | the guy doing the interview, tell a joke that he will
             | appreciate, talk about something that you think he will
             | approve, will win you bonus points. Being pleasant, Mr Nice
             | Guy, will help because interviewers are people and they
             | want to have good team mates who they will have a great
             | time working with. This might even be more important than
             | engineering excellence.
        
               | erikerikson wrote:
               | I agree that there are factors unrelated to ability to
               | fulfill the role that increase the probability that a
               | person is hired. That is simply a failure that some are
               | more willing and or able to take advantage of. A good
               | process evaluates ability to fill the role.
        
           | BlargMcLarg wrote:
           | Don't be sorry. If anything, people should be venting more
           | and showcasing the absurdity of the job market. We've
           | normalized the idea of just biting through a really
           | emotionally taxing time for no particular reason and
           | companies are taking advantage of it.
        
           | DeathArrow wrote:
           | You should find a position as a junior developer without much
           | problems. Right now is a big need for developers in many
           | countries.
           | 
           | Try to see what is the best web site for your country /
           | region to find developer work. For me is LinkedIn. Prepare a
           | bit more for the interview. By now you should know the type
           | of questions asked.
           | 
           | You can ask right here on HN for a jobs. Also there are
           | periodical jobs posting on HN, you just have to search and
           | find when.
           | 
           | I wish you good luck.
        
             | PartiallyTyped wrote:
             | My skillset is mostly in Machine Learning. I had ML
             | internships, research assistantships, an MLE contract.
             | 
             | I can't get junior dev jobs because they are asking for
             | $tech-du-jour and they told me that, they told me that they
             | don't care that I have a master's from one of the top
             | universities in Europe but they care that I lack experience
             | with a particular tech stack.
        
           | ensan wrote:
           | Why not apply to PhD/MSc programs in the US?
           | 
           | The PhD stipend is well above starvation levels and you can
           | go to internships during summer to earn more money and
           | accumulate experience. I have seen many, many people in FAANG
           | with PhDs in SDE/DS roles and they can relatively quickly
           | reach senior levels as well.
        
             | PartiallyTyped wrote:
             | They are too competitive and my odds of getting in one are
             | slim to none ._.
        
               | ensan wrote:
               | I don't know your situation but I while there are
               | certainly ultra-competitive CS programs (e.g., Stanford,
               | MIT, Berkeley, CMU), there are many research-focused
               | universities in the US (R1) that are totally good-enough
               | for doing research and getting a recognized degree. In a
               | lot of less competitive universities, there is no
               | admission committee per se; you just email the faculty
               | you're interested in and if he wants to recruit you, then
               | it's basically done.
               | 
               | There are good research universities in the R2 list as
               | well (RIT, IIT, etc.)
               | 
               | https://en.wikipedia.org/wiki/List_of_research_universiti
               | es_...
        
           | stackbutterflow wrote:
           | I too was looking for a job last year and it made me wholly
           | depressed. Rejection after rejection, not knowing whether I'd
           | be ask a leetcode easy, or medium, or whether I'd be grilled
           | on some obscure/gotcha language features (C++ takes the crown
           | in that domain). The randomness of it all, passing the
           | technical tests but failing the interview with the CEO. The
           | wide range of topics on which you might be quizzed on.
           | Frontend, backend, javascript quirks, typescript. You worked
           | with C++ 3 years ago? Then tell me what that piece of code
           | does. Sorry it's undefined behavior according to the page 756
           | of the C++ standard version 17. You don't know how to answer
           | this question about databases and you call yourself a backend
           | developer? You don't know this very specific feature of SQL?
           | Solve this leetcode problem for me. And then again the next
           | day, and the next day, and the next week. And the week after
           | that. And it's been two months and you've been rejected 10
           | times. And then you go on HN and you read that the market is
           | hot, the market is white hot! But you, you're ready to snap
           | at the first offer that comes to you because you're
           | emotionally drained. Leetcode in the morning, sending
           | applications in the afternoon, then some leetcode again
           | before going to bed. Repeat everyday, even on weekends.
        
             | DeathArrow wrote:
             | Hold on and try to resist. Also, try to focus on one
             | language / one position. For example you can chose backend
             | / C#. Or Frontend / React. Or systems programming / C++.
             | 
             | In my opinion, if you already went to a few interviews for
             | the same role, you kind of know what kind of questions you
             | are asked.
             | 
             | Also, I find leet code as a waste of time in preparation
             | for the interviews unless you shoot for a FAANGs.
             | 
             | Good luck!
        
           | avereveard wrote:
           | It took me two year to change job. The expectations are
           | absolutely bonkers right now, the selection process
           | capricious and often even if you jump all the hurdles there's
           | little guarantee that salary on offer comes close to what was
           | in the job listing.
        
             | DeathArrow wrote:
             | I kind of succeeded in changing my job in a 2 weeks - a
             | month at most. A few times. It probably depends on the
             | exact field you are in.
        
               | avereveard wrote:
               | Makes sense, I'm a generalist, so I've much more
               | competition.
        
           | lelanthran wrote:
           | > Most of the responses by companies are flat out rejections
           | without any information as to how or why. I have been told
           | that I am overqualified for positions. By others that I was
           | underqualified.
           | 
           | Can't both be true?
           | 
           | You have a part-PhD, hence too qualified for almost all
           | entry-level dev jobs.
           | 
           | You have too little experience, hence underqualified for any
           | non-entry-level dev job.
        
             | PartiallyTyped wrote:
             | I don't think I expressed that they can't.
             | 
             | I was expressing that I am in a situation where I am too
             | specialized for regular SDE roles but at the same time I
             | lack the experience to get anything beyond those.
             | 
             | I don't know what to do at this point to be honest.
        
           | ushakov wrote:
           | > At this point I am practically begging for anything to not
           | starve and pay the bills
           | 
           | maybe we need a society where you would not need a job to not
           | starve?
           | 
           | what happens to people who cannot get a job, do we just let
           | them starve?
           | 
           | what are your thoughts?
        
             | PartiallyTyped wrote:
             | I have previously expressed that I do not mind working more
             | or paying more in taxes if it means that the community
             | around me benefits from it. I see it as a form of mutual
             | aid. It is in everyone's best interest to help our
             | community and make up for each other's bad luck.
        
           | motiejus wrote:
           | You said EU? Uber (my team) is hiring in Vilnius, if you are
           | into Eastern Europe. I have been there for 6 years, can
           | recommend.
           | 
           | Feel free to send me your CV (contact details in my profile),
           | I'll comment or put it to our system.
        
         | lbriner wrote:
         | I got the idea for the take-home test from the Remote book by
         | Hansson and Fried and I think what they spelled out made sense:
         | 
         | 1) Give them a realistic task to work on - this is what you
         | want them to do if you hire them 2) Give them a reasonable
         | amount of time 3) Pay them for it - why wouldn't you?
         | 
         | We did this for one candidate and although your gut feel as an
         | employer is sometimes, "is this a waste of PS1000"? but if you
         | are already quite far on in the process, you probably think
         | they might be good enough and that PS1000 is offset against the
         | Recruiter fee that you incur when a hire doesn't work out or
         | the loss of a good person you don't hire because you are not
         | sure.
         | 
         | It also shows good will between employer and applicant. We have
         | done it once so far and didn't take on the person but gave them
         | feedback on the task and because they were paid, they didn't
         | see it as a waste of time.
        
         | VoodooJuJu wrote:
         | >Let's push back against this, please.
         | 
         | I would love this, but the only reason the bullshit is allowed
         | to happen is because people are ready and willing to put up
         | with it. There are simply too many desperate people, many of
         | them third-worlders [1], who will do anything for a meal
         | ticket.
         | 
         | The world would be better if people developed a "fuck you, pay
         | me" attitude, but so many people are inured to their caste.
         | 
         | [1] "Then, don't. I want to move from my 2000 USD a month (this
         | is a good salary alre... | Hacker News." 8 May. 2022,
         | news.ycombinator.com/item?id=24446562.
        
           | dominotw wrote:
           | > many of them third-worlders [1], who will do anything for a
           | meal ticket.
           | 
           | If your people from 'third world' are your main competition
           | then you fucked up your life by not making something out of
           | your 'first world' privilege and educational opportunities.
           | 
           | > The world would be better if people developed a "fuck you,
           | pay me" attitude, but so many people are inured to their
           | caste.
           | 
           | wtf.
        
             | ryandrake wrote:
             | Even disregarding those weird "third world" and "caste"
             | tangents, there are _tons_ of Westerners too who would
             | literally do anything for a software job at a tech company,
             | especially at a prestigious and well-paying FAANG. And, by
             | anything, I mean suffer through any brutal study regimen,
             | inhumane corporate process and any humiliation. Undergrad
             | and advanced degrees, months of leetcode practice, take-
             | home tests and coding challenges, hundreds of phone
             | screens, a dozen rounds of interviews for a single company,
             | staying half-ghosted on a waitlist for months, sending ping
             | after groveling ping to recruiters for updates. There 's
             | nothing that's beneath them, and this willingness to endure
             | pain simply raises the level of pain everyone else has to
             | endure.
        
               | PartiallyTyped wrote:
               | Is that not a testament to how awful the current
               | situation is with respect to the living conditions of the
               | average person and the average salary?
        
         | jt2190 wrote:
         | A senior dev role is an income stream of USD n 000 000 dollars
         | a year, that has certain guarantees about payments. In this
         | context it makes sense to dedicate a considerable amount of
         | personal time and effort to capture one.
         | 
         | > ... yet somehow you feel you yourself are the arrogant one
         | for not doing more. That's not even highlighting all the other
         | emotional effects the process had on the author, and the author
         | is by no means "average"
         | 
         | Learning techniques for managing one's emotions and stress
         | levels can pay huge dividends here.
         | 
         | Part of that is stepping back and realizing that the "rules of
         | the game" of resume/interviews/offer were written by employers,
         | for their benefit first. (One technique for addressing this is
         | to beak out of this process, and reach out to hiring managers
         | directly. Professional sales people do this all the time; I'm
         | not sure why selling labor is somehow magically different.)
        
           | DeathArrow wrote:
           | >A senior dev role is an income stream of USD n 000 000
           | dollars a year
           | 
           | That's true for US. In most parts of the world developer
           | salaries are much lower.
        
             | jt2190 wrote:
             | I suppose that since Jamie is based in Nottingham, U.K. [1]
             | then we should adjust the currency and number of zeros for
             | his particular locale. My understanding is that senior
             | software developer roles in the U.K. are _also_ considered
             | professional-level jobs that pay very well relative to
             | other professional-level jobs in the local labor market,
             | similar to the U.S., and are worth putting in some extra
             | time and effort to get.
             | 
             | I think the same is true about senior software developers
             | in many other countries: They are professional-level jobs
             | that pay well relative to other professional-level jobs in
             | the local market, and they're definitely worth taking some
             | time and effort to get.
             | 
             | Feel free to provide specific examples of countries where
             | this isn't the case.
             | 
             | [1] "README" https://readme.jvt.me/
        
               | PeterisP wrote:
               | It's not only that the rate is adjusted for locale but
               | that the disparities in USA are much larger.
               | 
               | In USA a very senior engineer at a FAANG in California
               | will earn 20x times more than a junior engineer at some
               | small midwest company. In UK a very senior engineer in
               | London will earn perhaps 4x that of a junior engineer in
               | Wales.
               | 
               | In USA "pays very well relative to other professional-
               | level jobs in the local labor market" will often mean a
               | compensation that's double or triple of those other jobs;
               | in UK "pays very well relative to other professional-
               | level jobs in the local labor market" would imply a 20%
               | or 30% difference.
               | 
               | That makes a meaningful conceptual difference.
        
         | [deleted]
        
         | snarfy wrote:
         | Compensation for an interview for a job that even poorly
         | compensated would put you in the top 5%? Talk about privilege.
         | I'll happily do the interview on my own time for that potential
         | payout. Push back? I'll be taking your job.
        
           | p1esk wrote:
           | Unless you know you're good and everyone wants you.
           | Otherwise, yeah, good luck with pushing back.
        
           | user_7832 wrote:
           | The problem with "letting the market decide" (which is very
           | similar to what you're suggesting - "If you don't want the
           | interview I'll take it!") hides long term (negative) impacts
           | and costs. "Letting the market decide" has made fossil fuels
           | cheap enough that we've got a climate crisis.
           | 
           | "Sure, we destroyed the planet, but for a brief period of
           | time the hand of the market ruled fair!"
        
           | BlargMcLarg wrote:
           | That's an awful lot of assumptions. These practices are
           | happening outside the very lucrative tech hubs as well. If
           | this was just the hubs, that'd be something else entirely.
           | 
           | Nor do I believe constantly encouraging more and more
           | competition is in anyway healthy for society as a whole.
           | Companies are already facilitating burnout cultures as is,
           | and it's not at all evident if this benefits them in the long
           | run.
        
             | scarface74 wrote:
             | Even if you aren't in the "very lucrative tech hubs" and
             | you're making about $140K, a salary you can get in any
             | large metro area in the US within 5-7 years and strategic
             | job hopping, it still puts you in the top 10% of earners
        
               | [deleted]
        
               | lotsofpulp wrote:
               | Top 10% does not get you as much as it used to these
               | days.
        
               | scarface74 wrote:
               | Amazingly people aren't living in their cars and starving
               | on _only_ $140K...
        
               | ushakov wrote:
               | you should add _yet_ to it
               | 
               | inflation eats the bottom out and soon enough $140k will
               | be barely enough to make the ends meet
        
           | giantg2 wrote:
           | I wish I was on the top 5%...
        
           | pmoriarty wrote:
           | This is a race to the bottom.
        
             | themacguffinman wrote:
             | That's...generally what competition is.
        
         | golergka wrote:
         | Doesn't the company invest significant amount of money in the
         | process too?
        
           | diatone wrote:
           | Does "the company" need to sleep?
        
             | golergka wrote:
             | The company is built by investment from VCs from hedge
             | funds from 401k or pensions of real people who not only
             | need to sleep, but on average make less then senior
             | software engineers.
        
           | Ozzie_osman wrote:
           | Depends on the company, but they should. This is a big
           | decision for both the company and the candidate. Both should
           | put a little effort into it to avoid a situation where
           | someone who is hired is unhappy or not a fit for whatever
           | reason.
           | 
           | The secret is to make sure the time invested on both sides is
           | actually increasing signal, and to make it symmetric (ie at
           | any point in the interview process both sides should have
           | invested roughly the same amount of time).
        
           | BlargMcLarg wrote:
           | Wouldn't that be _more_ reason to push back against this?
           | 
           | There's an implicit assumption that more sessions -> more
           | security. I've yet to find evidence this session inflation is
           | doing anything beyond making companies _feel_ more secure.
           | 
           | Same goes for a lot of other things related to interviewing.
           | If there's no clear evidence, it should be treated as the
           | bread and circuses it is.
        
             | spyspy wrote:
             | I've found that the more people you throw at a candidate
             | the higher the chances that _someone_ is going to find
             | _something_ they don't like about him/her and burn them in
             | the end, especially when approvals have to be unanimous.
             | I've seen engineers give glowing praise for one particular
             | candidate but they got passed on because they made some
             | comment about disliking scrum/agile/jira and that just
             | rubbed the 2nd project manager they interviewed with the
             | wrong way.
        
               | dangoor wrote:
               | A counterpoint to this is that our process generally
               | looks for at least one "Strong Yes" among the
               | interviewers. While they do come up, there aren't _that_
               | many "No"s in the results, but there are a lot of just
               | "Yes" results.
               | 
               | Not saying it's a perfect process, but just providing a
               | counterpoint that our process actually seems more likely
               | to help someone with the rounded set of interviews we
               | have than we would with fewer.
        
               | dotBen wrote:
               | _I've found that the more people you throw at a candidate
               | the higher the chances that _someone_ is going to find
               | _something_ they don't like about him /her and burn them
               | in the end_
               | 
               | I can't emphasize this enough. Successful interviewing is
               | about pattern matching and what this really speaks to is
               | more people means greater risk someone isn't properly
               | calibrated on their pattern matching and their feedback
               | negates someone else who's pattern matching is spot on.
        
               | tough wrote:
               | Right on. Never say anything you've not been asked for.
               | You don't need to create traps for yourself.
               | 
               | Interviewing sucks...
               | 
               | The best jobs I had I just started on -trial- or whatever
               | doing good work on their GH and from then i'ts pretty
               | easy to know if we're a match or not.
               | 
               | (Paid) Trialhires should be a more common thing.
               | 
               | Companies should hire and fire more easily. I just don't
               | understand I work mostly as a contractor so they really
               | can fire me with 1, 10, or whatever days in advance...
               | 
               | It's not like I'm an employee with protection to being
               | fired or compensation or whatever...
               | 
               | Why so much hassle?
        
               | NikolaNovak wrote:
               | I think that works great for 1st job.
               | 
               | Once you are in your... 30s 40s 50s etc, maybe family and
               | mortgage... You're not going in for a two week trial
               | hire.
               | 
               | ANd it may not make sense for companies either. A lot of
               | positions I hire for need 3 months to be productive. The
               | level of business and client knowledge, as well as prices
               | and policy understanding required for tech positions is
               | high. That may not be the vocal HN experience which is a
               | lot about interchangeable tech on modern frameworks but I
               | think actually comprises a lot of enterprise IT.
               | Basically we need to invest a lot in you before you are
               | productive and we can truly judge fairly your actual on
               | the job performance.
               | 
               | Heck if you work for public sector, you may not get your
               | laptop and Id in first two weeks at all :-)
        
               | DeathArrow wrote:
               | > I think that works great for 1st job. Once you are in
               | your... 30s 40s 50s etc, maybe family and mortgage...
               | You're not going in for a two week trial hire.
               | 
               | In my country all companies are having a 3 months
               | probation period, when they can fire you without notice
               | or reason, as the laws allow it.
        
               | ghaff wrote:
               | Yes, there are often probationary periods with varying
               | degrees of formality. But, in practice, these are mostly
               | reserved for something going really wrong in the hiring
               | process, e.g. someone not being able to do things that
               | they said they knew well.
               | 
               | A trial period _could_ be the same thing but it could
               | also be  "We usually extend permanent offers to about a
               | third after the trial period." If it's a formality that
               | may be one thing. If it's an extension of the interview
               | process, that's something else.
        
               | jameshart wrote:
               | But they're not using that's a a substitute for
               | interviewing, right?
        
               | codenesium wrote:
               | In the U.S. that's called at will in most states. They
               | can fire you for no reason as long as it's not one of the
               | limited reason protected by the federal government. It
               | doesn't matter how long you've worked there.
        
               | BlargMcLarg wrote:
               | >The level of business and client knowledge, as well as
               | prices and policy understanding required for tech
               | positions is high.
               | 
               | Whenever I read this advice, I get "indie game developer"
               | vibes. Indie game developers wear many hats and need a
               | lot of breadth for obvious reasons: they don't have a lot
               | of funds, they don't have a lot of people, they don't
               | have a lot of specialist work you'd need someone for full
               | time, but they do have a lot of different things that
               | need to be done.
               | 
               | Then I compare it to your regular corporate job, and it's
               | the opposite in many ways. Tons of people. Tons of funds.
               | Some people very specialized, some people somewhat
               | generic for flexibility purposes. It makes me question
               | why a developer in a corporate setting would need high
               | levels of "business and client knowledge", or even
               | "prices and policy understanding". Not because they
               | aren't useful in theory, but because there's almost
               | always someone with far more knowledge and decision-
               | making power pulling the strings, to the point having
               | such dedicated knowledge is more a waste than anything.
               | The developer can't get to their level without
               | sacrificing development time, or being with that company
               | for a ridiculous number of years.
               | 
               | And we already know companies in general aren't
               | optimizing around long tenures.
        
               | pph wrote:
               | It's not reasonable to expect a candidate to give up
               | their secure job / salary for a two week trial. It gets
               | more complicated as within the first weeks you're
               | probably mostly ramping up and not very productive yet,
               | so it's both a cost-sink for the company and difficult to
               | judge anyhow.
               | 
               | For fresh graduates this might be more viable, but
               | internships are already a thing.
        
               | vsareto wrote:
               | Trials should be an option but not the only route.
               | Multiple interview formats would be good too.
        
               | rapind wrote:
               | This is contract to hire which is perfectly valid but not
               | something most companies will agree to.
               | 
               | I think it's due to conflicting goals. The department
               | hiring wants to lock in the employee so they can cross it
               | off their todo list, and fix the cost. They don't want to
               | train a consultant who's still lining up other work. Once
               | the consultant has been trained he or she is in a better
               | negotiating position since they haven't agreed to a
               | salary yet.
               | 
               | Corporate wants to require a probationary period so they
               | can wiggle out of it with least expense in the unlikely
               | event they have to.
               | 
               | Ideally after a probationary period the employee can
               | renegotiate their compensation, but this is seen as bad
               | faith and holding the company for ransom and creates bad
               | feelings.
        
               | rapind wrote:
               | It's funny because I literally just a just ran into a
               | friend who owns a restaurant after I posted.
               | 
               | He complained about being short staffed and not being
               | able to handle the cooking work while being sociable with
               | customers (he's one of those guys who sits down with his
               | customers).
               | 
               | I asked him what happened to his last chef. He said he
               | trained her up and she quit, so now he's screwed. I asked
               | him if he could have kept her if he paid her more. He
               | looked at me like I was crazy and said she was already
               | being paid too much. I responded, Oh, so you couldn't
               | afford to pay her more? He said it wasn't about that, it
               | was just crazy that he should have to pay her more.
               | 
               | I kept my opinions to myself and just said "I hear ya.
               | That's rough man." He said "Loyalty is dead"...
               | 
               | I didn't make up a word of this.
        
       | ensan wrote:
       | Is it just me, or are the salaries much lower in UK than in US?
       | Why?
        
         | maxlamb wrote:
         | The US by far leads the world in profitable software companies
         | and venture capital funding. The competition for talent in
         | Silicon Valley combined with the huge amount of money
         | generated/raised ends up increasing US engineer salaries even
         | outside California over time.
        
         | jamietanna wrote:
         | We don't have to pay for healthcare for one ;D
         | 
         | Cost of living is generally lower AFAIK, too
        
           | kitten_mittens_ wrote:
           | I wonder what that looks like versus Purchasing Power Parity.
           | https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(PPP)
           | 
           | My salary in Germany (EUR60K) and apartment in a not great
           | neighborhood was EUR900 a month.
           | 
           | Here in the US, I pull $150K and spend ~3K a month on a
           | studio. I think my standard of living in Germany (besides
           | desperately missing air conditioning) was roughly the same.
        
       | lelandfe wrote:
       | Interesting how different our job market experiences were.
       | 
       | First, only 8 applications! That's fantastic - I likewise am
       | starting a senior software eng role... but after 6 months of
       | unemployed full time interviewing, and around 80 applications.
       | FE, not BE, though.
       | 
       | In terms of content, I think _every_ coding round required time
       | /space complexity analysis, and (as an FE!) most had me doing
       | things like building recursive binary tree checkers, solving
       | medium Leetcode problems, etc.
       | 
       | > I made a point of challenging it and asking whether it was
       | representative of the role
       | 
       | Yes! Love this. I had a systems design round, which are usually
       | my time to shine, that focused exclusively on designing an app's
       | database. A DBA I am not, and I essentially flunked. I brought it
       | up to their CTO on a later call, as I really didn't think that
       | was a fair assessment of me.
       | 
       | That wound up being the place that hired me :)
        
         | sage76 wrote:
         | 80? I'm at 600 already, fuck me.
        
         | pranit10 wrote:
         | Good to see I am not the only one interviewing a ton. I have a
         | different experience than yours for FE interviews. No leetcode
         | questions. Mostly take home or live coding React/Vanilla JS
         | stuff. No system design rounds either mostly talking about the
         | tech stack in breadth and sometimes in-depth.
        
           | lelandfe wrote:
           | This was my first time going after "senior" titles, and was
           | also the first time I'd seen system design interviews. They
           | only cropped up in final rounds. I had them at Amazon, Uber,
           | and three other companies.
           | 
           | I was supremely nervous about them before but I actually
           | wound up doing really well (save aforementioned DB crap). It
           | was a chance to talk about my personal niches, like
           | accessibility and load times.
           | 
           | Frustratingly, every single one was wildly different. I found
           | that approx. 0 of the "cracking the system design" stuff I
           | read beforehand helped in anyway.
        
           | ryandrake wrote:
           | You guys are not alone. My last job search was probably on
           | the order of 100 applications, 10 interviews, 1 offer. It's
           | been this way my whole 20+ year career. I don't know who
           | these Captains Of Industry geniuses are who are getting
           | multiple offers from 20 job applications, but I'm sure it's
           | not the norm.
        
             | tester756 wrote:
             | is this some US thing?
             | 
             | here in Eastern EU if you have >= 3 years of xp then
             | probably almost all of companies that are hiring will try
             | to talk to you if you apply
             | 
             | ofc if your skills/tech matches their requirements somewhat
             | reasonably
        
               | ChuckNorris89 wrote:
               | _> is this some US thing?_
               | 
               | Western EU thing as well. There's an oversupply of
               | candidates (everyone wants move/live here) and a low
               | supply of jobs (in some countries), so companies can
               | afford to be very picky.
               | 
               | Eastern EU has the opposite phenomenon, oversupply of
               | jobs due to outsourcing/nearshoring coming in, and lack
               | of skilled candidates since may skilled ones moved west.
        
             | [deleted]
        
       | 1970-01-01 wrote:
       | Hunt often! If you aren't _in love_ with your current job, just
       | keep looking. A good pace is to apply (to more interesting and
       | overall better jobs) every month.
        
       | motohagiography wrote:
       | > I thought back to something a friend of mine says, "channel
       | your inner middle-aged white man who'd feel entitled to ask for
       | more". (Note that this is a statement said in jest, based on
       | research that men are more likely to ask for raises, and doesn't
       | have any racist undertones)
       | 
       | While I take the joke and sentiment at face value, as a member of
       | said demographic, the word I think they were looking for is
       | "dignity," and while it's a rare quality nobody has a monopoly
       | on, it is precisely the value that institutions try to grind out
       | of you, and what you need to negotiate effectively. It's the
       | x-factor in leadership, the quality that causes dogs to stop
       | barking, the dishonest to froth, women to swoon, children to feel
       | safe, young people to seek mentoring, customers to sign with
       | enthusiasm, staff to be loyal, trades to do a bit extra, service
       | workers to feel elevated, antagonists to cease their hostilities,
       | and yes, employers to give due consideration to whether they have
       | made their best offer.
       | 
       | It was a funny aside in a valuable article, and self-deprecation
       | is a peculiar UK/CAN thing, but I didn't get the impression the
       | author knew enough to make a joke about it, and they should be
       | more confident in the value and integrity they can provide, as
       | they've done some really cool and fasctinating stuff and should
       | own that.
        
         | [deleted]
        
       | fullstackchris wrote:
       | > This other company, however, gave me feedback that "if this was
       | how you worked on a team, it'd be perfect, and we love it. But in
       | an interview, that's not what we want"
       | 
       | The tech interview process is still so completely broken in my
       | book. Nobody really knows what anybody wants or how to show it 1
       | hour blocks (for both parties - applicant and employer)
        
         | evandale wrote:
         | It's such baffling feedback. I can't even comprehend what it's
         | supposed to mean or why someone would say it. Are they trying
         | to look for a rock-star interviewer who is a total disaster for
         | the team?
        
           | marcinzm wrote:
           | It's possible they had a rubric for the interview which
           | implicitly assumed a certain way of answering. Since the
           | whole point in that case is to strictly follow the rubric to
           | lower bias they had to reject.
        
           | [deleted]
        
         | [deleted]
        
       | daniaal wrote:
       | Did you have to solve a leetcode problem for the deliveroo
       | interview?
        
         | jamietanna wrote:
         | Nope, it was a different test
        
           | daniaal wrote:
           | Thanks :)
        
       | [deleted]
        
       | throwaway4good wrote:
       | Nice to see the openness about salary.
       | 
       | The numbers he quotes (90 uk pounds for remote work) - is that
       | normal for the UK atm?
        
         | jamietanna wrote:
         | Not particularly - in London, or with a lot of high-funding
         | startups it's more common, but across the country no.
         | 
         | Makes it much harder for local companies to try and compete,
         | even if they're very big. If you see my salary changes over the
         | last year, it's a considerable jump.
         | 
         | Either way, I'm aware I'm gonna be working quite a bit for it
         | :D
        
           | wirthjason wrote:
           | A comment on the CV. At quick glance it looked like you only
           | worked at places for a year or two then changed. This is
           | generally a red flag for me. But because I saw the salary
           | history I knew there was a Lon time at Capital One. However
           | this was harder to spot on the resume. It might be better to
           | group your experience at a single employer together so your
           | loyalty stands out.
           | 
           | I'm curious if employers ever saw your salary posts and
           | responded.
        
           | throwaway4good wrote:
           | Congrats on it.
           | 
           | It is apparently a statistical fact that keeping salaries
           | hidden and or confidential causes lower salaries.
           | 
           | So what you do here is applauded in our current world of high
           | inflation and record corporate profits.
        
             | jamietanna wrote:
             | Thanks. Yeah that's why my salaries/compensation detail are
             | all public, so I can try and help nudge the needle a bit
             | towards at least having ranges available everywhere.
        
         | rjh29 wrote:
         | It seems highly variable, I have friends on 110k+ with huge
         | bonuses, I also have friends on 30k. 90k is very high for a
         | fully-remote job IMO.
        
           | lbriner wrote:
           | It seems mainly driven by the funding of the company. A large
           | bank or oil company in the city can easily afford to pay Devs
           | a large salary which is less than their investment bankers
           | which generally means London.
           | 
           | Others like Just Eat made a massive VC raise and had money to
           | burn so why not offer 20% above everyone else and get the
           | pick of the best? They were advertising for Team Leaders in
           | Bristol for around PS130K, way more than most people across
           | the country could hope to get.
           | 
           | Of course, with the salary comes the burden of perhaps being
           | part of a much larger team, which might mean more variation,
           | things not scaling or feeling lost in the machine, not making
           | a difference in the big picture.
        
       | egman_ekki wrote:
       | > company [***] gave me feedback that "if this was how you worked
       | on a team, it'd be perfect, and we love it. But in an interview,
       | that's not what we want"
       | 
       | What a weird feedback. That sounds like a miscommunication that
       | the interviewer would be responsible for.
        
         | [deleted]
        
       | jhatemyjob wrote:
       | My god. They are doing you DIRTY. 8 years of experience and only
       | making 90k euros??? My first job out of college i was making
       | $105k. OP should be making AT LEAST $400k by now.
       | 
       | Reading his compensation history is making me depressed. What a
       | waste of a career! I would take this page down and switch jobs
       | ASAP. You could easily make 3x your current income.
       | https://www.jvt.me/salary/
        
         | [deleted]
        
         | id wrote:
         | There are senior developers making less than 30k euros in
         | Europe. $400k is absolutely unheard of. Not even CTOs make that
         | much!
        
           | jhatemyjob wrote:
           | I hope you're joking about the senior 30k euro salary. I'd
           | switch careers entirely if I was making that little. My
           | father makes double that driving a bus part time.
           | 
           | If what you're saying is true, the european market is fucking
           | abysmal.
        
             | chillel wrote:
             | yes it is. it really is.
        
       | draw_down wrote:
        
       | zabzonk wrote:
       | > "Senior" is a title with a different meaning everywhere
       | 
       | And so is meaningless. Can we just get rid of this "I am a
       | senior" nonsense? Also "I am a junior", come to that.
        
         | alostpuppy wrote:
         | Yes please.
        
         | throwaway_1928 wrote:
         | I believe "Senior" in tech interviews only means:
         | 
         | * been around longer and more subject to ageism
         | 
         | * more system design questions
        
         | ThalesX wrote:
         | Whenever I interview I present myself as a developer with more
         | than a decade of experience that wants $X / year and willing to
         | go a bit lower for the right company.
         | 
         | Whatever other categorizations they might have for me, is on
         | the company. Ultimately I don't really care.
        
           | DeathArrow wrote:
           | >Whenever I interview I present myself as a developer with
           | more than a decade of experience that wants $X / year and
           | willing to go a bit lower for the right company
           | 
           | I present myself as someone with plenty of experience in both
           | writing code and software architecture. Someone they direly
           | need and will help their business achieve its goals for at
           | least X amount of money. Which would be a great deal for them
           | even if it doesn't sound cheap in the beginning.
           | 
           | Many told me it's too much. But a few have said yes.
           | 
           | You should think about the largest amount you think you can
           | obtain. And add 15 - 20 % on top. You will be surprised in
           | finding that someone will say yes.
        
           | zabzonk wrote:
           | Well, ditto. The most meaningless job title I ever wound up
           | with was "Senior Systems Architect" - really only something
           | they could put on my business cards so they could sell me for
           | consultancy gigs. Bah!
           | 
           | It's not what they call you, it's what they pay you - call by
           | reference versus call by value, I guess.
        
             | mmmpop wrote:
             | > It's not what they call you, it's what they pay you
             | 
             | This is correct because if I'm writing checks, the one
             | making the most is generally my "senior" person.
             | 
             | I suppose this doesn't scale well though, especially when
             | you start talking about niche skillsets where being
             | objectively "good" gets conflated with "useful at the
             | moment."
        
             | bryanrasmussen wrote:
             | >The most meaningless job title I ever wound up with was
             | "Senior Systems Architect"
             | 
             | hah, when I was employed by the Danish under ministry in
             | charge of standardization (called IT og Telestyrelsen at
             | that time) management people came through one day and asked
             | what titles we wanted, and for various amusing reasons
             | another guy and I said we want to be called "XML
             | Architects".
             | 
             | They gave us business cards too!
        
         | sdevonoes wrote:
         | Yes, it's meaningless among developers, but not among
         | recruiters. Since I work first and foremost in exchange for
         | money, I make it pretty clear to recruiters that I am "a very
         | senior software architect with knowledge in X, Y and what not
         | under my belt"... and so, I get more offers and got more money
         | when negotiating an offer.
         | 
         | Among my colleagues, or when someone (not a recruiter) asks me
         | what I do for a living, I say: I'm a computer programmer.
        
         | wintermutestwin wrote:
         | ? I found the label to be highly useful as an adjective
         | descriptor. At the highest level it is a way to distinguish
         | between Intelligence and Wisdom. Wisdom requires experience,
         | but experience doesn't indicate Wisdom. A senior role has to be
         | someone who can mentor junior roles and has fairly well
         | developed soft skills. I can put a senior in front of a
         | customer.
         | 
         | When choosing between two candidates for a senior role:
         | 
         | Candidate A has: Int 16 Wis 10 Candidate B has: Int 14 Wis 12
         | 
         | I would almost always choose Candidate B.
        
           | zabzonk wrote:
           | And you evaluate Int and Wis scores ... how?
        
             | wintermutestwin wrote:
             | It was a D&D reference. I figured any geek would grok it. I
             | was just making the point that intelligence alone does not
             | make a good hire for a senior position.
             | 
             | Of course the specific methods of evaluation are complex,
             | but I would argue that it is easier to evaluate wisdom by
             | asking experiential questions.
        
               | zabzonk wrote:
               | > I figured any geek would grok it.
               | 
               | I did. I simply don't understand how such scores can be
               | evaluated in real life.
        
         | lbriner wrote:
         | That was the point that jumped out to me as well.
         | 
         | If we can all start making progression ladders a normal part of
         | a dev team then we recruit for a rung on the ladder rather than
         | an arbitrary title. Then us Devs will be less precious about
         | "That person said I wasn't a Senior", instead we can try and
         | convince our prospective employer that we can e.g.
         | "Consistently produce high quality code", "Is a thought-leader
         | in new frameworks etc."
         | 
         | It also allows conversations about salary to be more open since
         | we pay a range for a specific level and not a massive range of
         | 20-100K depending on how good somebody interviews or how much
         | gall they have asking for more than they deserve!
         | 
         | see https://www.progression.fyi/
        
         | simplehuman wrote:
         | What should one replace it with?
        
           | zabzonk wrote:
           | You don't need a replacement - you don't need it in the first
           | place.
        
         | DeathArrow wrote:
         | We can replace senior with guru or master. Or ninja.
        
       | DeathArrow wrote:
       | >Firstly, I'm really glad to say that the interviews I did were
       | not the stereotypical tech interviews. As an industry, it's great
       | to see we're getting better, and moving away from whiteboard
       | coding, dealing with super abstract problems like inverting a
       | binary tree, or doing things that we'd generally just use a
       | Search Engine for in our real jobs.
       | 
       | I would expect a junior developer out of college knows data
       | structures and algorithms. That includes knowing what a binary
       | tree is. And if you know what a binary tree is, it isn't terribly
       | difficult to invert it.
       | 
       | Why shouldn't a "senior" developer know what a binary tree is?
       | 
       | While I don't have much regard for leetcode and hackerrank, I
       | wouldn't want to hire someone who doesn't know about algorithms
       | and data structures and thinks he can solve anything with Google.
       | 
       | Sure, many thinks are solvable using Google, but many require
       | knowledge, experience and practice.
       | 
       | >Unfortunately one company - who outsourced the first part of
       | their interview process - had something similar to this, which I
       | wasn't impressed with. There were some arbitrary questions around
       | several topics, and then in the coding exercises you were asked
       | what the O(n) complexity of time/space were.
       | 
       | The author is even outraged he was asked about time complexity,
       | something even junior programmers shouldn't have a with.
        
         | zeroonetwothree wrote:
         | I don't like the "trick" questions where you have to think of
         | some very specific approach or else you fail.
         | 
         | But I agree that basic knowledge of things like trees and
         | runtime complexity is reasonable. That kind of stuff does come
         | up in actual work.
        
         | avereveard wrote:
         | Memorizing stuff that any reference book can tell you is a
         | waste of time and skill.
         | 
         | Knowing when to use a binary tree is much more important.
         | 
         | Knowing _not_ to write a binary tree and using a library is a
         | delivery saving skill.
         | 
         | At least abstract problems off a whiteboard show candidate
         | problem solving approaches. But dry coding koans are absolutely
         | a waste of time for anyone involved and tend to produce teams
         | that care about knowledge tidbits hoarding instead of, idk,
         | serving the business that pays them producing value.
         | 
         | And rest assured, there is no value in writing a binary tree
         | for the business. As a matter of fact if one of my dev doesn't
         | use off the shelf components for these kind of things they'd
         | get a stern talking about time efficiency, security and the
         | likes. Why would I go and stress that at a interview?
        
         | sdevonoes wrote:
         | > Why shouldn't a "senior" developer know what a binary tree
         | is?
         | 
         | Because it's not about binary trees. You could as well ask why
         | a "senior" developer shouldn't know what:
         | 
         | - a TLB is
         | 
         | - a Trie is
         | 
         | - UDP is
         | 
         | - consistent hashing is
         | 
         | - the CAP theorem is about
         | 
         | - NFS is
         | 
         | - BFS is
         | 
         | - and a large etc.
         | 
         | As you can see, a question like "what a binary tree is" could
         | easily be as well "what BFS is about". So, it's not about
         | "senior" developers not knowing their stuff, but that there is
         | so much to know about, that certain developers may know better
         | about certain topics than others. For instance, I don't know by
         | heart the algorithm for inverting a tree; sure, I can give it a
         | try and may come up with a solution... but I'm sure a fresh
         | grad student who has studied in the last semester how to
         | inverted a binary tree, will come up with a solid algorithm
         | faster than I can come up with my weak algorithm.
         | 
         | > I wouldn't want to hire someone who doesn't know about
         | algorithms and data structures and thinks he can solve anything
         | with Google.
         | 
         | Same can be said about not hiring someone who doesn't know the
         | basics of Operating Systems (e.g., TLBs), or the basics of
         | networking (UDP vs TCP), or the basics of distributing systems
         | (e.g., CAP theorem, distributed transactions)...
         | 
         | I'm not saying "There is too much to learn about! Please don't
         | ask me anything!", I'm saying that at a given point in time,
         | any experienced developer can provide a poor algorithm (and so
         | fail the interview) to invert a binary tree.
        
           | abecedarius wrote:
           | What "inverting" a tree means isn't super clear, but the last
           | time this came up on HN it meant reflecting left to right --
           | right? So the question tests if you can write code dealing
           | with recursive data structures at all. To me it's strange to
           | think of this as a niche concern and not something you may do
           | every day.
        
             | charcircuit wrote:
             | Yes, it means that for every node the right child becomes
             | the left child and the left child becomes the right child.
        
           | charcircuit wrote:
           | Even an entry level developer should know those things at
           | least at a surface level since they are taught at university.
           | 
           | Regardless in interviews you are not required to know what a
           | binary tree is. Your interviewer will be able to define it
           | for you.
        
         | laichzeit0 wrote:
         | These specific questions don't help much in my opinion. I
         | prefer asking questions that I know someone can't game through
         | studying some leetcode crap.
         | 
         | - What was the most difficult problem you've had to solve as a
         | developer? They talk about it. You get some data, and you start
         | asking more detailed questions about it for them to elaborate
         | on. Soon you discover if they're bullshitting, or at least
         | what's their "technical ceiling" based on what they considered
         | the most difficult thing they've ever done.
         | 
         | - Have you ever had a performance issue that you've had to
         | debug. How did you go about finding the root cause?
         | 
         | Etc. Basically nothing with a textbook answer. Just get them to
         | talk and not be autistic about it. Surely if you know your
         | craft you'd be able to suss out if this person can solve
         | technical problems and get an idea about how they go about
         | doing it. I really don't care if you can invert a tree or have
         | memorised The Art of Computer Programming...
         | 
         | Will: Wood drastically -- Wood 'drastically underestimates the
         | impact of social distinctions predicated upon wealth,
         | especially inherited wealth.' You got that from Vickers, 'Work
         | in Essex County,' page 98, right? Yeah, I read that too. Were
         | you gonna plagiarize the whole thing for us? Do you have any
         | thoughts of your own on this matter? Or do you...is that your
         | thing? You come into a bar. You read some obscure passage and
         | then pretend...you pawn it off as your own idea just to impress
         | some girls and embarrass my friend? See the sad thing about a
         | guy like you is in 50 years you're gonna start doin' some
         | thinkin' on your own and you're gonna come up with the fact
         | that there are two certainties in life. One: don't do that. And
         | two: You dropped a hundred and fifty grand on a f----n'
         | education you coulda' got for a dollar fifty in late charges at
         | the public library.
        
         | scarface74 wrote:
         | On a day to day basis, most jobs are simply CRUD using a
         | framework. The day to day need to know algorithms is nil.
        
         | karaterobot wrote:
         | > Why shouldn't a "senior" developer know what a binary tree
         | is?
         | 
         | Well, wait a minute. He didn't say it's unreasonable to ask
         | what a binary tree is. He said he was glad he wasn't asked to
         | invert a binary tree on a whiteboard. There's a big difference
         | between those things. I think your reading is uncharitable.
        
       | bambataa wrote:
       | Interesting that the OP liked Monzo so much. I have heard
       | consistently bad things about their tech culture.
        
         | claytonjy wrote:
         | Yup, I only know about them from this site, where they seem to
         | be held up as an example of taking a microservice architecture
         | too far.
        
       | sdevonoes wrote:
       | > Another thing to note is that I ended up not really preparing
       | for the interviews. I feel like this is a bit of an arrogant move
       | by me
       | 
       | Well written article. The only part I don't agree with is this
       | though. If I am applying to a company, I do research what the
       | company (and its product) is about. But that's it. I want to know
       | if in my current "shape" and with my current knowledge, I would
       | be a good fit for them.
       | 
       | For me, preparing for days or weeks for a tech interview feels
       | like cheating: "Recruiter: design a distributed key-value store.
       | Me thinking: yes! I read how to do that in How to Crack the
       | Coding interview! I'm gonna nail it!... Recruiter after seeing my
       | solution: Wow, let's hire this guy!"
        
         | Deltitt wrote:
         | Yes and everyone is doing it and everyone who is doi.g it is
         | earning 10k more or perhaps even 50k and more just because they
         | do that.
         | 
         | They are not better at the job than you are (at least this
         | alone is not an indication) but they still get hired over the
         | other group of people.
         | 
         | So I do prepare for my interviews. I'm increasing my chances.
         | 
         | And btw I learn things when preparing for an interview so while
         | I don't like it, I still learn.
        
           | sdevonoes wrote:
           | That's very well. I didn't pretend to say I am doing it
           | right, and others not.
           | 
           | > And btw I learn things when preparing for an interview so
           | while I don't like it, I still learn.
           | 
           | Well, I'm constantly learning whether or not I'm looking for
           | a job.
        
             | Deltitt wrote:
             | Yes same as me.
             | 
             | But when they want to see I can write a handful of
             | algorithms blind, I'm learning as well just something else
             | than usual.
        
         | bradlys wrote:
         | This is the modern interview practice though. Realistically -
         | you're not gonna pass at most of the companies here in SV when
         | you're getting leetcode hards on the regular like I am. Without
         | a lot of practice, you're gonna fail spectacularly.
        
       ___________________________________________________________________
       (page generated 2022-05-08 23:01 UTC)