[HN Gopher] The rise of never-ending job interviews
       ___________________________________________________________________
        
       The rise of never-ending job interviews
        
       Author : hhs
       Score  : 873 points
       Date   : 2021-08-02 00:53 UTC (22 hours ago)
        
 (HTM) web link (www.bbc.com)
 (TXT) w3m dump (www.bbc.com)
        
       | DrBazza wrote:
       | I would have thought in 2021 companies would say "if it's a 'not
       | sure', then it's a no", but I've worked at some places recently
       | where "not sure" would get additional interviews. That's one
       | problem.
       | 
       | Another problem is in certain companies, senior management don't
       | trust their own staff and want to be involved in the recruitment
       | process.
       | 
       | Yet another problem is poor CV vetting. You really can tell a lot
       | about a candidate just from the CV. Even if (in the UK) an agency
       | has mangled the CV into its own 'template' for companies.
       | 
       | Demonstrating knowledge of algorithms is fine. Having to
       | implement a red-black tree in an interview, or some arcane
       | template corner of C++'s standard library from scratch, is _not_
       | a good use of anyone 's time.
       | 
       | If companies don't keep consistent interview processes, if they
       | have two 'yes' candidates for one role, they can't fairly compare
       | them and choose.
       | 
       | My worst/most lengthy interview was for a certain bank, that
       | famously expects employees to work 12-14 hr days, and weekends.
       | Total interview time: 24 hours. The result boiled down to the
       | MD/partner interviewing me _last_ , and having the yes/no
       | decision.
        
       | dzhiurgis wrote:
       | Aaah the impossible captcha of hiring! Amazing. Some companies
       | could use this to drive some nutters ever crazier.
        
       | rfwhyte wrote:
       | Think of it this way. Company A is hiring for role X. They get
       | 100 candidates, interview 10, with each candidate going through a
       | 5 interviews at an average of an hour each, assuming they hire 1
       | candidate, that's 45 hours of people's lives that have now been
       | utterly wasted.
       | 
       | The problem is companies don't care about you and your time until
       | you are their employee. They'll gladly waste hours and hours and
       | hours of your time, because doing so costs them nothing.
       | 
       | There's actually a super simple solution to this problem.
       | 
       | Require interviews be paid. Doesn't have to be a lot, a simple
       | honorarium scaled to the role's salary would suffice.
       | 
       | If your time has a cost to companies, they'll stop wasting it and
       | start optimizing to minimize the time hiring takes instead of
       | optimizing for other factors and ignoring the negative
       | externality of wasting peoples time.
        
       | voidfunc wrote:
       | People are getting less and less willing to deal with bullshit
       | when they're in massive demand and there is a talent shortage in
       | $x industry. And they're finding out they can move around easily
       | now too in this remote-first world.
       | 
       | Something is going to have to change - really a lot of things.
       | One of them is going to be that companies need to learn to figure
       | out how to hire people without putting them through a grind-fest.
       | Figure out how to deal with bad hires after-the-fact, but don't
       | let yourself get screwed not hiring good talent because you made
       | the interview process a giant pain in the ass to catch the crap.
       | 
       | Oh and compensation needs to go up to make some of these
       | interview grinds worth it.
        
         | onlyrealcuzzo wrote:
         | Nothing's going to change at FAANG until average, non-FAANG
         | companies can compete on TC (never). I doubt things will change
         | outside of FAANG - because most companies are merely emulating
         | the FAANGs and hoping they emulate the success.
        
           | vmception wrote:
           | > until average, non-FAANG companies can compete on TC
           | (never).
           | 
           | And that's the rub. Not only do they struggle to value my
           | skillset, they also can't compensate it accurately. And
           | sadly, FAANGs don't even have the roles in a lot of niches.
           | 
           | When you can make 3x what a FAANG would offer, annually, but
           | the companies building in your same niche are too immature
           | and pay 1/3rd of what FAANGs do, its tricky to want to
           | tolerate any of it!
        
             | CobrastanJorji wrote:
             | I'm not sure I follow. If FAANG companies would offer you
             | 1x, and non-FAANG companies in your area of specialty would
             | offer you x/3, who's paying 3x?
        
               | vmception wrote:
               | Solo. Right now I can make 3x FAANG comp on a new idea
               | annually without reaching out to my network or needing
               | outside capital.
               | 
               | Given how many ways there are to do that and much more, I
               | would like the structure of someone else's idea to focus
               | (aka being an employee). Doing things solo has overhead
               | costs and liability risks, whereas employment has almost
               | none but half to 3/4ths of your compensation is withheld
               | the whole time. So there is a limit to what comp I'll
               | accept, given the opportunity costs. Would be great if
               | that comp was FAANG level.
        
               | [deleted]
        
               | onlyrealcuzzo wrote:
               | You know that it's pretty easy for senior engineers take
               | make >$500k at FAANG atm, right?
               | 
               | Can you share some things in the past that were easy
               | money that netted you $1.5M in a year? I'm genuinely
               | curious.
               | 
               | I used to have a ton of ideas that I thought if I did
               | everything right I could've maybe made $300-600k. But
               | then you can just get that as a paycheck at FAANG.
               | 
               | None of my ideas ever were easy and could realistically
               | generate more than that. Plus there was always a risk
               | they would generate $0.
        
               | vmception wrote:
               | Yes, I am talking about $500k annual vs making at least
               | $1.5 million in a couple of months and doing something
               | else
               | 
               | Hm, worst case, people on HN debate an irrelevant
               | understanding of what I say is possible
               | 
               | Best case, they copy it en masse and dilute the
               | opportunities faster
               | 
               | No thanks
               | 
               | I would take $500k doing the same stuff for a tech
               | employer but nobody is offering that right now. Some
               | contracting firms do, kind of, don't really want hourly
               | though and also want the benefits. I want to focus on
               | someone else's visions, get paid on days off, no risk.
               | Also want a ton of equity I wouldn't go and purchase
               | myself. Or private equity that I wouldn't have the
               | opportunity of purchasing in addition to an attractive
               | cash compensation. (These are all things I could do in
               | just frontend/fullstack work.)
               | 
               | Some smaller companies are going above the 125-150k
               | range, to double that. But not quite and they're still
               | few and far between.
        
               | rantwasp wrote:
               | ideas are cheap. execution matters.
        
               | vmception wrote:
               | which obviously applies more to the person asking about
               | what I've done because their ideas and execution made
               | them nothing. good luck ya'll.
               | 
               | this is a thread about the conundrum of leveraging this
               | experience without losing freedom or opportunity costs,
               | not about being miffed that someone won't share how to
               | make money, its like you all _want_ to be scammed into
               | purchasing an some youtuber 's outdated amazon
               | dropshipping masterclass.
        
         | marto1 wrote:
         | Consider we've had a labor shortage since BEFORE the pandemic.
         | The gotcha here is companies have a shortage of people they can
         | lowball into a sweatshop "startup" environment.
         | 
         | Nothing changed regarding that one as far as I can see so
         | interview processes getting longer isn't all that surprising.
         | After all that's one surefire way to optimize for getting
         | desperate people.
        
       | wly_cdgr wrote:
       | IMO, for new grads and career changers in particular, it would
       | make good sense for Google and other companies that have to
       | interview vast quantities of candidates to develop and publish
       | some rigorous MOOC sequences that candidates can complete on
       | their own schedule to develop and demonstrate relevant
       | competencies in a way the companies can trust more than they
       | trust 3rd party degrees. Candidates who complete the MOOC
       | sequences successfully could be fast-tracked into an expedited
       | interview process. Plus they get a marketable, public credential
       | out of it, rather than just going through a super long interview
       | process with nothing to show the world / other companies for it
       | 
       | Google is already kinda doing this with Grow With Google, so I am
       | just thinking of an even more extensive and rigorous version of
       | this
       | 
       | And/or just ask people about their best Factorio factories and
       | EXAPUNKS solutions :)
        
       | neilwilson wrote:
       | Once you realise that they are trying to leverage the 'sunk cost
       | fallacy' to try and get cheaper staff, you tend to bin these
       | earlier.
       | 
       | This is nothing to do with removing risk from hiring processes.
       | It's to filter for those who want to be in the fraternity so much
       | they will do anything to get there - including being chronically
       | underpaid and badly treated.
       | 
       | There is still a shortage of good people. Let these companies
       | have the less good people.
       | 
       | Good employers know talent is in short supply.
        
       | kebman wrote:
       | Preferably one. Perhaps two if there are unanswered questions.
       | You're really, really pushing it at three, however. Unless I'm
       | compensated for the time I'm about to waste, I might not bother
       | meeting up to a third interview.
        
       | LAC-Tech wrote:
       | A big part of what prompted me to become a contractor. When I
       | last did this, everything was at least 3 interviews, + sometimes
       | even the recruiters wanted to meet with you first.
       | 
       | Finding your own clients doesn't start looking as bad, and a
       | discussion to see if you'll work together is much better than an
       | interview.
        
         | bississippi wrote:
         | Are you a contractor or consultant? Because SW contractors are
         | just quasi FTEs without health insurance and no termination
         | notice periods
        
       | niklasrde wrote:
       | I've done two long ones - McKinsey Digital (~7 interviews over 3
       | months) and Bloomberg (~5 interviews over 1 month).
       | 
       | Whilst it was dragging, I do feel they were both adequate
       | processes for me to learn about the companies and the role, and
       | for them to get to know me and my fit for the team. I ended up
       | learning quite a lot about myself, too, and got useful feedback
       | out of the process.
       | 
       | It also was during the pandemic where organisations where finding
       | their feet with remote hiring; I reckon in a pre-pandemic
       | session, they would've been compressed into sessions together.
       | 
       | The scheduling, and comms about it weren't always amazing, but
       | that's down to the recruiters rather than the hiring team, imho.
        
       | Amin699 wrote:
       | Trial and error is bad and costly for companies who are hiring,
       | so they often compensate by making the recruitment process more
       | and more forensic. This means conducting multiple interviews to
       | gather valuable information to help them more clearly determine
       | which candidate has the most potential. In the best-case
       | scenario, this is a great investment for all involved: it ensures
       | that the candidate won't struggle in the job, and that the
       | company won't have to repeat the process all over again.
        
       | pts_ wrote:
       | Interviewees should demand payment by the hour at their going
       | rate.
        
       | bississippi wrote:
       | > That's a question Mike Conley, 49, grappled with earlier this
       | year. The software engineer, based in Indiana, US, had been
       | seeking a new role after losing his job during the pandemic
       | 
       | This is ageism. I hope he realized this after 10 6 rounds of
       | interviews.
       | 
       | https://news.ycombinator.com/item?id=19507732
        
         | theyellowkid wrote:
         | It seems to me that ageism actually has some value.
         | 
         | People never got any smarter, but the nature and details of
         | group activity have changed over time.
         | 
         | After a career of delivering products for boutique
         | manufacturing companies, I'd say that my ability to pass a
         | modern interview suite is essentially nil. My last gig for a
         | company with modern practices taught me that it's no fun in any
         | case as design devolves into manufacturing (perhaps for good
         | reason).
         | 
         | Give me a young body, and I'd look into purposefully arcane
         | careers with little remuneration. Blacksmithing perhaps.
        
         | neilv wrote:
         | Ageism absolutely is a problem in our field (I've seen/heard
         | many people even openly boast of ageist hiring practices), but
         | I don't know that ageism was the reason in that quoted case.
        
         | vmception wrote:
         | Not to invalidate ageism, there are many threads about younger
         | people's interviewing experience that match this. The
         | competition (other candidates) are doing _much_ more than that,
         | and also studying and practicing leetcode much longer than I am
         | willing to.
        
           | ChrisMarshallNY wrote:
           | Well, one way that this works, is that older folks, that have
           | gotten used to working in an environment of mutual respect,
           | and have some modicum of self-respect, are less likely to put
           | up with BS, as opposed to someone younger, who may have come
           | from a ... less _professional_ climate.
           | 
           | The idea is to drive out older, less-pliant potential
           | employees, in favor of newer ones, who can be molded into a
           | shape the corporation prefers.
           | 
           | Have you ever seen a couple that has gotten married later in
           | life? Many times, it may be a second (or more) time for one
           | or both of them.
           | 
           | They need to make _massive_ compromises. Both have gotten
           | used to supporting themselves, and keeping their own counsel.
           | They generally both have a lot of property, maybe grown kids,
           | careers, etc. Usually, they don 't actually _need_ each
           | other, for more than emotional support. They each do fine, on
           | their own. It 's a relationship of equals.
           | 
           | It can be a challenge to make it work, but when it does, it's
           | _amazing_. I have known many couples like that.
           | 
           | I understand why corporations don't want to put effort into
           | working with older folks, but it can be well worth it.
           | 
           | So many times, when I see these awful, Jurassic-scale
           | disasters, made by companies that are staffed exclusively by
           | younger folks, I say to myself "That was a really great idea,
           | but they completely pooched the release. Why didn't anybody
           | raise any red flags?"
           | 
           | The answer is generally, that no one on staff had enough
           | experience to understand the ramifications of many decisions,
           | and often, they were afraid to countermand ideas put forth by
           | their superiors.
           | 
           | Couple that with 20-something CEOs, who are often fearfully
           | insecure, and you have a recipe for disaster.
        
           | kxrm wrote:
           | Perhaps, but I can say that I am over 40 and I can tell when
           | the enthusiasm for my candidacy dies after they see my face
           | that it's not due to anything but ageism.
        
             | vmception wrote:
             | and I'm in an underrepresented group, we all have the
             | ability to conform our experiences to the reason that
             | matches what other people say will limit our opportunities.
             | It is equally important to weigh each experience against
             | the similar experiences. I've seen plenty of linkedin posts
             | and blogs about people bragging about their quests to get
             | competing offers in tech, some interviewed at 60 companies
             | and did 100 interviews, when my tolerance is 12 companies
             | and maybe 15 interviews. Some did 700 hours of leetcode,
             | where my tolerance is maybe 5 hours. The dataisbeautiful
             | and some employment subreddits have flow charts that show
             | similar quests to get an offer, visualizing how much
             | rejection and time is used inefficiently.
             | 
             | Like I said, not to invalidate anything, these experiences
             | are so common amongst the whole pool that it has to be
             | weighed accordingly.
        
               | atomlib wrote:
               | What's stopping you from claiming you spent 700 hours on
               | Leetcode?
               | 
               | (Not everything people say online is true.)
        
               | vmception wrote:
               | Ok. Not the point.
               | 
               | It wouldnt take me 700 hours to get familiar with all the
               | abstract problems and concepts I'll encounter, but it
               | would take me a very long time to, and longer to
               | synthesize solutions that are above average, and
               | regurgitating that on the spot for an interview in a
               | quicker time than other candidates.
        
       | cowanon22 wrote:
       | I'm fine with having 6-8 interview - every
        
       | graderjs wrote:
       | I've had this experience too. Including with a 10-person YC
       | backed company. I'm glad it's not just software engineers
       | experiencing this. I suppose hiring is broken everywhere...
        
       | spoonjim wrote:
       | I think the third party screening companies will eventually win
       | here. There will be an objective measure of skill at the job,
       | plus some culture/fit interviews.
        
         | zug_zug wrote:
         | It does seem like the obvious efficient solution
         | hypothetically. Right now we have proxies "Well he worked at
         | FAANG so he's probably good enough for us" on the company side
         | and glass-door (horribly subjective) on the individual side.
         | But really no way for extremely-qualified individuals to say
         | "show me all job offers within X miles that pay more than $y
         | for position $z" (closest thing I'm aware of is indeed).
         | 
         | That said, for whatever reason the startups that tried to be
         | intermediaries (and also various recruiters) tend not do very
         | well in my experience.
        
       | eh9 wrote:
       | I get so jealous of my mechanical/structural engineering friends
       | who's interviews usually span one or two rounds, and they're
       | never asked for anything resembling spec work.
       | 
       | Hiring should never take more than a day or two of interviews.
        
       | cowanon22 wrote:
       | Every quality job I've had consisted of 6-8 different interviews.
       | However, all of those jobs also send me a schedule and list of
       | job titles of who I will be interviewing with, and conducted all
       | of them on the same day. At this point I consider it a big red
       | flag if a company excessively spreads them out.
        
       | Ithildin wrote:
       | This trend is absolutely ridiculous. I'm currently in "Round 3"
       | and have FIVE interviews this week, four of which are technical.
       | I already passed the technical in Round 2.
       | 
       | As someone with 10+ years experience in the industry, I've about
       | had it with these technicals. I'm just going to start refusing.
       | I'm happy to have a long technical discussion on my work
       | experience and to provide you with portfolio examples. Take your
       | hacker rank problems and get out of here.
        
       | theshadowknows wrote:
       | I work at Big Ass Corporation, Inc. in the US (there's a very
       | strong chance you use one or more of our services). Hiring is
       | fucking awful. First of all it's nearly impossible to get
       | approval for a req in the first place. I'm actively looking to
       | leave just because of that...but that's a different rant than
       | this one.
       | 
       | Once a req is approved then it goes out to the team to disperse
       | as well as hr. Some roles get handed off to the critical search
       | team if the hiring manager pushes hard enough. But that doesn't
       | really matter.
       | 
       | We get flooded with candidates. Almost every one of them could
       | probably do the job so we have to figure out who could do it best
       | through the interview process. I personally never ask stupid
       | gotcha puzzle questions because those annoy me as much as they do
       | most folks here. I ask people to talk about their experience as
       | it relates to the role. Usually this means I ask about how they
       | solved a truly difficult problem at work, what made it difficult
       | and how they were able to overcome it. Then I like to get into
       | the technical stuff of what they implemented and why. Mostly I
       | just like letting people who are proud of something they've done
       | get a chance to talk about it.
       | 
       | Anyway we're supposed to score people based on these arbitrary
       | metrics like longevity (how long we think they will stay) and
       | communication ability (this is very, very close to being
       | racist...draw your own conclusions).
       | 
       | I never score people. Managers ask me why and I say because I
       | don't interview spreadsheets.
       | 
       | Anyway I'm one of usually 4 interviews. I interview by myself and
       | the rest are all panel interviews. And once you finish the last
       | panel that's the last you hear from us unless you get an offer. I
       | hate it.
        
         | FinanceAnon wrote:
         | It sounds like you do what you can. Unfortunately, people like
         | you leave as they can't put up with it any longer and the
         | company is just left with people who are happy with the status
         | quo.
        
         | autarch wrote:
         | > communication ability (this is very, very close to being
         | racist...draw your own conclusions)
         | 
         | I'm trying to draw my own conclusion but I'm confused.
         | Communication ability is very important for developers and
         | other technical roles. We need to be able to talk to each other
         | about our work, and in many organizations we also need to be
         | able to work effectively with other non-technical staff.
         | 
         | Of course, this doesn't mean that you have to speak or write
         | the company's primary language in some particular way, as long
         | as you can make yourself understood. Nor does it require that
         | you speak that language as your first language.
         | 
         | Is there something specific about _how_ Big Ass Corporation is
         | evaluating communication ability that is racist?
        
           | sandyarmstrong wrote:
           | The way I read it is that "communication ability" is
           | something people can use to justify racist hiring decisions.
           | For example, labeling non-white speaking patterns as
           | "unprofessional", or non-American accents as "poor
           | communication skills".
           | 
           | When in fact, these candidates _may_ have excellent
           | communication skills, and in a blind interview situation the
           | same interviewer might praise their writing abilities.
           | 
           | But you don't really know, because the interviewer is rating
           | communication skills in a scenario that can easily bring out
           | a lot of hidden biases.
        
             | autarch wrote:
             | This makes sense.
             | 
             | I think it's really important to spell out what
             | "communication ability" means so that all the interviewers
             | know what they're looking for. And more generally, it's
             | very important that before you start the hiring process,
             | you have a clearly defined set of criteria that everyone
             | participating in the hiring process agrees on.
        
       | hardwaregeek wrote:
       | If your application process starts with a human being--even
       | better a technical human being--reaching out to me, followed by
       | 2-3 interviews, followed by an offer, I am already on your side.
       | If your application process starts with a HackerRank, followed by
       | 2 phone interviews followed by on-site, followed by team
       | matching, I will not be on your side. Oh and if there's random
       | month long gaps in between stages, I will especially be
       | uninterested.
       | 
       | I've noticed though that as I've gotten more specialized to
       | compilers and programming languages, my application experience
       | has improved significantly. It's not a large sample size but the
       | last few processes I've gone through have been fewer interviews
       | that usually involve going over a project of mine or doing a
       | problem that's related to compilers. It's really refreshing to
       | have an interview where I actually learn something about my field
       | of interest during it. I know that doesn't scale because we
       | shouldn't expect compilers knowledge for junior compilers jobs
       | but it's a very nice change of pace for me.
        
         | Aeolun wrote:
         | I don't think there is such a thing as a junior compiler job?
        
           | trhway wrote:
           | compilers are 101 of CS with coding a major part of compiler
           | being just a course project. Honestly, one of the most
           | straightforward and simple things in the industry. At one of
           | my previous jobs several senior undergrads (beside fresh
           | grads which were frequently hired) were hired full-time to
           | work on a major compiler suite. A nearby company doing a
           | lesser known kind of bit more narrow specialized compiler
           | suite were hiring even more of senior undergrads and fresh
           | grads.
        
           | hardwaregeek wrote:
           | Considering I've worked on a compiler as an intern and know
           | plenty of people who have done the same, I politely disagree
           | :D
        
         | purplecats wrote:
         | the quality of your experience will depend on the desperation
         | of the candidate employer.
         | 
         | more competition = worse time for you
        
         | onion2k wrote:
         | I applied to a company recently whose first interview was a
         | tech test. I turned them down before I even spoke to a human. I
         | don't want to work for any company that puts so little value on
         | people.
        
           | that_guy_iain wrote:
           | Honestly, I understand the whole send the tech test first.
           | Having wasted time on talking to people who clearly weren't
           | able to do the job I would rather waste their time than
           | mines. For me, it's when I talk to their developers and it's
           | clear they know I know what I'm talking about and they then
           | try to tech test me. At that point, no. I just impressed the
           | hell out of some of the people you consider to be your best
           | and you think I can't code? Nah.
           | 
           | The tech test seems often like it's cargo cult. It's on
           | Joel's list so everyone thinks it is a must do. Instead of
           | realising that the entire point of the tech test was to make
           | sure people could actually code. With some of the original
           | tech tests being do FizzBuzz or do something really simple in
           | a short amount of time. Not, build me a production ready toy
           | project using techincal DDD aspects.
        
             | onion2k wrote:
             | _Having wasted time on talking to people who clearly weren
             | 't able to do the job I would rather waste their time than
             | mines._
             | 
             | Of course. But consider how that attitude looks from the
             | perspective of a candidate - you'd rather waste my time
             | that yours is a really good reason for me to drop out of
             | the interview process.
             | 
             | This is essentially what's wrong with hiring right now.
             | Companies don't want to have anyone "waste their time", so
             | they have many levels of filtering to reject candidates as
             | early as possible while doing as little work as possible to
             | make hiring good for candidates. In other words, companies
             | have largely forgotten that candidates are people, and
             | wasting _anyone 's_ time is a pretty bad idea.
        
               | that_guy_iain wrote:
               | Well, being the candidate I would rather they did a tech
               | test first than talk to me and then do a tech test.
               | Actually, if someone technical has spoken to me and then
               | they ask me to do a tech test. I'm very likely to say no
               | because they've already got a feel for my abilities and
               | that is the point of a tech test.
               | 
               | I think sometimes people forget people working at these
               | companies are people too and noone wants to have their
               | time wasted. This isn't companies deciding these things.
               | It's people. It's the person on the otherside that
               | doesn't want their time wasted.
        
               | onion2k wrote:
               | To be honest, I think I'd agree with you if job adverts
               | included all the information necessary. Doing a tech test
               | for a job when you don't even know the salary range, or
               | what the role consists of, or what the company really
               | even does ... that's what annoys me. If companies wrote
               | transparent, clear job adverts I'd be a lot happier with
               | their interview processes.
        
         | andrew_ wrote:
         | Agree totally. I recently accepted a position where an officer
         | reached out to me, followed by a really great discussion with
         | them. A call with two engineers and a team call later, I was
         | offered, and we were all confident it was a great fit. The
         | interested was consistently maintained on all sides evenly and
         | communication was fluid. Great experience.
        
         | Dig1t wrote:
         | I agree actually, I've had a similar experience except in the
         | mobile engineering space.
         | 
         | Currently I'm going through the interview process with a ton of
         | companies (because my company is really dumb and is forcing
         | everyone to move back to a certain bay area city post-covid),
         | and I have been happily surprised to find that most of my
         | interviews are very practical, project based, ones instead of
         | straight whiteboarding leetcode problems. I've received several
         | take-home projects that are followed up with a simple add-on
         | interview to sit down and explain the choices made during the
         | take-home. They have all been specifically focused on domain
         | knowledge to the mobile platform that I'm interviewing for. Its
         | really nice! I hope this trend continues.
         | 
         | That said, I am still reviewing leetcode problems for the
         | stupid faang interviews I have coming up as well.
        
           | MattGaiser wrote:
           | Where do you find take home project interviews?
        
             | kxrm wrote:
             | I just went through this with a company. They sent me a
             | generic packet with 3 projects to choose from. With a
             | simple Google search I was able to find all of the answers
             | to all 3 sample projects implemented in different
             | languages.
             | 
             | This was after a 10 minute conversation with the company's
             | recruiter. To top it off, nothing in the job listing said
             | anything about software. Just Cloud and Devops management
             | role.
             | 
             | I am absolutely ok with take home or some presentation of
             | my skills. However, I expect to know that I am being taken
             | seriously as a candidate by that point. I don't want to
             | waste my time on something with no investment from the
             | company.
             | 
             | As you can guess, I bowed out of the running explaining
             | that I didn't think it was appropriate for me to give them
             | so much of my time with no commitment from their end. I
             | also told them I could tell their take home project took
             | them less than 5 minutes to generate for me as it was
             | everywhere on the internet. How can I trust a process where
             | the answers to the interview are everywhere? How can they
             | really know my skills as a candidate if I can just steal
             | the answers off of GitHub? Worse, how can I know how I will
             | stack up to someone who might be less scrupulous than I and
             | steal those answers when I tried in earnest and actually
             | burned an afternoon trying to solve their test?
        
         | virgilp wrote:
         | Is HackerRank so bad? If one does "whiteboard problems",
         | HackerRank says, "boo, whiteboard interviews, just let me code
         | and be able to search on Google, whiteboard is unrealistic!".
         | Now if the company starts with a HackerRank test, that's also
         | bad? I don't get it.
         | 
         | Look, a lot of people have good-looking CVs and can't code
         | shit. I don't know about you but my experience was that one
         | really can't hire based on CV alone. Also, I've seen
         | "architects" that are smart and fairly knowledgeable people
         | that failed to code very very basic stuff (as in, merge 2
         | sorted arrays).... I get it that at some companies you are
         | expected to draw diagrams in Confluence as a main job, and
         | might no longer have actual coding skills; but we want even the
         | most senior people to actually code, and that doesn't seem
         | unreasonable to me. So just because you're a very-senior FAANG
         | employee doesn't automatically mean you'd be a good fit. I'm
         | not saying they're bad employees, but maybe they just wouldn't
         | be a good fit and wouldn't enjoy the job if they expect to just
         | design stuff instead of actually implementing, too.
        
           | arp242 wrote:
           | The main problem with some of these things is that:
           | 
           | 1) you're expected to spend 3 or 4 hours on some HackerRank
           | test before you've even spoken to anyone. Some of these tests
           | (outside HackerRank) can actually be projects that take a day
           | or more to get right. The issue is that at this point I don't
           | know if the attitude is "hey, this seems like it might be a
           | good hire, let's check if he can actually code" or if it's
           | "let's send anyone this test and discard anyone who doesn't
           | pass". I suspect that in a lot of cases it's the latter. I'm
           | not opposed to investing time, but it quickly becomes
           | unmanageable if everyone just asks you to pass their several-
           | hour tests just to be considered for application. There is
           | very little time investment from the company, and it feels
           | almost like a dDoS attack on my time.
           | 
           | and 2), that a lot of these tests are asking you to solve
           | some hard problem that you will rarely face in real life and
           | where people have quite literally won Turing awards for
           | finding solutions to them. Many previous discussions about
           | this on HN in the past.
           | 
           | I don't think it's even all that much more effective at
           | actually weeding out bad programmers than a simple test. We
           | used to ask people to write a CSV address book importer with
           | some very basic requirements; nothing fancy, you could do it
           | in 30 minutes. It worked well enough, and a lot of the
           | results we got back were horrible.
        
           | wildrhythms wrote:
           | There is so much more information gained about a candidate by
           | an engineer interviewing another engineer than by a "pass" or
           | "fail" score from a robot.
        
             | drclau wrote:
             | You assume the interviewer is ideal: infinitely competent,
             | infinitely great at judging other engineers' skills etc.
             | This is practically never the case.
             | 
             | I am not one for LC type of problems, but at the least I
             | have to admit they have the potential of being more
             | objective than everything else during the interview
             | process. You get the specs, you write the code and it gets
             | tested via multiple test cases. It does not matter if the
             | interviewer agrees your solution will work or not, and the
             | interviewer won't have to copy&paste your code, compile and
             | run it (like someone else mentioned in this thread).
             | 
             | On the other hand, what I particularly dislike about the LC
             | problems is that many of them are essentially trick
             | questions and brain teasers. Can't we just stick to
             | problems that are relevant to an SWE?
        
           | MattGaiser wrote:
           | A lot of the issue with HackerRank is just how early it is in
           | the process. I don't object to it. But there companies out
           | there that just have every applicant do it indiscriminately.
        
           | someelephant wrote:
           | HaackerRank is now 3 hard problems in 1.5 hours. That's not
           | testing anything other than a thousand hours memorizing
           | leetcode.
        
           | brailsafe wrote:
           | HackerRank isn't inherently bad. It's actually pretty good.
           | It's that receiving a 1-2 hour automated algo contest to
           | every job application is bad.
           | 
           | If I applied to 10 companies, and every single one of them
           | asked me to come onsite for whiteboarding as the first step,
           | that would also suck tremendously, but at least it would be
           | limited in scope by the employer's time as well. As it
           | stands, arbitrary companies can expect a large time
           | investment without any of their staff ever having to speak to
           | anyone.
           | 
           | I'll take a calculated stab at Amazon's once every 6 months I
           | guess, because if I pass (which I haven't) I can potentially
           | earn a hell of a lot more than any other place. I get it,
           | whatever. If every company is doing it (they are)? I might
           | just leave the industry if I can't find a way to be
           | specifically good at remembering the implementation details
           | of every data structure and algorithm. Sucks to be someone
           | with pointless skills I guess.
        
           | itronitron wrote:
           | If there are teams interviewing candidates that are surprised
           | to find that some applicants can't write basic code, then
           | there must also be candidates that are surprised by that as
           | well.
           | 
           | The longer a candidate has worked on very capable teams the
           | more surprised they will be to have those problems presented
           | in a job interview.
        
           | hardwaregeek wrote:
           | I agree it's subjective. Some people may prefer HackerRanks
           | because it lets them do the work on their own time without
           | someone watching them. For me, HackerRank problems almost
           | always have nothing to do with my work, require passing an
           | arbitrary test suite, and provide the interviewer with no
           | insight into my problem solving ability. Who would you rather
           | hire, someone who reasoned through the solution on their own,
           | then dropped a hidden test case, or someone who saw this
           | question before and just rote wrote it from memory? Perhaps
           | both, but HackerRank won't give the former a chance.
           | 
           | Besides, if someone is duplicitous enough to have a good
           | looking CV and no coding ability, what's stopping them from
           | just cheating on the HackerRank?
        
             | virgilp wrote:
             | > almost always have nothing to do with my work
             | 
             | TBH that's another argument I don't really get. Almost
             | everyone agrees that basic CS knowledge trumps specific
             | technology knowledge (I'd rather hire someone with strong
             | CS fundamentals that didn't use Java before than someone
             | who is a "Spring Boot expert" but lacks basic CS knowledge,
             | even if I actually use Spring Boot right now).
             | 
             | But then, why complain that you don't do that in your work?
             | Surely you need to traverse data structures from time to
             | time, yeah it won't be the exotic tree traversal that I'd
             | ask you to write but that's exactly the point - to test
             | that you can be put in a novel situation that can't be
             | directly-pasted from StackOverflow and you're able to write
             | a recursive function that takes _a little bit_ of skill).
             | 
             | The hidden test case is opportunity for discussion during
             | actual interview. And this answers your "what's stopping
             | them" question, too - regardless of problem, I can tweak
             | the input slightly so that your solution doesn't work - and
             | more often than not, I don't even tweak the input, I just
             | provide an additional testcase where your solution doesn't
             | work. If you can quickly fix it ("oh, yeah, I forgot that
             | URLs may have a fragment appended to it, let me quickly
             | adjust my log-parsing condition") then it's awesome, it's
             | exactly the signal I'm looking for, and we can go on to
             | discuss system design and your relevant experience (but
             | honestly, at that point my mind is likely ~80% made up,
             | from CV + how you explain/modify your hackerrank solution).
        
       | mitsuchen wrote:
       | For everyone saying that it's risk mitigation, I recently asked
       | about something similar[0] for a junior position, and the process
       | still hasn't finished. For context, the company is a medium-size
       | tech company with presence mostly in Europe and Asia.
       | 
       | I don't know these things well enough but it makes no sense to
       | me. For starters, in the tech sector in my country the salary for
       | fresh grads like me actually come mostly from the government.
       | Moreover, these companies are all secretive about compensation,
       | and they probably think they can get away with it by dangling
       | their "reputation" in front of you like a carrot. In most cases
       | the salary is about the same as a small startup because, again,
       | they get the money from the government.
       | 
       | People can argue about spending time and resources on training
       | and what not but basically every job ad, from "top" companies to
       | the web dev garage down the road, expects us to learn by
       | ourselves anyway?
       | 
       | It's frustrating for early career starters that most of my
       | friends and I are going through. It's such a huge waste of
       | everyone's time and people are just churning because of this
       | crap. Please get rid of non-technical HR and interviewers.
       | 
       | Sorry for the emotional rant. I would really like to know what
       | risks (other than useless non-technical HR keeping their jobs)
       | there are after candidates have past a certain threshold for
       | quality, particularly for junior positions.
       | 
       | [0] https://news.ycombinator.com/item?id=27881668
        
         | yarky wrote:
         | > I would really like to know what risks (other than useless
         | non-technical HR keeping their jobs) there are after candidates
         | have past a certain threshold for quality, particularly for
         | junior positions.
         | 
         | It's harder to deal with emotional kids than it is to deal with
         | incompetent engineers. Maybe that's why those non-technical HRs
         | might not be as useless as you think.
        
           | mitsuchen wrote:
           | You made the mistake to assume that we are idiotic enough to
           | be emotional for job interviews.
           | 
           | It's harder to deal with people who think they are competent
           | and know it all than emotional kids.
        
             | yarky wrote:
             | > You made the mistake to assume that we are idiotic enough
             | to be emotional for job interviews.
             | 
             | And that's a risk that could potentially be spotted by a
             | competent HR.
             | 
             | > It's harder to deal with people who think they are
             | competent and know it all than emotional kids.
             | 
             | Maybe, but juniors are (unfortunately) seen as a commodity
             | by the market. Commodities are about uniformity and
             | adherence to some standard, rather than uniqueness.
        
               | mitsuchen wrote:
               | > And that's a risk that could potentially be spotted by
               | a competent HR.
               | 
               | It's a risk that could only be spotted be HR, don't know
               | about the "competent" part. There would be no emotional-
               | kid risks to speak of if it weren't for useless HR.
               | 
               | > Maybe, but juniors are (unfortunately) seen as a
               | commodity by the market. Commodities are about uniformity
               | and adherence to some standard, rather than uniqueness.
               | 
               | It's making even less sense now. If we are commodities
               | and it's all about uniformity and standard, why do we see
               | senior engineers complaining about this, too? It also
               | makes no economic sense to spend so much time and effort
               | on elaborate bullshit on "commodities". I don't mind
               | being a commodity if the standards that you speak of
               | exist, and I don't want to be unique. But guess what?
               | It's the HR that wants us to be the unique commodities.
        
               | arp242 wrote:
               | The most difficult people I've worked with were not
               | because of technical reasons, but due to reasons outside
               | of that: inability to disagree constructively,
               | unwillingness to compromise, or just general assholes.
               | That kind of stuff.
               | 
               | Someone without the required technical chops can be
               | useless, which isn't good, but these people can be _worse
               | than useless_ as they can derail and /or demoralize an
               | entire team. I've seen it happen; it's not pretty.
               | 
               | This isn't unique to younger people, but in my experience
               | the risk is quite a bit _higher_ in younger people. I say
               | this also as someone who, in hindsight, was quite
               | difficult to work with when I was younger for various
               | reasons. As I 've grown older, I've learned a thing or
               | two and I think that now I'm actually a fairly nice
               | person to work with (I hope so, anyway...)
               | 
               | Everything else being equal, I'd rather take someone with
               | a 9 (out of 10) on soft skills and a 6 or 7 on technical
               | skills, than someone with a 3 or 4 on soft skills but a
               | 10 on technical skills.
        
               | yarky wrote:
               | > Everything else being equal, I'd rather take someone
               | with a 9 (out of 10) on soft skills and a 6 or 7 on
               | technical skills, than someone with a 3 or 4 on soft
               | skills but a 10 on technical skills.
               | 
               | I agree, I've even had to reverse my own team's policy on
               | this at work : I used to think the technical stuff was
               | the most important and pushed my team towards hiring
               | exclusively the technically smart people, but I have been
               | proven wrong over and over again by those "smart"
               | engineers I vouched for.
        
               | arp242 wrote:
               | "Smart" isn't just technical skills anyway. You can have
               | all the technical chops in the world, but if you never
               | listen to anyone else, insist on doing things the _One
               | True Right Way(tm)_ , and are unable to admit that you're
               | wrong, then _effectively_ you 're not actually all that
               | smart, are you? "Smart" is really a combination of skill
               | and attitude.
        
         | jijji wrote:
         | On all job responses you should spell out your minimum salary
         | requirements before you agree to the interview, unless you are
         | ok with wasting time on interviews only to get low balled on
         | the salary side or it doesn't match your minimum requirements.
        
           | mitsuchen wrote:
           | Most of us don't have the privilege to negotiate, we are
           | fresh grads. Who doesn't want to work for larger companies in
           | the hope for a better career path? And don't forget about
           | power asymmetry.
        
       | pabs3 wrote:
       | It would be nice if hiring processes were defined publicly up-
       | front in the job advert.
        
       | zschuessler wrote:
       | I was semi-actively hunting for a role a year ago.
       | 
       | The worst offender was a company I had five meetings with, 3 of
       | which were identical code reviews for the same code test. None of
       | the reviewers realized I already had the code review with their
       | peers. None knew what the next step was.
       | 
       | Most companies just didn't have an organized funnel for
       | candidates.
       | 
       | The one that did I quickly took the job offer at. Here's what
       | they did right:
       | 
       | 1. The recruiter prepped me for each interview as if they were a
       | good friend looking out for me. They told me who I was talking
       | with and what hobbies they had so I could relate to them.
       | 
       | 2. I knew of each meeting and its format in advance. It's weird
       | I'm calling this out as it seems simple, but here we are :-)
       | 
       | 3. The code review was paid. And actually quite fun. The previous
       | company code review was unpaid and 20 hours of 'implement a REST
       | API'
       | 
       | 4. The engineering team was actually trained on recruiting. Each
       | one had read my resume and asked detailed questions about my
       | hobbies, experiences, etc. Engineers elsewhere hadn't read my
       | resume at all.
       | 
       | 5. I always had quick feedback on technical meetings and didn't
       | have more than three.
       | 
       | The most important difference I noticed is that most companies
       | were ambivalent seeing me fail.. a select few even seemed to
       | crave that.
        
         | Taylor_OD wrote:
         | The paid code review or paid technical is a big one for me. If
         | a company is willing to actually value my time during the
         | interview process then I'm going to be much more interested in
         | them. Instead of just inventing steps and adding seemingly
         | worthless technicals
        
         | musingsole wrote:
         | > select few even seemed to crave that
         | 
         | I've seen the same thing. It makes no sense. I keep telling
         | myself the incentives can't really be such that your hiring
         | process be actively antagonistic...not if we want anything good
         | right?
         | 
         | But perhaps the market can stay irrational longer than I can go
         | without income. Hold strong to the companies that bother to
         | acknowledge you're a person.
        
       | pts_ wrote:
       | HR gets paid for it candidates should demand payment too at their
       | current rates.
        
       | firefoxd wrote:
       | They can also drop you in the middle of the process. With just an
       | email saying thank you.
       | 
       | I had a long interaction at Amazon where the recruiter told me
       | they are trying something new. Their goal is to keep the
       | candidates mental health in mind and create a welcoming and open
       | process.
       | 
       | I spent 2 hours in the phone where she presented me with
       | different process and what not. I even learned the name of her
       | grand daughter, and her dog, and how she had to raise the grand
       | kids when the mother was going through a phase, and how she had
       | to paint her hair pink to keep up with the new generation. She
       | gave me her personal cell, and we communicated everyday until my
       | assessment test.
       | 
       | I passed the coding challenge. But that cultural or psychological
       | test? No idea. Anyway, never heard from her again despite
       | emailing and texting.
        
         | itronitron wrote:
         | I bet the recruiter you spoke with wants everyone returning to
         | the office.
        
       | dexen wrote:
       | Two months ago there was a news that raised some eye-brows, _"
       | Amazon has a quota for the number of employees it would be happy
       | to see leave (businessinsider.com)"_ [1]. Some of the comments
       | were quite negative, reading it as a dehumanizing practice with
       | no clear upsides. Re-upping my reply [2]:
       | 
       | The article paints a needlessly bleak picture.
       | 
       | The neutral reading of the practice is, "managers are able to
       | take riskier hiring decisions, because they are given an allowed
       | turnover rate".
       | 
       | Which surprisingly enough is a solution to the ever-growing worry
       | of false negatives in hiring - i.e., overlooking good candidates
       | whos resume or interview did not shine strongly enough, or who
       | perhaps are from a shunned, misunderstood culture, or who
       | otherwise did not fit the generic hiring practice prevalent in
       | the society. This solution allows an organization to make riskier
       | hiring decisions at a well understood rate - hopefully catching
       | the false negatives that did slip through competing
       | organizations' hiring process.
       | 
       | --
       | 
       | [1] https://news.ycombinator.com/item?id=27369910
       | 
       | [2] https://news.ycombinator.com/item?id=27370538
        
         | dijit wrote:
         | The issue is with setting a quota as "must" vs "acceptable"
         | 
         | If you "must" find a way to pick fault with your employees
         | because you can only give out 1 "exceeds expectations" and at
         | least 1 "meets most" then you're likely creating a toxic
         | environment from that.
         | 
         | Similar to telling managers that they "probably should" thin
         | the herd.
        
       | karaterobot wrote:
       | The last two jobs I applied for were like this. The first one had
       | 8 interview rounds on 8 separate days. It was a remote company,
       | and I was working in an office at the time, so I had to figure
       | out 8 separate excuses for sneaking away from work for an hour to
       | take video calls. It was ridiculous.
        
       | gorpomon wrote:
       | On my team, I inherited an interview process with 7 steps. It's a
       | long one for sure, and it's not a process I can change. But as a
       | hiring manager I mitigate issues brought up in this article by
       | doing a few really easy things:
       | 
       | 1. On my first chat with a candidate, I layout the entire
       | interview process. I acknowledge that it is long and I
       | preemptively thank them for going through the process and say
       | that we value their time. I make sure our recruiters can
       | reiterate the process as clearly as I can.
       | 
       | 2. I let the candidate know that at any time if they want to pull
       | out, that is a-ok, and that they are welcome to apply again in
       | the future in good standing. I also tell them that during our
       | coding assignment, we really mean it when we say it's ok to ask
       | for more time, and that we don't judge them negatively.
       | 
       | 3. I tell the candidate that if at any point we decide to
       | decline, that I will send them a written letter of feedback so as
       | to make the process worth their time. This isn't always easy, but
       | it's always been appreciated. Sometimes it is hard to write these
       | letters, how do you tell someone multiple interviewers didn't
       | like them? I do it by pressing our interviewers to state clearly
       | what didn't come across well, and then I relay those things to
       | the candidate. Sometimes even still the letters probably aren't
       | super satisfying to the declined candidates, but I do my best and
       | hope everyone realizes that job hunting in general is rarely
       | satisfying.
       | 
       | Basically, transparency, honesty and specifically thanking them
       | have gone a long way for me. I fully understand that an
       | underfunded/understaffed startup might balk at the feedback part,
       | especially when lawyers can get involved. But offering up items
       | #1 and #2 to candidates should just be table stakes of your
       | hiring process.
        
         | ChrisMarshallNY wrote:
         | I liked that. I was a manager for 25 years. I think I did OK
         | with my decisions (for the most part).
         | 
         | One thing that I noticed at my company:
         | 
         | When I first got hired (in 1990), it was made clear that I was
         | a desired and valued employee. They were a very picky company,
         | and might well have rejected me, but I felt respected and
         | valued, from my first interview (I was flown out to the West
         | Coast, and interviewed by two managers at a trade show).
         | 
         | As the years have gone by, I noticed that our HR department
         | started to have a very different posture. They _had_ to be the
         | ones in charge. Applicants were _supplicants_. The company was
         | doing them a favor, by considering them for this position.
         | 
         | Also, the HR department started to project this attitude to
         | current employees, to a visibly increasing degree, over the 27
         | years that I was at that company. By the time I left, the HR
         | posture was that employees were little more than serfs. There
         | was no illusion that employment was a two-way relationship.
         | They started to impose some really draconian policies on
         | employees, with "termination of employment" as the only choice,
         | if the new policy was not acceptable. No negotiations.
         | 
         | I think that this is an attitude that has become a standard in
         | HR, these days, and that part of the reason for this interview
         | process, is to filter for people that won't talk back to HR,
         | and are willing to abase themselves for the company.
        
         | pnt12 wrote:
         | I'd really appreciate a letter with feedback after a lengthy
         | interviewing process, I think that's really valuable.
         | 
         | However, I don't think I'd value it after more than 3
         | interviews. Candidates are applying after work hours and
         | there's a time / energy limit to how many processes they can
         | take at a time. After a given point, you're wasting not hours
         | but possibly months of their life.
        
           | IshKebab wrote:
           | I didn't really realise it until I was on the other end, but
           | if you don't get any feedback you can totally ask for it and
           | there's a decent chance you'll get some.
           | 
           | But I agree, it's usually pretty obvious if you just weren't
           | good enough, or you had a bad day, or they just didn't like
           | you for some random reason.
        
         | krab wrote:
         | I like your approach and I think it really makes the process
         | much better. However, this one thing stands out to me:
         | 
         | > I acknowledge that it is long [...] and say that we value
         | their time.
         | 
         | I dislike this communication style. Maybe it's a cultural
         | difference. I've heard several times from an American speaker
         | that they "value my time/comfort/satisfaction". At the same
         | time their act clearly showed that they valued something else
         | much more.
         | 
         | For me, your sentence would sound much more personal if you
         | just omitted this last part and kept only the explanation.
        
           | Tempest1981 wrote:
           | Agreed. It's more like:
           | 
           | > I acknowledge that it is long process, so we appreciate
           | your patience.
        
         | sumtechguy wrote:
         | Just a rejection letter is _something_ , and in a reasonable
         | amount of time. Many times I would just hear nothing. No
         | response at all. Just a simple 'no thank you' is better than
         | what many get from most companies. It is amazing how many
         | companies do not do this one thing. They just leave people
         | hanging. I had one dude who thought to finally send a 'no'
         | letter. It was 2 years later. That should have been closed out
         | ages ago.
         | 
         | Thank you for doing that sort of thing. It really helps.
        
         | mildweed wrote:
         | Maybe even lay out the interview process IN the job post?
        
         | dr_orpheus wrote:
         | Any response is better than nothing and it is sad that is the
         | line to be above. But I know I appreciate letters actually
         | explaining why I was declined, if they are informative it can
         | actually be helpful for me to improve.
         | 
         | Especially if there is an assignment with the interviews I
         | really think that feedback should be required. I spent about a
         | week on an assignment like this with 3 interviews and just got
         | back a "nope, sorry". And it wasn't even from anyone I had
         | interviewed with, just the original recruiter.
        
       | sdfjkl wrote:
       | > Research shows that if interview processes drag on, good
       | candidates lose interest - and go elsewhere
       | 
       | I certainly would! More than one hour of interviewing is a sure
       | sign of a diseased company that probably suffers from massive
       | management overhead, internal conflict resulting in inability to
       | make decisions or someone's complete paralysis out of fear of
       | making wrong decisions.
       | 
       | You'd have to be pretty desperate wanting to start work at such a
       | place. If not, better to keep looking and not waste your time.
        
       | tomrod wrote:
       | > The National Business Research Institute study shows that a bad
       | hire can have significant costs to an organization - between
       | $25,000 and $300,000 5 . Asking a candidate to partake in four
       | interviews may seem like overkill, but it seems trivial compared
       | to the cost of a "bad hire." Organizations that hire the best
       | data science talent ensure they spend the time to use the best
       | hiring practices.[0]
       | 
       | It's a risk mitigation strategy.
       | 
       | [0] Data Science Playbook, Booz Allen Hamilton
       | https://www.boozallen.com/s/insight/publication/data-science...
        
         | vagrantJin wrote:
         | No one is doubting the risk mitigation, which is why the
         | process exists in first place. But the BS of wasting someones
         | time also needs to be addressed. The reason most companies
         | waste peoples time is because they are too busy with abstract
         | concepts tangentally related to the actual job, and theoretical
         | models by some "expert" of HR management. Software engineering
         | has become a psuedo-religious exercise in computing witchcraft.
         | 
         | If you want a backend engineer - book a few hours, even on a
         | weekend, set up an IDE and get on a real world project. No
         | bullshit. _Build a small API to these requirements, using these
         | technologies but take care of edge cases and deploy that bad
         | boy._
        
         | csa wrote:
         | Are you (or they) suggesting that the 4th interview
         | meaningfully reduces the number of bad hires?
         | 
         | I'm guessing not.
         | 
         | It's poorly designed and/or poorly implemented hiring
         | strategies that lead to bad hires, mostly through a lot of
         | noise being collected during the interview process.
         | 
         | This is a very solvable problem.
         | 
         | Edit: I will add that this is an ad for Booz hiring, so of
         | course they want more process.
        
           | AnimalMuppet wrote:
           | 6 interviews _increase_ the chances of a bad hire (or at
           | least decreases the chances of a great one). It restricts
           | your hiring pool to those who are willing to be abused by the
           | company. That 's not the top-tier talent.
        
             | [deleted]
        
         | ojbyrne wrote:
         | That's quite the range. It suggests a strategy: worry less
         | about hiring false positives (with all the concomitant issues
         | not hiring anyone brings) and worry more about reducing the
         | cost of those false positives.
        
       | a3n wrote:
       | I've never been interesting enough to have gone through that many
       | interviews.
       | 
       | I suspect that these companies have structural problems that
       | inhibit their decision making. Possibly also personal problems.
       | 
       | I also suspect that if they can't say yes after a third interview
       | then the candidate is non-judgmentally not a good fit, by
       | demonstration. Both parties should consider that.
        
       | jesusthatsgreat wrote:
       | Technical interviews are high pressure situations that don't just
       | check someone's technical proficiency but rather their ability to
       | cope with pressure, communicate effectively while under that
       | pressure and their willingness / unwillingness to ask for help or
       | recognise their own weaknesses as soon as they realise they can't
       | do something.
       | 
       | All are essential, day-to-day situations any developer will find
       | themselves in. It's difficult to replicate that in anything other
       | than a technical interview.
       | 
       | Having said that, tech employers don't hold the same power they
       | once did. Decent developers with people skills know they can
       | always find work or just make work for themselves if need be.
       | We're entering an era where these guys will set their own hours
       | and pay and the employer will be the interviewee.
        
       | devnull3 wrote:
       | We only hire the best ... just like everybody else!
       | 
       | - Unknown
       | 
       | (I read this sometime back on HN and it stuck with me)
        
       | gregmclaughlin wrote:
       | I was paid $300 to complete a take-home project for the final
       | interview round at the company I currently work at. Give
       | candidates a 1-2 day take-home project and pay them for their
       | time.
       | 
       | Outcome: You learn how they work, while showing that you value
       | their time.
        
       | nothing_special wrote:
       | We are a mid/small-sized company (~3K) which is hungry for
       | "freshers" (those just out of college). We are out competed by
       | the big sharks who pick the best of the students and we have to
       | search among the remaining. Our hiring pipeline involves a
       | written test (coding - mix of Multiple choice and coding - in
       | favour of only MC nowadays and analytical skills) provided to us
       | by a third party. The test isn't really great (fixed small set of
       | questions which doesnt change, some arcane C coding questions
       | (the likes of https://news.ycombinator.com/item?id=28034019),
       | etc.). So we have 2 rounds of TA (technical assessment) and 1 HR
       | round at the end. This is resulting in a lot of filtering and we
       | get a success ratio of about 4-5 per 1K students.
       | 
       | Management does not like this and blames the assessment team for
       | having "high standards" and feels that we are wasting previous
       | time (of assessors) and not getting desired results. The
       | assessment team feels that the written tests are not a good
       | indicator of coding skill and that most applicants fail in the
       | basics of coding (logic, for loops, pointers etc.). Management
       | has given a new target to reduce the time to hire and increase
       | our hit rate.
       | 
       | The solution will mostly consist of removing HR round (no value
       | add, can be assessed in TA), reducing or eliminating TA (!) and
       | relying solely on the written test. Given the written test
       | quality (though it has mininal configurability in terms of the
       | split between MC and coding questions) this seems likely to get
       | in a lot of "false positives".
       | 
       | My questions - is it really feasible to use only a online
       | automated assessment (not specifically the one we are using) to
       | get a right coding assessment done for freshers? is there a
       | "good" (efficient and effective) "standardized"
       | framework/solution for fresher assessment which one can follow
       | which you have used? (Note: we are a software company providing
       | solutions and consulting in domains like automotive, networks,
       | devices, embedded, etc.)
        
       | stacker8888 wrote:
       | Thanks God it isn't just me!
       | 
       | When I lost my job during the pandemic, I had multiple jobs I was
       | interviewing for, each took maybe a month to get through all of
       | the interviews. Do they really expect unemployed people to suffer
       | through a month of interviews? Some people actually need a job
       | fairly urgently!
       | 
       | And these companies I was interviewing with, they all had a fake
       | air of superiority, like they were the next Google. This
       | interview culture needs to change back to how it was.
        
       | Rapzid wrote:
       | I interviewed with four companies back in May for staff engineer
       | roles(or staff equiv). Based on that experience and my current
       | employers process a somewhat baseline expectation can be:
       | 
       | * Phone screen with recruiter that reached out to you
       | 
       | * Screen with the hiring manager
       | 
       | * Behavioral interview with multiple peeps
       | 
       | * Code pairing session with multiple peeps
       | 
       | * System design session with multiple peeps
       | 
       | So AT LEAST 5 hours time commitment just on interviews. Add time
       | to research the company, its employees, and etc. Maybe the code
       | pairing is instead an at-home test of some sort. This could
       | potentially add hours(or in the case of Teleport like 20+ hours).
       | Just engaging with a handful of companies was a huge amount of
       | extra work and stress on top of existing responsibilities.
       | 
       | I pulled out of three voluntarily and declined an offer from the
       | last for various reasons, opting to stick out till my RSU cliff
       | in October. For the next round of engagements I may start toying
       | with filtering out companies based on their hiring process as
       | well and giving push back on it to see what happens.
        
         | uglygoblin wrote:
         | I had the same experience earlier in the year and ended up
         | bailing out/declining offers because the process was giving me
         | bad feelings about the work cultures at said companies.
         | 
         | I did actually tell one that the schedule of phone interviews
         | (2) and video call rounds (4) was too much commitment without
         | more details about the role and salary range. They responded
         | with "if that's too much commitment the position is too".
         | 
         | Dodged that bullshit!
        
           | nathanaldensr wrote:
           | Isn't it fun when they make you feel like _you 're_ at fault?
           | Nice try, assholes.
        
         | encryptluks2 wrote:
         | Most likely a 20 hour interview is required to be paid,
         | especially if it isn't just a test and similar to the work
         | you'd be doing.
        
       | phendrenad2 wrote:
       | Meanwhile you can go down the street and make 70% as much money
       | with less hassle. Companies with grueling interview processes are
       | inadvertently weeding out people who value their time, which
       | seems like a good kind of employee to have.
        
         | planet-and-halo wrote:
         | Yep. This interview process is pretty much why I'm out of the
         | market. Could I increase my comp? Probably. But the hours of my
         | life are slipping by, and those never come back. I used to
         | enjoy the hours I spent learning to code. Absolutely loved it.
         | Doing this Leetcode crap just to jump through hoops is a
         | miserable waste of life, though.
        
       | blodkorv wrote:
       | Am i the only one who thinks modern dating has the same sort of
       | problem?
        
       | badbetty wrote:
       | Fuck these pretentious companies, almost everyone with average
       | intelligence can work in the role and just pick things up rather
       | than making you run through a maze just for an entry level
       | position.
        
       | xyst wrote:
       | Interviewing these days is not a technical challenge. It's a
       | fraternity/sorority rushing week.
       | 
       | Technically I was qualified and able to answer their questions.
       | But ultimately was turned down after 6 rounds of interviewing. I
       | think I was heavily dinged because I wasn't entirely familiar
       | with their product in the wild, and was never given any hint as
       | to what product I would be working on.
        
         | bufferoverflow wrote:
         | I'm surprised good programmers have the time/patience for 6
         | interviews. I think 3, maybe 4 is my max. If you can't figure
         | out my skills in that amount of time, your process is broken.
         | 
         | I also disagree that interviewing is not a technical challenge.
         | For most programmers it is. There are very few who can breeze
         | through FAANG-level technical interviews.
        
           | knuthsat wrote:
           | For me, if the 2nd interview is not me talking to someone
           | from their company that I might work with and if I cannot ask
           | questions about the problems they solved, their approach to
           | programming or building teams (depending on their role), I
           | just say to the recruiter that I'm not interested.
           | 
           | The only reason why I'd come somewhere is if I like the
           | engineers or if I'm in need of money. If I need the money, I
           | won't ask a thing.
        
           | bb88 wrote:
           | 2 total interviews. Maybe 3 if they have questions. But if
           | they have questions, they should have figured it out between
           | the first and second interview.
        
         | MarkSweep wrote:
         | At one startup I did a couple rounds of phone interviews and a
         | full day of in person interviews. Lastly I got to chatting with
         | the co-founder. I can't remember the precise question I asked
         | about how they were building out the team, but I clearly
         | remember the answer. They made the interview process longer and
         | more involved in an effort to narrow the field of candidates.
         | 
         | I understand the reasoning: if you think you have a special
         | mission and want people dedicated to that mission, filter by
         | dedication. But I'm not really sure there is a way for any one
         | candidate to consume as much time interviewing for a role as
         | that company could consume out of a pool of candidates. And
         | that includes my smart-ass idea of trying to interview at
         | Pinterest and stopping in the middle of the interview saying
         | "please sign up to see the rest of this whiteboard solution".
        
       | ChrisMarshallNY wrote:
       | I've pointed out, before, that one advantage I have, is a _huge_
       | portfolio (check my SO story[0]).
       | 
       | It's tens of thousands of lines of code, in multiple shipping
       | product form. All you need to do is clone a repo, hit "Archive,"
       | and you have a built and App Store-ready app. Some of these apps
       | are still on the App Store (most have been deprecated, over the
       | years). I have full source for shipping apps (over 20), going
       | back to 2012. I've been writing Swift -every single day-, since
       | the day it was announced, in 2014, and have released quite a few
       | apps, written entirely in native Swift. I'm working on a big one,
       | right now.
       | 
       | Here's an example of a repo for a currently shipping free app
       | that is available as an iOS/iPadOS app, a Mac app, a Watch app,
       | and a TV app. It's a Bluetooth BLE explorer app (yes, you can
       | sniff Bluetooth on an Apple Watch)[1], [2], [3], [4]. It uses
       | this cross-platform Swift BLE SPM module[5].
       | 
       | All of the repos also include things like graphic asset originals
       | (usually Adobe Illustrator). I'm a passably good designer. At one
       | time, I considered becoming a professional artist.
       | 
       | All of my work is localizable and accessible. A number of my apps
       | have been localized in multiple languages. These days, I also
       | tend to do things like support Dark Mode.
       | 
       | I have a ton of SPM modules, tested, documented, tagged and
       | available for immediate integration. I use most of them in my own
       | work.
       | 
       | I have full source for a couple of server systems, that are in
       | heavy use, today (I use them in my own work, and one is a
       | worldwide standard, in use by thousands, daily).
       | 
       | I have dozens of blog posts, articles, tutorials, explorations
       | and other online writings[6]. I go into great detail, how I
       | design, test, architect, and think. Most of this stuff is
       | extremely detailed, and comes with supporting playgrounds. I'm a
       | fairly good writer. There's a lot there, but it's quite readable.
       | 
       | I have given instruction on technical stuff for years. The most
       | recent one was a Zoom class on intro to Core Bluetooth, using
       | Swift[7]. It was received well.
       | 
       | I don't know if I have a single fork. I'm the original author of
       | all of it. Since I have over a decade of commit history, across
       | multiple public repository systems, that's easy to prove. I also
       | tend to have fairly informative (and frequent) checkins. It's
       | simple to see how I work. My GH Activity Graph is solid green[8].
       | 
       | My technical ability is not a matter for debate, it's easy to see
       | what I bring to the table (including limitations). I'm satisfied
       | that there's lots of stuff I can do. I won't bother trying to
       | claim abilities that I don't have.
       | 
       | Any interview should be only determining whether or not I'd get
       | along, and whether or not I would be a good "personality fit."
       | Since I spent decades at my jobs, including at one of the most
       | famous brands on Earth, that should also be easy to figure out. I
       | could definitely see that some companies would not want me, but
       | that should be simple to determine. I'm a completely open book.
       | My LinkedIn profile is full of testimonials, by former managers,
       | coworkers, employees, and open-source project partners.
       | 
       | It's been my experience that all this has been _completely_
       | ignored, in favor of ridiculous 50-line binary tree tests.
       | 
       | In one interview, I sent the recruiter links to several public
       | repos of code for shipped applications, that pretty much exactly
       | fit the requirements of the job they contacted me for. This was
       | ignored. Instead, I was passed to an obviously bored tester, who
       | gave me a binary tree test in a language not used by the open
       | position, and I was dinged for not using a formulaic approach,
       | unique to that language (which, did I mention?, was _not_ the one
       | used for the posted job). The repos that I had sent, were in the
       | language that was specified in the opening.
       | 
       | After a few of these broken, insulting, awkward, hazing rituals,
       | I simply gave up looking. It's plain that no one wants me, and I
       | won't go where I'm not wanted. I'm fine, doing my own thing.
       | 
       | [0] https://stackoverflow.com/story/chrismarshall (SO Story)
       | 
       | [1] https://github.com/RiftValleySoftware/BlueVanClef (App
       | Source)
       | 
       | [2] https://apps.apple.com/us/app/blue-van-clef-for-
       | mobile/id151... (iOS/iPadOS App - Includes Watch App)
       | 
       | [3] https://apps.apple.com/us/app/blue-van-clef-for-
       | tv/id1529181... (TV App)
       | 
       | [4] https://apps.apple.com/us/app/blue-van-
       | clef/id1529005127?mt=... (Mac App)
       | 
       | [5] https://github.com/RiftValleySoftware/RVS_BlueThoth (BLE SPM
       | Module)
       | 
       | [6] https://littlegreenviper.com/miscellany/ (Writing)
       | 
       | [7] https://github.com/ChrisMarshallNY/ITCB-master (Core
       | Bluetooth Course)
       | 
       | [8] https://github.com/ChrisMarshallNY#github-stuff (GH ID)
        
       | dredmorbius wrote:
       | The LinkedIn post on which this story is based:
       | 
       | https://www.linkedin.com/posts/mike-t-conley_jobhunt2021-lea...
       | 
       | (Not previously discussed on HN best I can tell.)
        
       | thrwyoilarticle wrote:
       | >According to a survey from global staffing firm Robert Half, 62%
       | of US professionals say they lose interest in a job if they don't
       | hear back from the employer within two weeks - or 10 business
       | days - after the initial interview. That number jumps to 77% if
       | there is no status update within three weeks.
       | 
       | Ha, that's familiar. I'm not in the US but, during my last job
       | hunt, I'd already accepted a job offer before some of the
       | companies I'd applied to replied to me. Companies that are paying
       | recruiters to bombard my inbox or paying staff bonuses to refer
       | me.
       | 
       | Hiring is a very human, very broken process. There's little
       | incentive for an individual to do it well short term but fatal
       | repercussions if the group do it badly long term.
        
       | throwaway984393 wrote:
       | If you go to an interview, you can probably suss out which are
       | stringing you along and which want to hire quickly. Ask if they
       | need a candidate immediately or are taking their time. Ask if
       | your qualifications are exactly what they're looking for, and if
       | you feel like a cultural fit for them. Ask if they have the
       | budget and headcount to hire you immediately. Ask which teams the
       | people interviewing you are on, to find out if they are all in
       | different teams/departments or the same. Ask if each interviewer
       | even knows who the the previous interviewer is in the company
       | ("Frank who?"). Ask if they know exactly what they want you to
       | work on. Follow up periodically to see if they are responding to
       | you in a timely manner.
       | 
       | It's common for there to be some uncertainty with one or two of
       | these things, but if there's a _lot_ of uncertainty, you are
       | being strung along. Best case they are waiting you out trying to
       | find a better candidate, worst case they don 't even have the
       | budget for you and are playing politics within their company
       | using you as leverage.
       | 
       | Interview multiple places in parallel, and don't cancel any
       | interviews until you've got a signed piece of paper. But of
       | course, prioritize the ones that aren't jerking your chain.
        
         | brailsafe wrote:
         | Ya, seems like decent advice.
        
         | ajna91 wrote:
         | good advice
        
       | lormayna wrote:
       | Before pandemic, I was contacted by a recruiter for a position in
       | a growing security startup for a role in technical pre sales. It
       | start with a call with the recruiter, then a call with the VP
       | that sent me an exercise to make in a short time (4 days). I had
       | a full time job, so I worked hard during the weekend and in the
       | night to finish the task and I was not able to finish everything
       | (just last step was missing). Then I presented everything to VP
       | and he gave me more time to finish and last step and schedule
       | another meeting to discuss everything. After this time I was
       | contacted by recruiter, that told me that I was in the very short
       | list of two candidates. He then arrange an interview with the VP
       | of HR and the VP of sales. After those two interview they
       | completely disappeared and ghosting me. I had other job
       | opportunities, then I tried several times to ping them and they
       | never replied back. After 5 emails without reply, I told them
       | that I was going to accept another job offer and the recruiter
       | replied that this was the right decision, because the company
       | made other choices.
       | 
       | I lost so many hours on this interview process that I would like
       | to send them an invoice :)
        
       | vector_spaces wrote:
       | I had an interview with a YC company last year. I went through --
       | not exaggerating -- 8 interviews, almost all of which aside from
       | the initial phone screen were an hour or more in length. 2 of
       | them were technical interviews. I had finally gotten to the take
       | home project, naturally a project in Ruby on Rails despite the
       | fact that I haven't written a lick of Ruby in my life. Anyway, I
       | was rejected after this step. To be fair, the take home step was
       | paid, which was nice, but not nearly enough for the time it took
       | me to learn enough Rails to be productive, learn best practices /
       | idiomatic Ruby, and solve the problem they gave me.
       | 
       | Incidentally I've noticed that the Ruby community has this weird
       | thing about insisting on either N years of Ruby experience or
       | requiring interviewees use Ruby during technical interviews or
       | take home projects. Ruby shops were the only places where I've
       | ever been required to use a particular language during an
       | interview. I suppose it's because there's so much magic happening
       | in DSLs like Rails that they assume it'll take too long for even
       | experienced engineers to come up to speed?
       | 
       | Obviously there's risk involved in the hiring process. But I
       | think there's a lot more risk involved in procedurally treating
       | people like garbage.
       | 
       | Anyway, after that ordeal I'm going to insist on being allowed to
       | interview in a language I'm familiar with. They'll judge me on my
       | best work or not at all.
        
         | wodenokoto wrote:
         | How far in the process were you before you found out you had to
         | code Ruby on Rails and present it?
        
       | nowherebeen wrote:
       | > Five companies told him they had to delay hiring because of
       | Covid-19 - but only after he'd done the final round of
       | interviews.
       | 
       | This is a typical HR strategy to keep themselves busy so they
       | don't get laid off. HR is not a revenue generating department, so
       | even if they aren't hiring, then they still need to push paper.
        
       | notjes wrote:
       | There might be a psychological part in it to seek candidates that
       | are willing to go through degrading interview meat grinders. I am
       | not sure those candidates would be what a humane society needs.
        
       | DebtDeflation wrote:
       | I remember over a decade ago interviewing at a bank and being
       | asked how much experience I had with [insert list of systems] and
       | integrating data specifically between two of those systems. I had
       | never even heard of any of the systems on the list. Got home and
       | Googled them, nothing. Called up a friend who worked there and he
       | told me those were internal names for their systems, no one who
       | did not work there would have any idea what they were, and he was
       | shocked they were asking about them using their internal names
       | during interviews. Oddly enough, one was just an Oracle data
       | warehouse fed by Informatica ETL and generating Cognos reports,
       | and I had experience with all of that technology, but answered
       | "no" when asked if I had experience with "the Pulsar system".
        
       | binarymax wrote:
       | If you can't make a decision after 3 rounds then you have no
       | business recruiting anyone and should just give up. You'll not
       | only irritate and push away all your good candidates, but you'll
       | also make your staff angry that they're always wasting time
       | interviewing people.
        
       | irrational wrote:
       | It's weird I'm seeing this on the same day as
       | 
       | https://news.ycombinator.com/item?id=28029344
       | 
       | So... which is it? Or did some employers not get the memo? Or is
       | this tech vs non-tech positions?
        
         | kxrm wrote:
         | Perhaps it depends on where you are in your career.
        
       | tekkk wrote:
       | I think the biggest give-away from the article and from the
       | comments written here is that companies neglect recruiting as a
       | chance to generate positive brand impressions and in general, use
       | it for marketing. If people walk away from your interviews
       | feeling disappointed or mistreated there's a good chance they
       | won't recommend or advocate for that company in the future.
       | 
       | You'd think spending some executive muscle to smoothen out the
       | warts in the process would be beneficial to any company trying to
       | recruit smart people. But I guess having regular engineers or
       | other employees with whatever ineptitudes in empathy or social
       | skills won't be fixed by somebody telling them to "be sensible
       | and nice." If that's how they were treated and think it's ok to
       | treat others the same way, that's how it will be.
        
       | alephnan wrote:
       | What's not mentioned is companies collectively want to waste
       | candidate's time.
       | 
       | If candidates have less time for interviews, they will have less
       | offers/counter offers to use as leverage
        
       | jijji wrote:
       | the best jobs I've had were at most three or four interviews and
       | then hired. The worst ones were more than 5 interviews and they
       | still couldnt make a decision or one guy out of six didn't like
       | you so you don't get hired...
        
       | tomcooks wrote:
       | Currently investing 2 hours of my time per job offer:
       | 
       | - investigating the role, the company, their stupid website,
       | their made up culture
       | 
       | - doing the unpaid take home tests (currently investing 8 hours
       | doing a technical test for yet another stupid startup)
       | 
       | - answering dumb questions ("why do you want to work for
       | $neverheardofstartup?") on fancy js forms
       | 
       | - having to register to their stupid career backend, thanks for
       | yet another chance of having my inbox filled with spam because
       | you don't know how to encrypt data
       | 
       | - uploading hours and hours of video presentations (as if cover
       | letters weren't dumb enough)
       | 
       | only to be canned with a copy-paste "due to the amount of
       | curricula we received unfortunately we cannot provide feedback -
       | good luck with your job search" nonsense.
       | 
       | And if I'm lucky enough not to be weeded out by a bored-to-death
       | HR person with the attention span of a starving kitten, this was
       | just interview step 1/5
       | 
       | Fuck you, from the bottom of my heart.
        
       | jedeye wrote:
       | failing on the 4th interview is vsry traumatizing
        
         | jedeye wrote:
         | I completely broke down and put in all my sick leave. I haven't
         | cried like this in years and I have to go through therapy and
         | all the things. I'm going to be ohkay at least my code still
         | works and is still making the company I currently work for a
         | lot of money. So I am just taking some time off to heal myself
         | and address my burnout at the same time. There is hope after
         | falling hard like that.
        
       | elmolino89 wrote:
       | I am fine that up to the ~3 interviews covering the different
       | aspects (say HR person checking the general personality, IT guy
       | for i.e. Linux sysadmin knowledge mini-test, the team manager).
       | In 2020 after the Covid started, I got into the endless spiral of
       | I believe 6 interviews spaced over a month or so, then the long
       | wait and getting shorter contract with same salary but different
       | from the advert job title. With the back against the wall I took
       | the job. Within 3 months or so (including a 1 month training)
       | they re-posted a job advert for my position. I had to extract
       | from them an info that my contract described as "with almost
       | automatic extension" will not be extended ("we run out of
       | funds"). I work off my posterior for months to get this.
       | 
       | In short: shit on input does not bide well
        
         | epicureanideal wrote:
         | > HR person checking the general personality
         | 
         | I would say that's the worst person to do the personality
         | check. Instead, engineers the hire would actually work with
         | should probably do the personality check.
         | 
         | Often HR is either a bureaucrat with a non-technical degree, or
         | an inexperienced young "internal recruiter" with a non-
         | technical degree and a pleasant appearance meant to attract
         | responses on LinkedIn. Neither of those are uniquely well
         | suited to judging personalities. (Unless this is another case
         | of, #wontfix, we want to screen out engineers who have
         | personality characteristics that random 24 year old sociology
         | students don't like.)
        
           | higeorge13 wrote:
           | Exactly this! They are probably the most incompetent people
           | included in the hiring process, and yet they will take part
           | in the decision making with their 'magic' personality
           | judgement and culture fit skills, always making the wrongest
           | decision ever. I had candidates rejected by HR because they
           | were too charming, too lively, too <insert random
           | characteristic>, to find them later employed in way better
           | companies and roles. Well done HR, now you have your culture
           | and team fit, for a team and culture you are not even
           | managing.
           | 
           | Ah and your professionalism stops as soon as you hire
           | someone. The rest of candidates might be left without a
           | response even in their 3rd reminder. I guess it's tough to
           | even setup the auto email notification in the ATS tool you
           | are using.
        
       | towtow wrote:
       | Just recently experienced this. Interviewed at a FAANG company,
       | process started 5 months ago, about 50 emails exchanged, a dozen
       | or so phone calls of various kinds. 6 interviews, they came back
       | and asked to re-do 1 of them, which I obliged. Then, they were
       | silent for about 2 weeks, I asked about the status and they said
       | they want to re-do 2 more interviews. I kindly refused and they
       | said they wouldn't move forward.
        
       | nine_zeros wrote:
       | Next time you hear a hiring manager complain about shortage of
       | engineers, ask them why haven't they changed the process with
       | recruiting instead of just trying to fan out and sending
       | automated tests and take home assignments.
        
       | ryeguy_24 wrote:
       | I work for a big 4 consulting firm and I think our process works
       | well and is extremely short. We hire financial engineers (quants)
       | and data scientists. I've lived through working with hundreds of
       | hires and can say from actual experience it works quite well.
       | This is our process:
       | 
       | 1. Review resumes to see who meets the criteria based on
       | credentials.
       | 
       | 2. Recruiter phone screen to screen for any glaring issues
       | 
       | 3. We conduct an interview day and the candidate interviews with
       | 3-4 people (30 minutes each). We have a mix of levels conducting
       | interviews but make sure to have at least 2 leaders from our
       | practice. We try to make sure we collectively poke around all
       | areas (technical, cultural, communication).
       | 
       | 4. That same day or the following day (want to make sure
       | candidate is fresh in our heads) we discuss candidate.
       | 
       | 5. Each interviewer (starting with the most junior) has to speak
       | about candidate and rate them from 1-3. It can be any decimal
       | rating but cannot be a 1.5 (an "I don't know" answer).
       | 
       | 6. Interestingly, we are mostly in the same ballpark on these
       | calls and when we move forward, we are generally happy with that
       | person.
       | 
       | I can't speak for the candidate who may have to wait a bit
       | between application, recruiter conversation, and interviews. But
       | at the very least, the interview to decision process is pretty
       | painless and you'll have a decision within 2 days max.
        
       | easterncalculus wrote:
       | It's just such a waste of time, too - you toss out so many other
       | potential opportunities when doing these. I've heard of this
       | being done to interns, people that only have so much time to get
       | a job. Six interviews until a rejection. If you can't start your
       | career without this going on I don't really know what you can do.
       | I can't imagine the recruiters conducting these in the same
       | position, going for six interviews to get that job. For software
       | engineers you just _need_ it, apparently.
        
       | hasa wrote:
       | I developed software professionally over 20 years and I get
       | impression that I would not have survived any of these
       | interviews. I remember the times in 90's when I had most of the
       | Java classes & methods in my "working memory", but after that
       | came syntax helpers and search engines. That ruined whole concept
       | of programming with just text editor. I don't know if anyone else
       | has similar experiences.
        
         | solumos wrote:
         | > That ruined whole concept of programming with just text
         | editor.
         | 
         | What "ruined" it for you, "made" it for me :)
         | 
         | I absolutely hated my CS courses in undergrad and dropped the
         | major after 2 classes. Didn't get back around to programming
         | until a few years later - using Google makes it way more
         | doable.
        
           | hasa wrote:
           | Actually I agree with you as I would not be able to program
           | much without Google today. But many reported here about
           | interview situations where they had like white paper and task
           | to develop something. It is something they never face in real
           | work.
        
       | hizxy wrote:
       | If you need more than 3 interviews then you don't know how to
       | hire. Unfortunately, so many people don't know how to hire.
       | Myself included ;)
        
       | qubyte wrote:
       | I once interviewed for a large game company. Their main office in
       | Europe is in Dublin, but at the time they were opening an outpost
       | in Brighton, UK (where I am) and were hiring a server engineer
       | for their e-sports division.
       | 
       | There were _a lot_ of interviews. For the fourth or fifth they
       | flew me out for a whole day of interviews in Dublin. These
       | included at least three different departments that I remember
       | with separate coding interviews, and I had to give an hour long
       | presentation.
       | 
       | I didn't get the role, and shortly after the Brighton outpost was
       | axed. In hindsight I'm pretty sure that I didn't get the role
       | because someone high up didn't want the outpost office to exist
       | (it was only there because someone important they wanted was
       | determined to live here).
       | 
       | I'm not sore though. Not long after the company hit the news for
       | having a toxic culture (amongst other issues), particularly
       | toward women.
        
         | qubyte wrote:
         | I should add, this was several years ago. I'd never put up with
         | that sort of crap now.
        
       | ivolimmen wrote:
       | I don't recognize this at all in my country (Netherlands). I have
       | 2 interviews max. My current employer I actually had one
       | interview with the boss in a restaurant. We had a nice chat and
       | he offered a job on the spot. I signed and never left. As I am a
       | consultant I ofter do interviews and I always stear the
       | conversation to the most important part of IT: communications.
        
       | a_square_peg wrote:
       | The trouble with interviews these days is that there is no
       | penalty for false negatives.
       | 
       | Long, multiple interviews are great for those who are already in
       | the group - it provides legitimate excuse to hold off doing
       | actual work, feel smug with their peers about how difficult the
       | job is, and also provides acceptable excuse for project delays.
       | 
       | As a senior engineer, it's amusing being interviewed by
       | intelligent but very junior engineers who clearly cannot
       | understand the scope of what's in the resume. This usually
       | happens with a quickly scan of the resume followed by a
       | realization (there is this peculiar look) that they don't have
       | any relevant questions to ask about the experience, and finally
       | landing on their favourite puzzle questions because what they
       | really want to know is how my thought process works.
        
       | [deleted]
        
       | js4ever wrote:
       | In 2007 I had 13 interviews with Microsoft before finally being
       | rejected at the last step. Reason invoked was "Not enough
       | corporate spirit". That was my last rounds of interviews, since
       | then I have my own consulting company and never regretted this
       | failure, quite the opposite in fact :)
        
       | ravishankark wrote:
       | While interviewing with a start up, I was asked to do an
       | assignment which took almost a week to complete. After the
       | assignment, I went through 6 rounds of interview.
       | 
       | Then they kept me hanging for a week, only so send me a rejection
       | mail.
        
       | cik wrote:
       | I've never understood this. The first interview exists to sell me
       | on the company, and for me to express my desire to work there.
       | It's for alignment.
       | 
       | Three questions I always ask are 1. What's your hiring process,
       | 2. What's the base salary range, 3. How does the company
       | demonstrate its commitment to ongoing learning. Any reticence to
       | discuss these items means that I learned about how the company
       | just isn't for me.
        
       | yawaworht1978 wrote:
       | Indeed, almost nothing is available without investing 5 or more
       | hours of your time. I have seen interview 1,2 plus full day on
       | site development with senior dev for a front end job and
       | something like 10 hours worth of assessments at FAANG. These are
       | not high paying jobs btw.
        
       | andix wrote:
       | Decision fatigue, one of the biggest problem of this century.
       | 
       | There is a lot of pressure, if you hire the wrong person, someone
       | has to be responsible. That's why they developed a lot of
       | processes. So if the person turns out to be the wrong person for
       | the job, you can tell everyone you thoroughly vetted them, and
       | it's not your fault.
       | 
       | From my perspective the only way is: Interview people once or
       | twice, hire them as quickly as possible, work with them for a few
       | days/weeks and make a quick decision (together with the person)
       | if it is going to work out.
        
       | jedeye wrote:
       | I got recruited for a an interview at a fund management firm.
       | Went through four interviews and got rejected a week later after
       | the 4th interview. Companies don't realise some of as are so
       | burnt out and have worked so hard during the pandemic. I removed
       | myself from LinkedIn because of it. No hard working dedicated dev
       | should be treated like the past didn't happen. I know what you
       | guy's and girls are going through and I just want you to remind
       | you you are more precious than gold and diamonds and you don't
       | need beaurocrazy to validate determine your value. We will
       | continue to build a better world and treat our future candidates
       | with respect they deserve and not make them jump through
       | impossible hoops designed for idealist machinemen
        
       | karmasimida wrote:
       | If all interviews are scheduled at the same day, I am OK with it.
        
       | shanev wrote:
       | DAOs are fixing this in the crypto world. You contribute to the
       | protocol and get paid by the DAO. Everything is transparent and
       | open. If you do this enough and earn the respect of the dev team
       | it could even turn into a full-time role.
        
       | eplanit wrote:
       | These stories reinforce my decision to go into consulting so long
       | ago. People hire me because they can't get stuff done, and they
       | need it done now. We're not getting married, and I'll be gone as
       | soon as the project/mission is accomplished. And, no BS coding
       | tests.
        
       | underseacables wrote:
       | Top Grading: A complete waste of time and effort.
        
       | Twirrim wrote:
       | I had a friend who had a similar experience to the candidate in
       | the article, but at T-Mobile.
       | 
       | He was unemployed. They interviewed him 5 times over a month and
       | a half, and tried to get him on site for a 6th interview loop
       | roughly 2 months after starting the whole process. They were most
       | put out when he told them he'd already got another job. He was
       | amazed at how offended they were, especially that _he 'd_ wasted
       | _their_ time.
       | 
       | He was, apparently, supposed to just sit around and wait for them
       | to make a decision, because who needs money to pay for things
       | like rent, food etc?
        
       | RIDDLERTHIS wrote:
       | I can relate to the whole "never-ending job interviews" as
       | described in the article.
       | 
       | Two months ago, in June, a company reached out to me regarding a
       | senior level back/front hybrid role. This company previously
       | ghosted me two years ago but still had my resume and were now
       | willing to hire me right away for a substantial increase in pay.
       | 
       | Before I accepted any offer, I shopped myself out on Indeed and
       | found there is a huge demand for folks like myself right now.
       | Here's a taste of how it went: Company #1: Fintech startup. Two
       | separate 30 minute, non-technical interviews. Third interview was
       | a four-hour long interview involving multiple LeetCode problems.
       | Fourth interview they wanted to discuss my performance during the
       | third interview, and then schedule a fifth interview. I declined
       | because a) I felt this was overkill and unnecessary, and b) one
       | of their developers was rude and condescending because I am self-
       | taught. He went out of his way for 8 minutes to berate me. I had
       | never experienced anything like it.
       | 
       | Company #2: AI-focused firm in analytics. Hiring for a
       | management-level role. Went through three interviews. First was a
       | 30 minute screening. Second was an hour long overview of my
       | technical background. Third was mostly a follow-up to the
       | discussion that took place during the second interview. And at
       | the end of the third interview they informed me there would be
       | four more interviews to meet the team, write code, and a
       | whiteboarding session. I declined and said I'm not interested,
       | again because of the time factor mostly.
       | 
       | And I noticed this process repeat itself for most companies. It's
       | mentally exhausting, plus I have a family, my current job
       | requirements, and other responsibilities.
       | 
       | The interview process is really unpredictable to a degree. Some
       | folks want to see substantially more coding than others, taking
       | into account similar job roles and descriptions.
       | 
       | I see a lot of folks who have interviewed with FAANG companies,
       | and while I don't have any experience with them, the process
       | sounds somewhat similar.
        
       | wesleywt wrote:
       | Not a "tech" job, but I found that the best hires were people who
       | worked on contract for a few months. They did not necessarily
       | have the skills when they started, but you could see drive,
       | diligence and competence in those few months. This attitude needs
       | to be maintained every day and cannot be faked as easily as you
       | can an interview. A bonus is that they get paid for their time
       | while getting valuable job experience.
       | 
       | It might only work for low-level entrants. For higher positions
       | you are hiring the person for their experience, not on how well
       | they can jump through arbitrary hoops.
        
       | vincewolff wrote:
       | Since I finished college I was on a interview loop. I'm so tired,
       | at this point making my own company and freelancing seem more
       | reasonable.
       | 
       | I don't understand why there must be 4 different persons asking
       | me the same questions just so in the final to give me a lower
       | offer than we previously discussed or to ghost me.
       | 
       | I had a bad opinion about HR when I was a student and didn't work
       | based on how a few of my friends and family treated, now that I'm
       | looking for work and have to deal with their bullshit daily I
       | literally started to hate the people working on this dep and
       | their lack of respect.
        
       | dzonga wrote:
       | problem, is as an industry we're treating software engineering as
       | a science only. forgetting it's part science part art. now you
       | can be smart, but not be artistic. which is a major problem,
       | google n other faangs have notorious interviews which wannabes
       | copy. yet can't make software that works half the time. maybe
       | it's high time, the software industry looks at how creatives get
       | hired. coz after all we're a creative industry - just only using
       | engineering principles to create art
        
       | ironman1478 wrote:
       | I don't mind going through a single day with many rounds, but
       | when it's spread out it's super frustrating. It feels really
       | disrespectful of my time. I interviewed at Apple and had like 3
       | onsites with different teams all in one week and got the results
       | quite quickly. It was such a good experience compared to some
       | companies where it's such a chore.
       | 
       | I also think the attitude of companies during interviews really
       | sucks. Many feel like they're doing you a favor or you're wasting
       | their time. That was a distinct feeling I got when interviewing
       | at Google, but not at Apple and I really think it's why I passed
       | those and not google. They were collaborative and fun at Apple. I
       | put a lot of effort into making candidates at my company feel
       | welcomed and like they are already part of the team and IMO it
       | really helps them succeed.
        
         | kamkazemoose wrote:
         | Part of the problem is that Manton the interview panel do feel
         | like they're wasting their time. It is valuable to the company
         | but for the engineers, they want to get back to coding or
         | whatever else they are working on.
         | 
         | It isn't fair to the person applying because they didn't pick
         | the people on the panel, but if the one doing the interviewing
         | doesn't hide their feeling it's obviously not great.
        
           | ironman1478 wrote:
           | That's true. I want to say that that's Google's fault right?
           | Because not everybody is on the team you're interviewing for
           | (I might be wrong)? At Apple you are interviewed by the team,
           | who presumably needs another person to assist them.
           | 
           | Also, regardless of whether or not they want to be there,
           | it's a bad look for the company. Somebody took a day off to
           | talk to you, it's only fair that an interviewer reciprocates
        
             | ladberg wrote:
             | Can confirm everything you said is true and that at Google
             | you'll likely never see your interviewers once you start
             | working there but at Apple you'll be working with your
             | interviewers on a daily basis.
             | 
             | It has upsides and downsides, like as you said you had to
             | go through 3 different on-sites (one for each team), but
             | you'll get a good sense of the team before getting an offer
             | (and they'll get a good sense of you). I like the Apple
             | method much better but I had an unusually bad Google
             | interview process so it's possible other people had better
             | experiences.
        
               | tonyedgecombe wrote:
               | The good thing about interviewing with your teammates is
               | they will be invested in making it success if they
               | recommended you. If you never see the interviewer again
               | then they have no skin in the game.
        
               | aix1 wrote:
               | > at Google you'll likely never see your interviewers
               | once you start working there
               | 
               | Can confirm that this is largely true, with an asterisk.
               | 
               | The interview panel (for SWE candidates) is indeed drawn
               | at random, but it's becoming more and more common to
               | conduct fit interviews for specific roles. This is
               | usually done by the hiring manager, in rare cases also
               | involving other people (e.g. the tech lead).
        
             | noirbot wrote:
             | Some of the difficulty is that the team may be hiring
             | people because they're currently under-staffed. I've been
             | on teams before where we're 3 engineers on a team that
             | we're trying to hire up to 6 people. It's really hard to
             | both try to keep up the work of 2 people, even in
             | maintenance, and spend hours every week on trying to hire
             | the replacements. Even if the company is good about
             | reducing demands for new work after a departure, it's
             | generally true that you're hiring BECAUSE you need more
             | people on the team, which often means that team is
             | overworked already.
        
         | valdiorn wrote:
         | I once applied for a job at an oil trading hedge fund in
         | London. The company was small, and everyone who worked there
         | became a partner in the firm once they joined. There were about
         | 23 people there IIRC. I did a 1 hour interview with one guy, a
         | bit technical, a bit of random trivia. Then another guy,
         | similar thing. Then the third guy.
         | 
         | After that I asked how many more interviews I should expect. To
         | my horror the answer I got was "we only hire people if all the
         | partners agree to hire you, we all have veto power, so you
         | should expect to see everyone"... so TWENTY more interviews. I
         | rather abruptly told the guy that was insane and I didn't have
         | time for that, shook his hand and walked out. He seemed
         | perplexed.
         | 
         | ... they went bust about a year later.
        
         | brainwad wrote:
         | It can get very demoralising as an interviewer when you
         | interview dozens of candidates, and none meet the bar - and
         | even the ones you rate hire or leaning hire get rejected by the
         | hiring committee. When I first started interviewing (at Google)
         | I was like the Apple interviewers you admire, but I have slowly
         | become inured the process and now I probably give candidates
         | the impression that I've seen it all before and I would rather
         | be doing something else - because it's true.
         | 
         | But the alternative is more filtering before the main round of
         | interviews, to increase the base success rate of candidates,
         | which many people hate (see many other comment threads on this
         | post). And too much would turn off the best candidates probably
         | more than the worse candidates, as they have more outside
         | options.
        
       | robertwt7 wrote:
       | Aren't FAANG companies doing at least 4-5 interviews now?
       | 
       | More and more companies are doing this now in tech space (AU) as
       | well. My last 4-5 job app contains 5 interviews, even the medium
       | sized one.
       | 
       | It is super annoying for me, but I'm not sure what to do about
       | it, some of my dream big tech companies are like that so I have
       | to go through that. I'm pretty sure a lot of people go through
       | with that because that's their dream job too, not because they
       | liked it
        
       | dredmorbius wrote:
       | In domains in which the underlying domain is complex, with an
       | irreducible informational complexity, as well as rich and
       | frequently highly significant interactions, there's a frequent
       | emergence of faddish, or ritual-driven, behaviours. Both seek to
       | reduce risks and accountability, as well as to increase credible
       | signalling of traits.
       | 
       | Both sides of the technical recruiting transaction (job-seeking
       | and recruiting) exhibit these behaviours and tendencies (what to
       | wear, how to format resumes, presentation, side projects, for
       | seekers, interviewing, tests and screens, and other filtering
       | practices for hiring teams).
       | 
       | The consequence is a tremendous amount of friction, inefficiency,
       | and fear-driven lore. Some years ago a senior Google staffer
       | commented that they'd found a guaranteed hiring heuristic: "No".
       | That is, reject _all_ candidates.
       | 
       | My response was that if this was serious (and it was at least
       | partially), that this was a profound sign of weakness within
       | Google: an inability to seek out and onboard talent successfully.
       | 
       | There are other possibilities.
       | 
       | It could be that the notion of private firms hiring highly-
       | skilled talent is inherently flawed.
       | 
       | I've speculated that one of the justifications for the ancient
       | Egyptians to build pyramids was as a combination of a skills-
       | development, skills-retention, skills-demonstration, and brain-
       | drain-mitigation programme. From what I've read there's at least
       | some independent informed speculation along similar lines.
       | 
       | One of the functions of writing a book, a notoriously
       | unremunerative practice, is as a credible signalling of skill and
       | ability. (And of book-writing capabilities, for what that's
       | worth.) Books are very fat sales brochures.
       | 
       | In a tech world in which typical tenures are measured in months
       | or single-digit years (2--3 years being typical from what I
       | understand), and correlations between _any_ hiring practices and
       | actual performance ... at best weak, there 's an inherent issue.
       | 
       | There's also the question of equitability of a process in which
       | employers have vastly greater access to information on individual
       | prospects than prospects do on companies or hiring managers /
       | management teams. George Akerlof's "Market for Lemons" suggests
       | that more information makes markets more efficient, though my
       | fear is that _highly asymmetric_ information access further tilts
       | the employment market in the hiring firms ' favour.
       | 
       | https://www.jstor.org/stable/1879431
       | 
       | http://libgen.rs/scimag/10.2307%2F1879431 Some of my earlier
       | fad/information theoretic musing here:
       | 
       | https://old.reddit.com/r/dredmorbius/comments/62uroa/clothin...
        
         | thaumasiotes wrote:
         | > I've speculated that one of the justifications for the
         | ancient Egyptians to build pyramids was as a combination of a
         | skills-development, skills-retention, skills-demonstration, and
         | brain-drain-mitigation programme. From what I've read there's
         | at least some independent informed speculation along similar
         | lines.
         | 
         | Brain drain mitigation? Brain drain just wasn't a _possibility_
         | 4400 years ago.
        
           | dredmorbius wrote:
           | If you're living in a domain in which your core competency is
           | in constructing complex stone structures, then leaking that
           | capacity to another kingdom or empire would be a risk.
           | 
           | Pharonic Egypt circa 2580 was not without neighbours and
           | there was both trade and warfare in North Africa and across
           | the Levant and Mediterranian, notably with Syria, Canaan,
           | Lebanon ("cedars of Lebanon" are a significant reference, as
           | Egypt had virtually no timber), Ethiopia, and Nubia, amongst
           | others. There's also the prospect of defection to internal
           | factions. The Old Kingdom seems to have been generally
           | peaceful with little internal _or_ foreign warfare, at least
           | until the First Intermediate Period, which was largely an
           | internal rivalry. But it wasn 't _entirely_ without defence
           | concerns.
           | 
           | https://en.wikipedia.org/wiki/Ancient_Egyptian_trade
           | 
           | https://www.worldhistory.org/Egyptian_Warfare/
           | 
           | I'm very happy to admit that my hypothesis is just that, and
           | that there's no evidence and only a very little external
           | support, though there is _some_. But _if_ you 're going to
           | develop an advanced skill that would be of use throughout the
           | region, it might be advisable to find ways to hold on to it,
           | and as a pragmatic explanation for what was an absolutely
           | immense effort ... there's some sense in the concept.
        
             | thaumasiotes wrote:
             | > If you're living in a domain in which your core
             | competency is in constructing complex stone structures,
             | then leaking that capacity to another kingdom or empire
             | would be a risk.
             | 
             | How? The only military use of large stone structures is as
             | fortifications; their primary feature is that they can
             | never move.
             | 
             | And Egypt isn't even known for its city walls. That's the
             | other civilization of the time, ancient Mesopotamia.
             | 
             | But on top of all of that, none of that is a brain drain
             | issue. You're talking about a hypothetical issue of loss of
             | state secrets. Brain drain is the concern that the local
             | population of skilled workers will all emigrate, leaving
             | the country unable to do skilled work. It's not the concern
             | that other countries may develop the technology to do the
             | same things that you can do.
        
               | dredmorbius wrote:
               | Building pyramids isn't simply piling rocks on top of one
               | another.
               | 
               | There's mathematics, surveying, architectural design,
               | measuring, logistics, labour organisation, planning,
               | transport, engineering, and a whole mess of related
               | skills. If not kept in practice, they are lost (you're
               | focusing strongly on the "brain-drain" element at the
               | expense of "skills retention" and "skills development
               | bits).
               | 
               | Too: once you've got those capabilities, there are
               | numerous _other_ abilities which derive from them. Large
               | structures means civil engineering, construction, grain
               | storage facilities, and quite probably some degree of
               | metalworking and related crafts, again, which can prove
               | useful in either foreign or civil war.
               | 
               | Take some time to think through possiblities,
               | consequences, options, risks, and opportunities here.
        
               | thaumasiotes wrote:
               | > you're focusing strongly on the "brain-drain" element
               | at the expense of "skills retention" and "skills
               | development bits
               | 
               | Well, yeah. Look at my comment, in its entirety:
               | 
               | >>>> Brain drain mitigation? Brain drain just wasn't a
               | _possibility_ 4400 years ago.
               | 
               | If you can't defend that, then... don't? Make the
               | argument that isn't obvious nonsense; you don't get more
               | credible by throwing in a laundry list of "concepts that
               | sound bad".
               | 
               | > There's mathematics, surveying, architectural design,
               | measuring, logistics, labour organisation, planning,
               | transport, engineering, and a whole mess of related
               | skills. If not kept in practice, they are lost (you're
               | focusing strongly on the "brain-drain" element at the
               | expense of "skills retention" and "skills development
               | bits).
               | 
               | There would have been no lost opportunities to exercise
               | these skills in the absence of pyramidal efforts. They
               | built temples, palaces, and cities on a continuous basis.
               | Surveying is a constant need of anyone who collects
               | taxes. (And it's _particularly_ important in Egypt, where
               | everyone 's property lines move every year to match the
               | extent of the flooding of the Nile.)
               | 
               | As far as I've read, the Old Kingdom pyramids stopped
               | being built when the colossal economic strain they
               | involved nearly collapsed the state. That doesn't suggest
               | that they were useful in employing otherwise idle
               | technicians. It also doesn't suggest that the system
               | governing them was especially capable at logistics and
               | planning. Planning would have involved noticing "this
               | pyramid will cost X amount to build, which is more than
               | we can afford".
               | 
               | > Large structures means civil engineering, construction,
               | grain storage facilities, and quite probably some degree
               | of metalworking and related crafts
               | 
               | I think this is backwards to a certain extent; I'd run
               | causation from grain storage -> large structures, not the
               | other way around.
        
               | dredmorbius wrote:
               | I'm not interested in litigating minutia. I've addressed
               | the point. I've admitted, repeatedly, that this is a very
               | weakly-supported hypothesis, though not entirely without
               | merits. Substantive proof is unlikely to emerge from a
               | tendentious HN debate.
               | 
               | You're the one constructing a far more magnificant
               | pyramid of this than I'd ever intended.
        
               | 7sidedmarble wrote:
               | This is the most hacker news comment I've ever read on
               | hacker news
        
       | kxrm wrote:
       | I am actually going through the hiring process now. I was a
       | hiring manager at my last shop and I tried to be very respectful
       | of the candidates time.
       | 
       | The process was first interview was 30 mins and basically a
       | getting to know you and us session. Second interview was a two
       | hour technical interview with debugging/fix this function type
       | question and a single from scratch example question in the
       | candidates language of choice. The final round was purely
       | optional if the CTO or CEO wanted to meet the candidate (they
       | rarely did).
       | 
       | If you made it through all that you got an offer. Of all the
       | candidates I hired only 1 didn't work out long term.
       | 
       | Now that I am on the other end, I don't understand the need for
       | this overly complex and generally noncommittal (on the employer
       | side) process. If it's FAANG I am lucky if I can even get a
       | fucking job description these days. They want to interview me for
       | jobs I can't know about and best fit me for their needs. What
       | about my needs? What about my time? If I can't even get a job
       | description, why do you think I want to waste 3 hours doing
       | "homework" before I can even talk to anyone for more than 10
       | minutes about what possible job I could be actually doing for
       | you?
       | 
       | Hiring in Tech is broken and I don't know what we can do to fix
       | it.
        
         | bsder wrote:
         | > If it's FAANG
         | 
         | And that's really the issue.
         | 
         | The FAANG's are throwing around so much money that people are
         | willing to put up with almost any amount of abuse to be on the
         | other side of the line. The FAANGs can deal out any amount of
         | abuse and they will still have a line of applicants around the
         | block--there is no negative feedback in the interview process
         | no matter how bad they make it.
         | 
         | > Hiring in Tech is broken and I don't know what we can do to
         | fix it.
         | 
         |  _Software_ hiring in the _Valley_ is broken--possibly.
         | 
         | Hardware folks I know still go through the same old, same old.
         | Single phone call with an engineer to make sure you're not
         | simply a waste of oxygen. One on-site with 4-6 people (and 6
         | would be an unusually long day--generally that would mean
         | you're doing well and some extra people want to talk to you).
         | One week to response--two weeks _MAX_.
         | 
         | WTF are you software people _doing_?
        
           | m-ee wrote:
           | I've interviewed for ME, EE, FW, and SW roles. It's not
           | better in hardware. There's an equivalent to all the things
           | people are complaining about here. Take home coding challenge
           | -> take home hw design challenge where they expect you to
           | have access to expensive software. I got a FW challenge once
           | that assumed I had two different dev boards on hand. Spot the
           | bugs in this printed out code? Find everything wrong with
           | this schematic in 5 minutes. Now quick what's the transfer
           | function of this filter? I have a dozen more questions to get
           | through.
           | 
           | I had an ME friend who got into an argument with an
           | interviewer about the convection equation. The interviewer
           | was completely wrong, eventually my friend admitted "Ok I
           | literally have it pulled up on my screen right now, I think
           | you're mistaken."
        
             | bsder wrote:
             | > Spot the bugs in this printed out code? Find everything
             | wrong with this schematic in 5 minutes.
             | 
             | I don't consider those terribly unfair. Depending upon how
             | the discussion goes, I could see myself doing something
             | like this.
             | 
             | For example, one of my standard questions for firmware
             | people is a state machine in Verilog (for those who claim
             | to know Verilog). What I'm looking for is whether you know
             | the difference between blocking and non-blocking
             | assignment.
             | 
             | > Take home coding challenge -> take home hw design
             | challenge where they expect you to have access to expensive
             | software.
             | 
             | > I have a dozen more questions to get through.
             | 
             | These are not fine, though.
             | 
             | > The interviewer was completely wrong
             | 
             | This, sadly, happens. I have had an interviewer cite
             | incorrect information about semiconductor device physics.
             | 
             | Quite often, though, it happens in more junior interviewers
             | with "standard" questions that are passed around because
             | the interviewer doesn't fully grasp the question. When I
             | was a junior engineer, I was always _terrified_ that I
             | would make that screwup. I used to do review study on my
             | own questions and area before every interview to make sure
             | that didn 't happen.
             | 
             | For example, I had an interviewer who gave me a question of
             | "clock a binary number in serially and use a state machine
             | to divide it by 3." It's a really cool question and was
             | passed around between engineers of a certain company. But
             | ...
             | 
             | This is either a really easy question or a really hard
             | question depending upon your choice of direction to clock
             | the number in. If you pick the easy way, it's something
             | like 3 states and it's obvious. If you pick the hard way,
             | it's 6 states and takes a somewhat subtle inductive proof
             | to show that you're right. If the interviewer doesn't
             | _know_ that this can happen, he can 't dig the candidate
             | out if they pick the hard direction.
             | 
             | Of course, you know which direction I picked in the
             | interview. LOL.
        
           | devnull3 wrote:
           | > WTF are you software people doing?
           | 
           | I think it stems from the fact that software is "soft" i.e.
           | highly malleable and flexible. This improves time-to-market
           | considerably and there is an inherent expectation built-in to
           | "move"/"execute" quickly.
           | 
           | This also creates problems. Now the same thing can be done in
           | multiple ways. There is a "my-company" way of doing. There is
           | "my-way" of doing. Throw in personal tastes, likes-dislikes
           | for testing, syntax, editors to name a few. Over the time,
           | people take on multiple identities (e.g. FAANG, language
           | fraternities, clubs of certain technology, editor
           | fraternities etc). These mix and match in at best interesting
           | ways and at worst in toxic ways.
        
           | morpheos137 wrote:
           | Seems like software engineering too often attracts
           | personalities that like creating uncessary complexity. It is
           | deeply ingrained in the culture.
        
         | echelon wrote:
         | > If it's FAANG I am lucky if I can even get a fucking job
         | description these days. They want to interview me for jobs and
         | best fit me for their needs. What about my needs? What about my
         | time? If I can't even get a job description, why do you think I
         | want to waste 3 hours doing "homework" before I can even talk
         | to anyone for more than 10 minutes?
         | 
         | Why don't you find people working on a problem you like, then
         | ask them if they have open positions?
         | 
         | Working though engineers is almost always better than filtering
         | though company recruiters. You'll wind up with a role you like
         | rather than being stuffed into open head count.
         | 
         | I've done this. It works.
        
           | kxrm wrote:
           | > Why don't you find people working on a problem you like,
           | then ask them if they have open positions?
           | 
           | That's not always straight forward. Once you get patched over
           | to HR, it's their process.
           | 
           | I am glad to hear that this is still working for you,
           | hopefully a serendipitous moment will occur soon to open a
           | door for me as well.
           | 
           | > Working though engineers is almost always better than
           | filtering though company recruiters.
           | 
           | Doesn't this say something about hiring being broken when you
           | have to dig through profiles on a company website or linkedin
           | and cold contact devs to get your foot in the door?
           | 
           | I am by no means suggesting that what you are saying is a bad
           | idea, just that this reeks of poor and inefficient hiring
           | policies.
        
       | postit wrote:
       | That's not about selecting the most qualified, the extra "lunch",
       | "coffee", "working habits", "cultural fit" ..., it's a way found
       | by companies to involve the maximum number of people in the
       | hiring process to make people in the team feel confortable with
       | the new hire. It's a very expensive team bounding exercice.
        
       | sebyx07 wrote:
       | Just do interviews with at least 5 companies at the same time.
       | Pick the first which offers you the position, semi ghost
       | others(keep them for backup), profit and no hurt feelings.
        
       | martindbp wrote:
       | I'm starting to think these interviews are not about skill, but
       | about resiliency. It filters out people with (occasional)
       | physical/mental health issues, difficult/many kids or other
       | difficult life situations etc. Which is fair I suppose, companies
       | would prefer perfectly healthy 26 year-olds that can dedicate
       | their life to the company without burning out.
        
         | FinanceAnon wrote:
         | I think "resiliency" is a positive way of phrasing it. In my
         | opinion, it's more of a case of checking if you can fit in and
         | put up with corporate BS.
         | 
         | I also doubt that companies are on purpose designing the
         | interviews to be this long. It's probably more of the case of
         | "more is better" thinking and no one being able to make a
         | decision by themselves to streamline the process.
        
       | jack_riminton wrote:
       | Reading all the replies its still quite a surprise that more
       | engineers don't go and build their own products.
       | 
       | Building companies is hella risky and hard, but if you're a
       | senior engineer you could quite easily do it on the side
        
       | andrew_ wrote:
       | I recently agreed to go through a 5-round process which totaled
       | to about 6 hours. I'm the first person to bitch about the
       | ineffectiveness of leetcode/hackerrank bullshit for people with
       | 10+ of verifiable experience, but I went through this one because
       | it was a field I had never worked in before, and the personnel I
       | was speaking with were truly interesting.
       | 
       | Sans all of those qualifiers, anything more than 3 rounds is a
       | deal breaker for me. If you don't know if I'm the right fit after
       | 3 hours, verifiable experience, a public body of work, and a list
       | of references, then your company culture isn't a good fit for me.
        
         | echelon wrote:
         | Devil's advocate.
         | 
         | Every bad hire costs the company $50,000 - 200,000. Sometimes
         | more. They can also sink or demoralize teams.
         | 
         | Many of the people conducting interviews are new to the process
         | and don't know how to extract signal. Sometimes scales don't
         | line up.
         | 
         | When you have a revolving door of employees (because that's the
         | way things are these days), have trouble scheduling interviews
         | (busy engineers trying to get their own work done), and can't
         | get enough skilled interviewers on a panel, then of course the
         | process will be a suboptimal experience for candidates.
         | 
         | To a degree, companies would rather a good candidate was passed
         | over than a bad candidate was accepted. Type I and II errors.
         | 
         | Companies also don't like telling candidates how they did
         | because that opens them up to lawsuit liabilities.
         | 
         | You have to do enough interviews to get signal yet not piss off
         | candidates. (Or your employees in the interview pool!)
         | 
         | It's a hard problem for companies too.
        
           | vishnugupta wrote:
           | +1 to everything you said.
           | 
           | I'd like to add time aspect as well. If selected, candidate
           | will spend next 12-18 months with the team, 5 days a week. I
           | look at those 5-6 hrs as worth an upfront investment from
           | both the sides just ensure those days months aren't miserable
           | and you don't end up parting ways on bad terms.
           | 
           | I'm saying this as an interviewee as well as hiring manager
           | who has conducted more than a thousand interviews.
           | 
           | Nothing frustrates a team and hiring manager more than a
           | mishire. It's the same for candidate, they have to go through
           | the charade of interviewing at tens of places again.
        
           | Gauge_Irrahphe wrote:
           | When you have a revolving door of employees, the job sucks in
           | some way and people leave for places that suck less.
           | 
           | You have two ways to solve this problem:
           | 
           | 1. Figure out what makes your employees keep leaving.
           | 
           | 2. Hire people who are not good enough to work elsewhere.
        
           | _carbyau_ wrote:
           | "revolving door of employees (because that's the way things
           | are these days)"
           | 
           | 2 things that line hits me.
           | 
           | 1. Remuneration. If I can jump ship and come back later to
           | much more money, why not?
           | 
           | 2. I work to _make_ myself replaceable. This is what good
           | documentation, code comments, architecture is for!
        
             | tcmart14 wrote:
             | So what I get is, write shitty confusing code and don't
             | document it. Job security, got it!
        
           | MattGaiser wrote:
           | > because that's the way things are these days
           | 
           | Why is nothing done about this? As turnover soars and tenure
           | plummets, I am willing to buy that companies do not value
           | codebase knowledge, domain knowledge, or believe that it
           | takes time for an engineer to get going. I can buy them
           | seeing us engineers as replaceable widgets.
           | 
           | But we are at the point where a lot of companies cannot
           | replace us and yet nothing is done about the endless parade
           | out the door. The focus is entirely on shovelling new people
           | in.
        
             | creato wrote:
             | I think most engineers overestimate their irreplaceability.
             | If a company actually wants you to stay, they'll fight for
             | you. They just choose not to for >90% of engineers leaving.
             | 
             | Chances are, the new hire replacements will be in the same
             | 90%, so it is a wash (minus ramp-up time), but maybe the
             | company gets lucky and finds someone in the other 10%.
        
               | MattGaiser wrote:
               | I get them being replaceable, but there must be companies
               | would be getting to the point where there aren't
               | replacements, or at least not good ones as the demand for
               | engineers grows.
        
           | thayne wrote:
           | They least they could do is let you know up front what the
           | interview process is going to be like. From what I've seen
           | the candidate often has no idea if the second interview is
           | the final interview or just the next in a long series. And
           | I've even seen employers wait weeks befor calling back to
           | inform the candidate they qualify for a third interview.
           | 
           | And if you have a revolving door of workers, that suggests
           | something else is wrong. Maybe you should focus on retaining
           | existing workers rather than acquiring new ones.
        
           | MisterBastahrd wrote:
           | If someone is new to the interviewing process, then they
           | shouldn't be doing interviews alone. If they don't know how
           | to gather information from a resume, then they shouldn't be
           | reading resumes alone.
           | 
           | You say that a bad hire is worth tens of thousands of
           | dollars, but if that's the case, then most of what you said
           | is irrelevant because a company that is smart enough to
           | recognize this would be smart enough to never put a junior
           | manager in a situation to make a terrible decision.
        
             | echelon wrote:
             | > If they don't know how to gather information from a
             | resume, then they shouldn't be reading resumes alone.
             | 
             | You would be shocked how many people blatantly lie or
             | overstate their roles on resumes. Senior, junior, it
             | happens all over.
             | 
             | A good practice is to ask candidates to go in depth about
             | recent resume items and explain the technicals, business
             | needs, etc.
             | 
             | > If someone is new to the interviewing process, then they
             | shouldn't be doing interviews alone.
             | 
             | Most don't. But are you really calibrated after five
             | interviews? Ten? And what about all the other folks that
             | need to shadow / train?
        
               | MisterBastahrd wrote:
               | It's either important and expensive or it isn't. I
               | wouldn't be "shocked" by anything. I used to be a
               | recruiter. In my current dev position, I have absolutely
               | nuked candidates by asking basic questions that the
               | managers (who were eager to hire someone to fill a spot)
               | and other devs (who would feel uncomfortable if they
               | asked the question and hence didn't) failed to ask. A
               | candidate who will try to bullshit me about something he
               | doesn't actually know is someone who will waste time on
               | projects by not using all the resources available to him
               | to find the correct solution (this usually involves being
               | brave enough to ask questions if you don't understand
               | something). If my future depends on your success, then
               | I'm going to ask questions that will make me feel like I
               | can trust my future in your hands.
               | 
               | If a manager is getting paid $150K a year and it costs
               | $200K to fire a bad employee, then "when they're ready"
               | is the correct metric to use.
        
             | gentleman11 wrote:
             | So they can learn from experienced interviewers who just
             | make you leetcode and answer dumb stock questions (my
             | biggest weakness is...)? What we need is for people to
             | interview with zero experience and figure out a better way
             | on their own, not copy a bunch of bad processes out of
             | insecurity
        
               | MisterBastahrd wrote:
               | If you've surrounded yourself with incompetent people,
               | then you still shouldn't assume that everyone else is
               | equally incompetent. Cynicism isn't wisdom.
        
           | void_mint wrote:
           | Your response is the voice of the company. The person you're
           | responding to, and lots of candidates, don't really care
           | about the voice of the company. From a company's perspective,
           | sure waste all the time you want, you want to be _sure_. But
           | to candidates, getting dragged around sucks, and is usually a
           | waste
        
           | s5300 wrote:
           | The lower end of that, and honestly, the higher end, is just
           | about complete rounding error to any FAANGM+ caliber company.
           | 
           | I have seen a fairly small amount of employees hit the lower
           | end on a singular dining bill when they had a company card
           | and were meeting with business partners they were trying to
           | "impress"
           | 
           | (obviously, the joke is free nice food and drink for all
           | involved at the companies expense)
           | 
           | If you were fickle you could perhaps justify that as priced
           | in to keeping good relations... but in the same light I'd
           | call your figures priced into the talent acquisition process.
        
           | billytetrud wrote:
           | Yes, every bad hire is really bad. However, companies
           | generally don't put in any effort into seriously evaluating
           | your publicly available work. I have reams and reams of open
           | source code companies can take a look at, and I've never seen
           | any evidence that any company I've ever interviewed at has
           | looked at that work. That's a result of companies being
           | completely incompetent at evaluation and disrespecting their
           | candidates time. Its wasteful and stupid. Its honestly
           | flabbergasting how many companies don't put in the effort to
           | make their hiring process passible, much less anything near
           | "good".
        
             | cubano wrote:
             | Well the obvious issue here is...how do they truly know
             | _you_ wrote the code? Its pretty much impossible to source
             | where OS code comes from, and it sure wouldn 't be hard to
             | find an obscure OS project and pass off the code as yours,
             | if you were that sort of person.
             | 
             | And this takes me to my 2nd point, and that is they current
             | hiring model totally leads to companies hiring _people who
             | are good at interviewing_ not necessarily people who are
             | good at doing the work required. There is no doubt t that
             | interviewing for a job is a skill that can be learned and
             | improved upon, and lots of crappy programmers have learned
             | to be damn good at being I interviewed.
        
               | azemetre wrote:
               | If a person has a history of giving talks, writing books,
               | or creating content around code they've written there's
               | probably a high likely hood they are capable workers and
               | can code.
        
             | bfung wrote:
             | Being on the hiring end, it's less out of incompetence and
             | more of not enough time, and open source code is low signal
             | that the candidate can actually solve problems.
             | 
             | If I submit some "open source" code as some proof that I
             | can code, how do you know I didn't copy the code from
             | somewhere?
             | 
             | Also, writing code for the sake of writing code doesn't
             | tell a hiring manager if the person can take requirements
             | and translate that to an automated process. It just say
             | that person isn't that busy and can, excuse my language,
             | shit out code for the sake of appearing productive.
             | 
             | Writing code can be a hobby, sure, but that's only a small
             | part of a software job and no amount of open source code
             | can tell a company if the candidate can work with others
             | and solve problems.
        
               | code_duck wrote:
               | > Writing code can be a hobby, sure,
               | 
               | > writing code for the sake of writing code
               | 
               | > It just say that person isn't that busy and can, excuse
               | my language, shit out code for the sake of appearing
               | productive.
               | 
               | It sounds like you have a serious misunderstanding of
               | open source at a basic level. It would have been
               | questionable enough in 2000 but I'm not sure why anyone
               | in 2021 would think that way.
        
               | bfung wrote:
               | I'd argue the other way - open source in 2000s to central
               | libraries were of decent quality. The quantity of code
               | now these days is so much and of questionable quality -
               | everyone and their bootcamp writes code to GitHub and
               | call it open source, just to show they have open source.
               | 
               | Hell, I have public code on GitHub, but I'd never put it
               | on my resume.
        
               | code_duck wrote:
               | There may be a signal-to-noise problem, but the amount of
               | useful open source projects and the extent to which we
               | rely upon them has only increased in the past 20 years.
               | "Open source" includes projects like Go and NodeJS, which
               | are hardly trivial, disposable projects like you're
               | referring to. Pretty much all crypto is open source and
               | people have invested tens of billions in that ecosystem.
               | I could continue and list at least half a dozen projects
               | that are considered critical infrastructure which are
               | developed in that fashion.
        
               | tcmart14 wrote:
               | I agree on your open source comments as far as, the only
               | open sourced code a person has is personal pet projects.
               | However, if you see someone has PRs and commits into
               | something like the Linux repository or a major well known
               | project, then their open source contributions could be
               | very meaningful. As an example. If you are hiring for a
               | position for a developer to work on garage band at Apple,
               | if an applicant is an audio dev for FreeBSD, that is a
               | pretty good sign the candidate knows what they are doing.
        
               | bfung wrote:
               | Agree - it'd have to be some contribution to a
               | significant project. Those are radar and far in between.
               | 
               | Usually it's "I wrote some code and put it on GitHub,
               | call it open source".
        
               | buck4roo wrote:
               | > no amount of open source code can tell a company if the
               | candidate can work with others and solve problems.
               | 
               | Balderdash. When was the last time an interview task
               | involved working with others? I'd offer that open source
               | PRs show this way better, and in an appropriate context
               | (as a collaborator) rather than what we have now:
               | adversarial interview{er,ee}s.
        
               | billytetrud wrote:
               | > how do you know I didn't copy the code from somewhere?
               | 
               | You can ask your candidate to explain the code... Is that
               | not obvious?
               | 
               | > writing code for the sake of writing code doesn't tell
               | a hiring manager if the person can take requirements and
               | translate that to an automated process
               | 
               | Kind of sounds like you don't know what open source
               | software is.
               | 
               | > excuse my language, shit out code for the sake of
               | appearing productive
               | 
               | I won't excuse your language. You sound like you're part
               | of the problem buddy. I don't think you have any idea how
               | to evaluate a programmer.
        
               | bfung wrote:
               | > You can ask your candidate to explain the code... Is
               | that not obvious?
               | 
               | Asking about projects is the obvious thing, but only
               | substantial and interesting projects really provide any
               | interview value. Yet another Todo app doesn't fit that
               | criteria. Neither is another scaffolded crud app.
               | 
               | A PR to fix a bug in a semi-popular library is worth. But
               | saying "I have a lot of repos" is def not.
        
           | rgbrenner wrote:
           | This is mostly management speak for: _don 't blame us, we're
           | just incompetent_.
           | 
           | If you run a company and you have a "revolving door of
           | employees" (ie: we can't retain talent), your managers "are
           | new to the process" and don't know what they're looking for
           | (ie: we hire inexperienced managers), and you "can't get
           | enough skilled interviewers on a panel" (ie: "we don't hire
           | enough engineers and we're too cheap and shortsighted to put
           | them on tasks like hiring")... then yeah, you should expect
           | your hiring costs to go up, have a revolving door of
           | employees (because you don't know how to hire), and your
           | teams to be demoralized.
           | 
           | The consequences of that are your (company's) fault. You
           | should own up to your shortcomings and work on your hiring
           | process... don't just punish the candidates indefinitely so
           | that you can ignore your problems.
           | 
           | (I say this as a serial founder, and hopefully never need to
           | be on the other end of the hiring process.)
        
             | MattGaiser wrote:
             | Are there companies that don't have a revolving door?
             | Talent retention seems to be solidly tagged #wontfix.
        
               | [deleted]
        
         | stevekemp wrote:
         | It's interesting to hear of these experiences because my own
         | job applications have usually taken four steps:
         | 
         | * See the advert online, and send an email/fill out a form to
         | apply.
         | 
         | * Have a quick phone-chat with a HR-person, where they ask
         | about salary, history, and try to decide if I'm a chancer, or I
         | have some somewhat useful skills.
         | 
         | * Have a 30-60 minute interview with some technical people, in-
         | person.
         | 
         | * Optionally have a second interview with a tech-lead, or
         | somebody else higher up the chain.
         | 
         | * Receive offer, rejection, or get ghosted.
         | 
         | Smaller companies sometimes have different processes. More than
         | once I've sent an email/CV in to apply and been invited out for
         | beer/food, and received a verbal offer the following morning.
         | No other interviews, or tests.
        
           | ExitPlatosCave wrote:
           | Hey Steve,
           | 
           | Thought your comment was interesting, so went to check out
           | your profile.
           | 
           | That was also clean and well made, so followed through to
           | your website.
           | 
           | Found this: "I published a simple tool to all your repository
           | details from Github, self-hosted Github Enterprise
           | installations, and other compatible systems."
           | 
           | Do you mean: ...to [pull] all your repository details
           | 
           | Since you have such a nice profile and everything I thought
           | maybe you intended to include this word in there.
           | 
           | Hope this is helpful.
           | 
           | Somewhat related to interviewing and getting hired.
           | 
           | If it's in an appropriate comment for this threat then please
           | remove it. @admin
        
             | tome wrote:
             | Hey ExitPlatosCave,
             | 
             | Thought the beginning of your comment was interesting, so
             | went to check out the middle of your comment.
             | 
             | That was also clean and well written, so followed through
             | to the end.
             | 
             | Found this: "If it's in an appropriate comment for this
             | threat then please remove it."
             | 
             | Do you mean: If it's in an _in_ appropriate comment for
             | this threa _d_ then please remove it.
             | 
             | Since you have such a nice comment and everything I thought
             | maybe you intended not to make these typos.
             | 
             | Hope this is helpful.
        
             | stevekemp wrote:
             | A little off-topic, but appreciated regardless.
             | 
             | I'll fix the entry you mention - as you suspected a missing
             | word there.
        
           | robin_reala wrote:
           | Yes, same for me. I was going through my past interviews, and
           | the most I've had before an offer has been two, both
           | scheduled on the same day. And I've worked in agencies and
           | big orgs, in both private and public sector. Maybe we've just
           | been lucky?
        
           | ImaCake wrote:
           | I do research assistant work in biology. The best way to get
           | one of these rare jobs is to email the professor directly.
           | They then have a "chat" with you (don't be fooled, this is
           | the formal interview!) and then several weeks later they get
           | around to bypassing the Uni's hiring process and you get a
           | job.
           | 
           | I really am not looking forward to going through a formal
           | interview process, because it will be so jarring compared to
           | what I am used to!
        
             | stanford_labrat wrote:
             | Fwiw I also work in molecular biology and did a recent
             | round of interviews (summer 2020).
             | 
             | Started with applications over a web form on the university
             | careers website, then chatted over email with the hiring
             | manager. Eventually got set up with some interviews with
             | current lab people, and eventually the PI.
             | 
             | Mirrored in industry, although that was back in 2018. So
             | all in all the "regular" route at least for this level of
             | work in biotech/biology is pretty sane.
             | 
             | That being said, I've used your method in the past as well
             | to great success, and is one of my secret techniques to get
             | more traction when I'm looking ;)
        
         | Plasmoid wrote:
         | I wonder if this is a way to crowd out competitors. Take up so
         | much of a candidate's time that they can only interview at a
         | handful of places successfully. Either the candidate goes all
         | in on you or they pass without using your resources. Kinda the
         | grocery store shelving model of competition.
        
           | dkdbejwi383 wrote:
           | And it's to weed out people who value their own time and who
           | won't take part in pointless company mandated bullshit.
           | 
           | If someone sits though 6 hours of interviews and pointless
           | exercises that should instead be solved by consulting the
           | documentation, they will probably just do what they are told
           | without fuss, will work overtime for free and will let the
           | company walk all over them with regards to sick pay,
           | holidays, etc.
        
         | [deleted]
        
       | strenholme wrote:
       | I've interviewed with Google twice. It's not that many separate
       | rounds: You have the recruiter sell Google to you, then there are
       | two phone screens, then it's the all day interview (with multiple
       | people). Which is reasonable. I didn't get the Google job, but,
       | looking back, my life is better because I didn't relocate back to
       | Silicon Valley to work for Google.
       | 
       | I've never had a company string me along. Four separate phone
       | screens or interviews seems to be the limit. I've even been hired
       | after one video conference interview.
       | 
       | I once was given a "we want to hire you, but we need to get the
       | funds together before we can give you the offer" spiel during the
       | great post-mortgage economic recession, but they did hire me
       | after about a month.
       | 
       | After five separate rounds (again, talking to multiple teams on
       | the same day after one or two technical phone screens and one
       | recruiter call doesn't count; that's standard practice with many
       | companies), I would tell a company they need to either, as my
       | father put it, "shit or get off the pot".
       | 
       | In terms of take home assignments, I have no problem doing them,
       | as long as the employer has no problem having me put my answers
       | on a public GitHub repo. I will not do Codility tests, because my
       | experience is that employers who do those kinds of tests are
       | Unicorn hunters.
        
       | Clewza313 wrote:
       | I had fourteen (14) interviews at my current employer, with a
       | similar "how about this position instead?" switch in the middle,
       | including redoing a whiteboard coding interview.
       | 
       | I've been there 8 years and counting now, and my current job
       | bears virtually no resemblance to what I was hired to do.
        
       | chriski2021 wrote:
       | I run a company. When I need to hire someone it's because I need
       | someone to do something, and either do it now or really soon. I
       | have never had the time (or inclination) to do any more than two
       | interviews
        
       | paulmendoza wrote:
       | I have a small startup. We try to be super responsive when
       | someone applies to a job. Generally within 2 weeks of an resume
       | being submitted we can have an offer letter to the person.
        
       | rcarmo wrote:
       | I'm usually OK with doing more than three calls after a recruiter
       | call (which are ideally with a hiring manager, peer manager, and
       | a prospective peer), but that is usually because I quite like
       | getting a feel for company culture.
       | 
       | More than that is just silly and contrived (although I usually
       | end up talking to a VP or similar these days on account of my
       | seniority).
       | 
       | There are usually three major red flags that make me step away
       | (or at least curb my expectations):
       | 
       | - Any kind of automated coding test (I have a GitHub profile and
       | plenty of public code, plus HackerRank and the like can be gamed
       | if you have enough free time)
       | 
       | - Whiteboard or live coding interviews (I find contrived
       | discussions about algorithms stupid when I can reach into my
       | actual, physical bookshelf to a well thumbed-through copy of
       | Skiena, get a tested approach going and _then_ figure out how
       | best to optimize things)
       | 
       | - When I am asked for compensation on the very first interview. I
       | see it as culturally rude, and if they read through my CV at all
       | and have a target for the role they are interviewing me for they
       | should have already done the math.
       | 
       | But as I am edging towards 50, a lot of the above just doesn't
       | happen. Instead I have long, rambling conversations about company
       | values, people culture, and even end up doing free corporate
       | strategy consultations, in which I am obviously expected to utter
       | the right buzzwords that fit the interviewers' worldview.
       | 
       | I quite enjoy those conversations for the insights they provide
       | into how completely broken some companies are - instead of
       | getting down to brass tacks and discussing their challenges, many
       | startups end up coming across as cargo culting FAANG concepts
       | without addressing their actual pain points (how to grow, how to
       | retain employees, how to actually deliver product, etc.).
        
         | lixoaqui wrote:
         | regarding the last point, nowadays what I see is the opposite
         | where candidates still struggle with getting a clear salary
         | range before engaging into time wasting exercises.
        
         | vdomingos wrote:
         | Hear, Hear! For me it's when they put junior people doing
         | interviews to senior roles. I get the point - not enough
         | resources, culture check, etc - but at a certain level we're
         | not even talking the same language or even working experience.
         | 
         | On the other hand, any Amazon interview has tons of people :)
        
       | matoyce wrote:
       | But some are pulling strings like connections for them to get the
       | job that they want. It is quite rampant, and it even gives the
       | job to those who are not quite competent enough for that certain
       | position.
        
       | cudgy wrote:
       | "Google, for example, recently examined its past interview data
       | and determined that four interviews was enough to make a hiring
       | decision with 86% confidence, ..."
       | 
       | Does this mean that 14% of Google hires are incompetent for their
       | role at Google?
        
       | axaxs wrote:
       | My one and only Google interview went this way years ago. Each
       | round they'd send me more books to study, which frankly I
       | couldn't be bothered to read given the circumstances.
       | 
       | My experience ended when an interviewer in round 3 or 4 asked me
       | an obviously scripted question. I answered sarcastically, he got
       | peeved, and I never heard from them again.
       | 
       | I'm not claiming I'm Google caliber, whatever that means.
       | Obviously I'm not because I don't have the patience for their
       | interview questions.
       | 
       | To be clear, the entire question was: What's not in a Linux
       | inode?
       | 
       | My answer was: Lots of things...dinosaurs, the moon...
       | 
       | The interviewer told me very matter of factly that it was in
       | fact, the filename.
       | 
       | I honestly lost all respect for the process, sorry Googlers.
        
         | laurensr wrote:
         | A lot of people tend to forget that hiring, certainly in
         | software engineering, is a two-way process. The employer
         | assesses "is this a good candidate?"
         | 
         | But a clever candidate assesses "is this a good employer?".
         | Even during the hiring process.
        
           | drclau wrote:
           | There is asymmetry involved, tho. They judge you as a single
           | individual, while you have to judge an entire company from
           | your experience with one single interviewer. The company can
           | be employing thousands or even tens of thousands of
           | engineers. Also, you don't get to ask so many questions. The
           | time allotted to your questions is but a small portion of the
           | interview.
        
         | Faaak wrote:
         | I had a similar experience with Proton's recruitment. They sent
         | me a dumb IQ test with stupid questions like (how many
         | triangles are in this triangle). I answered with "Way too
         | many", and that was the end for me
        
         | izgzhen wrote:
         | There is no need to "respect" the process, but just to be more
         | thoughtful:
         | 
         | > What's not in a Linux inode? > My answer was: Lots of
         | things...dinosaurs, the moon...
         | 
         | You can answer that you want more clarification, or even answer
         | that "we can google this".
         | 
         | The "dinosaurs" thing might make the interviewer feel that you
         | are being unprofessional since the interview is to test one's
         | ability to perform in a professional environment. You don't
         | help your colleagues by answering in this way when asked
         | similar questions in work...
        
           | selcuka wrote:
           | While technically true, that's irrelevant here. The point is,
           | the answer was going to be wrong unless they said "filename"
           | anyway.
        
           | Scarblac wrote:
           | That kind of question is never asked in a work
           | situation,that's why it invites an absurd answer.
           | 
           | What _is_ in an inode, sure. Or _why_ is the filename not in
           | an inode. But what _isn 't_ in an inode is just a useless
           | trivia question.
        
           | nicky0 wrote:
           | To me the dinosaurs answer demonstrates a sharp mind, the
           | kind of person I would want to work with. Can you see why?
        
         | Nition wrote:
         | And yet if they ask you for an answer to a quirky question like
         | "why are manhole covers round?", they expect a clever answer
         | like "they can't fall in", rather than a pedestrian answer like
         | "well, probably they just started making them that shape for
         | some simple production reason, and then everyone else just
         | kinda of did the same thing because it worked."
        
           | emptyfile wrote:
           | What? Manhole covers aren't round. Silly americans.
           | 
           | http://lh4.ggpht.com/_LWPSf1_ugFI/TA4tx-22QRI/AAAAAAAAFx0/T1.
           | ..
        
             | [deleted]
        
             | Nition wrote:
             | And look at that, it's got a hinge on it, so it can't fall
             | in. _And_ it can 't be stolen or misplaced.
        
             | signal11 wrote:
             | Manhole covers come in a variety of shapes. A non-ironic
             | "why are manhole covers round" question speaks more to lack
             | of life and/or travel experience than anything else.
             | 
             | There are triangular[1] and even more exotic-shaped[2]
             | covers.
             | 
             | [1] https://www.reddit.com/r/mildlyinteresting/comments/g82
             | 6ve/m...
             | 
             | [2] https://manhole.co.il/doSearch.asp?tp=114
        
               | darkwater wrote:
               | > [2] https://manhole.co.il/doSearch.asp?tp=114
               | 
               | Holy crap, I never thought a website dedicated to
               | manholes pictures was a thing. I love the human species
               | :)
        
             | tssva wrote:
             | They aren't even all round in the US. Where I live there is
             | a high and rapidly growing number of data centers. In fact
             | there is currently another large data center campus being
             | built for the company famous for asking this question.
             | Among other things this means installation of fiber optic
             | cabling along the roads leading to the data centers. This
             | in turn means the installation of a large number of
             | manholes to service the cables. All the covers for these
             | manholes are rectangular.
        
           | whatshisface wrote:
           | Manhole covers are round because they minimize the
           | circumference per area that must be cut to make the cover
           | fall in.
        
             | vishnugupta wrote:
             | Obligatory
             | 
             | https://sellsbrothers.com/12395
        
               | bryanrasmussen wrote:
               | Ok but consider - is there any department at Microsoft
               | other than marketing that Richard Feynman would have been
               | suited for?
        
               | HWR_14 wrote:
               | Richard Feynman oversaw the IBM computer's use and
               | programming used in the Manhattan Project. Microsoft also
               | has an R&D department that would probably just give him a
               | budget and a team of assistants to see what he came up
               | with.
        
               | neilv wrote:
               | Feynman made significant contributions to supercomputing.
               | 
               | https://longnow.org/essays/richard-feynman-connection-
               | machin...
               | 
               | I'm guessing Feynman would've had a much better chance
               | getting hired at old Microsoft, than through the current
               | FAANG/wannabe interview process.
        
               | [deleted]
        
               | gcheong wrote:
               | I don't know but I shudder at the thought of what state
               | the world would have to be in for Feynman to be
               | interviewing at Microsoft or any FAANG company for that
               | matter.
        
             | paganel wrote:
             | In my area there are lots of square manhole covers. I have
             | it on my personal to-do list to photograph almost all the
             | older manhole covers from my city and geo-locate them at
             | some point, I think it could be a good indicator of how my
             | city grew and evolved ~100 years ago.
        
             | achow wrote:
             | Most probably, because manhole covers were/are made using
             | cast iron, which were sand casted.
             | 
             | Mold for sand casting is easily done in lathe (turning a
             | wood on lathe for precise shape is faster and more accurate
             | than sawing).
             | 
             | So as one of the parent comment mentions - it is round
             | because of production reasons.
        
               | eecc wrote:
               | My guess is it's also a matter of practical usage:
               | they're made of heavy iron and a round one will fall in
               | place whatever orientation it's thrown over the cover,
               | while a different shape needs to be carefully oriented. I
               | suspect this also means less broken fingers.
        
               | achow wrote:
               | But round one is easier to steal.. just roll them off.
               | Whereas a square or any such shape, would be very
               | inconvenient to move.
               | 
               | [Edit in response to a question]
               | 
               | Some people have attempted to steal manhole covers in
               | order to sell them for scrap metal. China Daily notes
               | that there has also been a problem with taxi drivers
               | removing manhole covers to "steal water and clean their
               | vehicles". https://www.bbc.com/news/blogs-news-from-
               | elsewhere-52400235
        
               | bluedino wrote:
               | Who steals iron to turn in for scrap? It's only worth
               | about 10 cents a lb. And then you have to haul it to the
               | scrap yard. It's heavy!
               | 
               | On the other hand, copper is $3/lb, brass $2/lb, aluminum
               | is $0.50/lb
        
               | pards wrote:
               | Read "Playing the Moldovans at Tennis". According to that
               | book, most of the manhole covers had been stolen for
               | scrap.
        
               | adrianN wrote:
               | Why would someone steal a manhole cover?
        
               | takeda wrote:
               | If Google is asking about them on an interview they must
               | be important.
        
               | rplnt wrote:
               | It's a very common thing to steal. Lots of iron. That's
               | why they use concrete-filled ones. That's why they are
               | stamped so a scrapyard can be checked (or alert
               | authorities).
        
               | xapata wrote:
               | To sell them at the scrap yard. Gotta be careful driving
               | in some countries; drive over an open manhole and you
               | might crack an axle.
        
               | xapata wrote:
               | If you're going around stealing covers, you're probably
               | driving a truck and carrying them in the truck bed.
        
               | varjag wrote:
               | Isn't as easy to shatter in handling too, lacking stress
               | concentrators.
        
               | discordance wrote:
               | ... fell for it like a dude trying to get his try at
               | opening a stuck jar lid.
        
               | PinballWizard wrote:
               | My take is because the manhole is round.
        
               | achow wrote:
               | The mouth of the 'hole' could be easily square, actually
               | making a square shape is perhaps easier - since laying
               | concrete is easier in straight lines.
               | 
               | So, _most probably_ the shape of the cast iron cover
               | (circular), drove the shape of mouth of the hole.
        
           | GistNoesis wrote:
           | It's just an invitation to discuss curves of constant width,
           | like the Reuleaux triangle, that has indeed been made into a
           | man-hole cover.
        
             | ivanche wrote:
             | Ah the famous Reuleaux triangle, something which 99% of
             | software developers around the world deal with every day!
        
             | cedilla wrote:
             | Lots of man-hole covers are rectangular though. Turns out
             | it isn't very important at all to have manhole covers that
             | don't fall in. They are quite heavy and don't roll around
             | on their own, so having them fall somewhere really is of
             | minor concern.
        
               | gowld wrote:
               | Hand-Rolling is a good reason to make them round.
        
               | GistNoesis wrote:
               | Yeah, but they don't sound as nice when you hit them with
               | the hammer (even when you make them of width/length
               | golden ratio so that they look nice).
               | 
               | The manhole cover question, is more of a check to test
               | whether the candidate belongs to the math-circle people
               | where this is well known.
               | 
               | Even if they don't it's then an opportunity to test if
               | the candidate can see the question behind the question.
               | 
               | With these sort of open-question in an interview context
               | you have to roll with it, otherwise it's seen as an
               | unwillingness to play (sphericon) ball.
        
           | RandallBrown wrote:
           | A bad interviewer might expect a certain answer but a good
           | interviewer will use it as an opportunity to examine the
           | interviewee's critical thinking skills.
           | 
           | Are there any other reasons the cover would be round? It
           | gives you an insight into their thought process as they come
           | up with more ideas and explanations.
        
           | bikson wrote:
           | I had same question, i was pissed because that was another
           | stiupid question. My answer was: Because its easier for ninja
           | turtles to jump on.
        
           | peoplefromibiza wrote:
           | > "why are manhole covers round?"
           | 
           | asked that question I would have answered: "that's a trick
           | question! they are not round!"
           | 
           | http://www.theromanpost.com/wp-
           | content/uploads/2019/11/cropp...
        
         | jcelerier wrote:
         | Isn't the question nonsensical ? inodes are a property of some
         | filesystems like ext, xfs..., that you can happen to use on
         | Linux. If you installed Linux, say, on an NTFS partition there
         | would be no inode anywhere, no ?
        
           | pjerem wrote:
           | I'd be curious if you already saw / read about a working
           | Linux installation on NTFS. IIRC, even WSL works with an EXT4
           | layer.
        
             | jcelerier wrote:
             | https://github.com/nikp123/ntfs-
             | rootfs/blob/master/guide_in_...
             | 
             | does not seem trivial given the differing permission model,
             | but not impossible either. for fat32 I wonder though if the
             | total absence of permissions allows for that.
        
               | rcxdude wrote:
               | There's a few things you'd need to patch up because a few
               | important utilities are picky about the permissions of
               | their config files (as a protection against
               | misconfiguration).
        
           | gpderetta wrote:
           | the inode vs filename distinction is historical unix behavior
           | (but I don't remember whether posix mandates it), and it is
           | quite important and relevant in many system programming
           | scenarios. Of course not all filesystems support it.
           | 
           | The question is still phrased terribly of course and the
           | candidate would have to reverse engineer what the interviewer
           | is actually asking to have a chance to answer it.
        
         | neilv wrote:
         | > the entire question was: What's not in a Linux inode?
         | 
         | Were they considering you as an experienced developer of a
         | Unix/Posix filesystem, who would almost certainly know what an
         | inode is?
         | 
         | Or were they considering you as someone who had been using a
         | Unix so long and extensively that you had a chance of once
         | having had to configure an older filesystem for huge numbers of
         | inodes. Or a chance that, for some rare reason, you once had
         | occasion to learn that the `ln` command isn't always used in
         | conjunction with `-s`?
         | 
         | In either of those cases, you might then guess at what the
         | question was getting at, in a slightly clever way. If you got
         | it, then both of you could share a bonding moment of both
         | knowing this thing not everyone knows, and it could be a quick
         | warmup to better questions.
         | 
         | Or, if you didn't get it, you could feel thrown off, and
         | insecure or negged, which is also a win for an evil interview
         | process.
         | 
         | If I'm feeling punchy at 3am, an alternative theory is that
         | they could be a recent CS grad, who'd had a class in which they
         | were told to recite, after the professor, "What's not in a
         | Linux inode is the filename," and that's what they think is
         | important about that. (By way of introducing the separation
         | between inode and directory entry in Unix, through catchphrase
         | and rote memorization. Other professors would probably instead
         | explain using a diagram or the code for structs.) (Theory
         | variation: perhaps the only professor who ever said this phrase
         | was at Standford, which would make calling for it an especially
         | transparent shibboleth for frat-like alumni affinity, and an
         | overly-precise filter for socioeconomic class.)
        
           | mrits wrote:
           | technically the filename can be in the inode. Just depends on
           | the filename.
        
           | danielmarkbruce wrote:
           | It was probably an opener for discussion. Assume the best
           | about the interviewer for a minute. What is the _best_
           | possible interpretation of where they wanted to go with the
           | question?
        
             | tonyedgecombe wrote:
             | But this was the third or fourth round. By then you might
             | expect a meaty discussion about file systems rather than a
             | trivia quiz.
        
               | danielmarkbruce wrote:
               | I'm not 100% certain of this, because I don't know what
               | job they ask a question like that for. It isn't a
               | software engineering interview. However, generally:
               | 
               | The rounds don't build on each other. You have X
               | interviews and the interviewers don't talk to each other
               | and are independent events.
               | 
               | They have gone through phases of having an initial phone
               | screen interview which is a hurdle, but the rest
               | are(/were) as laid out above. There may be exceptions for
               | very senior people, but they are sufficiently rare to
               | exclude.
               | 
               | Google has it's problems to be sure - but by and large
               | the individual people there mean well.
        
             | resonious wrote:
             | The fact that the interviewer didn't get the joke and
             | immediately divulged "the answer" makes it hard to assume
             | the best here. If they were really trying to open a
             | dialogue, I'd expect a chuckle and maybe some clarification
             | (like, what _is_ in an inode?)
        
           | tinco wrote:
           | I once cost my employer a bunch of valuable data due to a bug
           | in my code that the second I discovered the data was gone I
           | knew why it was gone because I understand inodes and their
           | relationship to filenames.
           | 
           | That's to say it's information that is useful to have in your
           | head if you're an SRE, just part of understanding Linux
           | fundamentals.
           | 
           | That's not to say it was a good question. Despite my
           | encounter with that bug in my code I still wouldn't have
           | answered the question correctly. Filenames point to inodes,
           | inodes point to data. The word filename might not even pop
           | into my brain when thinking of inodes in isolation.
           | 
           | Also it doesn't show the full picture, I'm not at all sure I
           | have what it takes to be an SRE let alone one at Google, that
           | I sort of know what an inode is says nothing about if I can
           | properly use that information to make architectural
           | decisions.
        
         | Taylor_OD wrote:
         | So... What does this comment have to do with the posted
         | article? In the article Google claims that 4 rounds is what
         | they see as the max to get a good hire/no hire signal.
        
         | nuker wrote:
         | Someone, please, write a book "Interview Questions: Linux".
         | Just questions and answers with short explainers. I got inode
         | question on every second interview! Make it good and expensive
         | af.
        
         | Arch-TK wrote:
         | >What's not in a Linux inode?
         | 
         | Wow, even if you were hiring filesystem experts to write
         | filesystems I think there are a million better ways to ask that
         | question.
         | 
         | e.g.: "Hey, talk me through the design of a really basic
         | filesystem, it needs to support hardlinks, symlinks, files and
         | directories."
        
           | pbhjpbhj wrote:
           | I'm not experienced in tech interviews nor knowledgeable
           | about inodes ... but your question and the interviewer's
           | question seem like they're functionally equivalent. They
           | presumably don't just want you to say "names", they're
           | expecting you to talk about what is in a Linux inode, what a
           | directory is, etc., and they can drop in further questions to
           | prompt you if you don't "talk me through the design of a
           | basic filesystem".
           | 
           | If the question is too vacuous surely you ask for
           | clarification -- "well, what happens when you issue the 'mv'
           | command" -- and presumably if you designed file systems you
           | can talk about different implementations, optimisations, and
           | problems crossing filesystem boundaries or whatever.
        
             | Arch-TK wrote:
             | I think there are multiple things wrong with the original
             | question:
             | 
             | - It's unclear what they're trying to judge. Do they want
             | to know if someone understands filesystems on an intimate
             | level? Do they want to know if someone knows how hardlinks
             | work? Do they want to know if someone knows what fstat
             | returns? Are they trying to trick someone since an inode in
             | many contexts is just a number? This is an unnecessary
             | level of uncertainty for a question and encourages random
             | tangents which may not be the answer the interviewer is
             | looking for or cares about.
             | 
             | - Someone who has studied google's standard questions which
             | this apparently may be one of [1] would be able to answer
             | this without understanding the implications, what does that
             | tell you about the candidate?
             | 
             | - If you want the candidate to go into a tangent about
             | filesystems in order to figure out how well they understand
             | them, this is as mentioned before a really stupidly open
             | ended question.
             | 
             | - If someone did understand you were talking about inodes,
             | they may be of the opinion that the inode contains a
             | reference to the file's contents and as such contains the
             | file contents. In the case of a directory this means that
             | an inode "contains" the file names of files in that
             | directory. This makes the question a leading question which
             | is trying to lead to what would be a wrong answer from that
             | person's point of view. How do you answer a leading
             | question when you disagree with what it's trying to lead
             | you to?
             | 
             | If you want to determine if someone understands filesystems
             | on an intimate level. I think my question would be far
             | better at elucidating that.
             | 
             | If you want to understand if someone knows how hardlinks
             | work, I can't come up with a question off the top of my
             | head but I doubt that "what is not in an inode" is anywhere
             | close to the best one.
             | 
             | If you want to trick someone, go ahead, this is a good
             | question. Likewise if you want to screen for people who
             | have googled "Google SRE Interview Questions" and memorised
             | the answers.
             | 
             | [1] http://www.gwan.com/blog/20160405.html (
             | https://news.ycombinator.com/item?id=12701272 )
             | 
             | Regarding the above reference:
             | 
             | I've spoken to someone who interviewed for an SRE position
             | and she said the questions were very similar to an early
             | phone interview she had. She said the interviewer did not
             | know what they were talking about and were just going off
             | an answer sheet. So I don't think the interview in this
             | case is representative of one for a Director of Engineering
             | but is representative of an early screening interview for
             | SRE. In which case anything BUT the expected answer to the
             | question "What is not in an inode" would be considered
             | incorrect.
        
         | beebmam wrote:
         | What an insane interview question. If someone asked me that
         | question I'd quickly end the interview.
         | 
         | A team looking for people with knowledge instead of looking for
         | people to know how to reason is a team that is already dead.
        
         | sz4kerto wrote:
         | I don't think this was scripted; it's a typical sign of bad
         | interviewers when they think that
         | 
         | 1) they are smart
         | 
         | 2) therefore if you're smart you have the same way of thinking
         | 
         | 3) also you have the same knowledge (and gaps!) about
         | irrelevant details
         | 
         | Therefore instead of checking your knowledge they check whether
         | you're like them.
         | 
         | It's just amateurish.
        
           | lrem wrote:
           | Nope, the inode question is part of the 50-ish long trivia
           | quiz that a sourcer uses to figure out if a candidate is
           | worth putting on the phone with an engineer.
        
           | janoc wrote:
           | It is also scripted. Google used to use internal people do to
           | the screening but not anymore, they have outsourced it to
           | agencies. And a random recruiting agency drone on the phone,
           | paid minimal wage, can't be expected to ask sensible
           | questions, so they get a script to choose questions from,
           | along with expected answers.
        
             | konschubert wrote:
             | I can't believe that Google would outsource their hiring
             | process, do they think they can keep their quality this
             | way?
        
               | randomdata wrote:
               | Have they kept their quality? Google does a few things
               | really well, but that drops off very quickly when you
               | look across their suite of offerings.
        
               | Tempest1981 wrote:
               | I doubt Google has outsourced their entire process.
               | 
               | But many recruiters work as independent contractors or in
               | recruiting firms. They often do a minimal phone-screen,
               | vs sending a candidate "cold" to the hiring company.
        
           | indigodaddy wrote:
           | This is pretty spot on
        
         | agumonkey wrote:
         | Happy to see that many recruiters have lost touch with
         | reality..
         | 
         | Is there a curated list of simpler, more human, more efficient
         | for both parties, companies ?
        
         | lbrito wrote:
         | Had a similar experience.
         | 
         | I was a recent grad, around 10 years ago. A Google recruiter
         | called me out of the blue. After a couple of minutes, she
         | started asking technical questions about Linux, which I had
         | just started using.
         | 
         | After a while came the final blow: I was asked what was the
         | fastest way to sum two integers (there were probably some
         | additional specs I don't recall).
         | 
         | I mumbled something. Wrong! The answer is, in fact, using the
         | TLB. I vaguely remembered what the TLB was from my CPU
         | architecture classes, but was aghast at the connection between
         | that and summing two integers.
         | 
         | The recruiter pretty much said I wasn't Google material on the
         | spot and said goodbye. I felt bad for myself at the time, but
         | now I can see this is a ridiculous approach to interviewing.
        
         | silon42 wrote:
         | I think this is not a bad question...
        
         | tyingq wrote:
         | That's a weirdly phrased question anyway. There's a directory
         | entries reference in the inode that leads to the filename. So
         | the name(s) isn't exactly "not in" an inode.
         | 
         | A lot of those interview questions just seem to test for "how
         | good is their memory", which I don't think correlates to future
         | performance very well.
        
           | ugjka wrote:
           | No, they just have to turn down 99% of candidates because it
           | will look bad for interviewers to have too many promising
           | ones
        
         | jd115 wrote:
         | I interviewed for a software engineering position with Goldman
         | once (in London). The process spanned several weeks of phone
         | interviews with people in the UK and US (I lost track of the
         | count), followed by a full day of back-to-back interviews on-
         | site with 12 different people - some via video conference with
         | New York. Questions were extremely diverse, both wide and deep.
         | Early on in the process I decided to look at this like a game
         | and try to actually have fun, which I did... I had fairly
         | positive feedback along the way so I thought I was doing well
         | ALL the way until the next-to-last interview with someone in
         | NYC on video link. I was sitting there in a room, waiting for
         | that next interview... the person on the other side was taking
         | longer than the others to show up. About 20 - 30 minutes into
         | my waiting, someone I had not seen before walked into the room
         | and informed me very matter of factly that we will not be
         | proceeding with the last interview and he will escort me on my
         | way out of the building.
         | 
         | To this day I have NO idea what happened. I never heard back
         | from them and the recruiter wasn't able to provide me with any
         | further feedback when I asked.
         | 
         | I thought maybe they saw me on camera taking a photo of the
         | Goldman-branded water bottle on the table while I was bored
         | waiting... Or someone was digging and saw an anti-Trump tweet
         | of mine. Or whatever.
         | 
         | Would have been more fun for me to turn them down after this
         | whole madness (which I fully intended), but I didn't get that
         | pleasure :)
        
           | jd115 wrote:
           | Hey! Did I just get some downvotes from Goldman junkies?
           | Ahahahaha That's adorable.
        
           | rwmj wrote:
           | I once had a weird interview at an investment bank for a
           | backroom sysadmin position. I went to the interview in a
           | smart cotton tennis shirt, black trousers, and was
           | interviewed by a bunch of techie people wearing pretty much
           | the same kind of clothes. The interview covered many
           | technical issues and seemed to go really well.
           | 
           | When I got out and was on my way home, the recruitment
           | consultant phoned me up and quite literally screamed at me
           | for about 5 minutes down the phone about why I hadn't worn a
           | suit. He didn't mention this interview requirement
           | beforehand.
           | 
           | So yeah, weird things happen at investment banks :-) I didn't
           | get the job obviously.
        
             | mcv wrote:
             | For one of my first job interviews I called to company
             | whether they wore suits. They said yes. I bought a suit and
             | got a haircut, and was interviewed by two techies in smudgy
             | polo and sweater. I felt way overdressed, didn't get hired,
             | and decided to never do this again. A neat button-down
             | shirt is plenty.
        
           | xvector wrote:
           | The software industry interview process is such a disaster.
           | The worst part of every job I've ever had (including FAANG)
           | is hitting the LeetCode grind when I want to leave. It's so
           | fucking _worthless._ Just a giant waste of time. This entire
           | fucking industry has its head up its ass.
           | 
           | I can't think of a single other high-paying profession that
           | pulls this shit.
        
             | devmacrile wrote:
             | Yeah the process always struck me as just as much a barrier
             | to exit as a barrier to entry (maybe even more so).
        
             | killtimeatwork wrote:
             | It's not that stupid from company's point of view - they're
             | preselecting for people who really want the job, and have
             | enough energy to pursue it. These are the people you want
             | to for your company.
        
               | xvector wrote:
               | Strange that this only seems to be necessary in the
               | software industry while literally every other industry
               | seems to be getting along fine without these dehumanizing
               | interview processes.
        
               | killtimeatwork wrote:
               | Software industry is also paying much more that most
               | other industries. Maybe it's special in some way?
        
               | __app_dev__ wrote:
               | I think to the fact that other "engineering" industries
               | do have licenses. There is no way legally they could get
               | away with these types of interviews.
               | 
               | I used to be a software developer and an architectural
               | firm (that designs buildings). The architects plus
               | engineers had to go through 5 years of college, do years
               | of on job training, all before they can be licensed.
               | 
               | I felt kind of bad for them though because I made more
               | then most of them before I was 21.
               | 
               | The interviews are crazy though. The last big company I
               | worked at had a "probation" period. For Sr Software
               | Engineers we would only do a single 1 hour interview. But
               | if they did not do well in the first 90 days we could
               | fire them.
               | 
               | Seems much better than telling people to study leetcode
               | hours per day for 2 months prior to an interview.
        
             | __app_dev__ wrote:
             | Totally agree! I've been getting hit up by FAANG recruiters
             | (and other companies) non-stop this year.
             | 
             | I live in Los Angeles where companies never did this type
             | of interview when I last got a new job (4+ years ago) so I
             | had to grind LeetCode for several months then didn't get
             | the job I studied for even though I got all questions right
             | (I was a little slow on some of them). I kind of resent it
             | because I know my time can be much better spent (keeping up
             | on security topics for example).
             | 
             | The process is so bad it makes me hope to be no longer
             | doing software development as a employee sooner than later.
        
           | oblio wrote:
           | Don't feel bad. It's entirely possible that they filled that
           | position somewhere along the way and some departments didn't
           | communicate to figure that out in time.
           | 
           | Or the position was cancelled during the interviews.
           | 
           | Not every reason has to be personal.
        
         | TheHypnotist wrote:
         | Amazon pulls something similar with their LP's. I spent more
         | time working with the recruiter and working GP's into my
         | stories/experience than I did actually interviewing. What an
         | incredible waste of time.
        
         | mancerayder wrote:
         | I skip any and all interviews that require math, algorithms, or
         | anything else. First of all, I'm an infra / devops engineer and
         | not a full-time software developer. Secondly, I've never used
         | this stuff.
         | 
         | And thirdly - because it's a proxy for intelligence by people
         | who think they're smart for having memorized sorting
         | algorithms.
         | 
         | Who wants to work in a place where people who memorize things
         | are conceived of as smarter than people who didn't memorize the
         | same thing at the same time interval (i.e. cramming before
         | interview or just out of college?)
         | 
         | Fuck those places, I'd rather work with human beings.
        
         | burntoutfire wrote:
         | Sounds like a failure of communication on both ends. The
         | interviewer should perhaps be more explicit in his question,
         | i.e. "What file metadata is not stored in its inode?". He
         | skipped the explicit part, since it probably seemed obvious for
         | him. The failure of communication on your end was not picking
         | up the obvious context of the question.
        
         | chovybizzass wrote:
         | I was asked if I was the size of a dime how would I get out of
         | a blender. I was like "Honestly, what does this have to do with
         | the Frontend role?"
        
         | naruvimama wrote:
         | While I have never interviewed with Google, my experience with
         | other companies is that.
         | 
         | 1. With senior or experienced developer, it is usually pleasant
         | and respectful and they are open to a diverging answer if it is
         | justified.
         | 
         | 2. Some of these companies either have an inexperienced person
         | in a senior position or delegate it to an inexperienced
         | developer to do the initial filtering.
         | 
         | 3. Inexperienced people are extremely painful to interview
         | with, they have "accomplished" something in their
         | current/previous job but do not realise there are better ways
         | than that. Sometimes it might just be an opportunity to
         | reinforce their own confidence (imposter syndrome).
        
         | pinewurst wrote:
         | I remember getting one like that - Googler demanded some random
         | value from a system .h file. Easy enough to grep if necessary,
         | but _no_ it had to be from memory to make one Googley.
        
           | wyclif wrote:
           | Google interviewers must hate Einstein. He said, "Never
           | memorize something that you can look up."
        
             | Akronymus wrote:
             | If you need to look up something enough times, it'll stick
             | anyways. But still, don't go out of your way to memorize
             | something.
        
               | sumtechguy wrote:
               | That one of my rules I always give to junior devs. Just
               | read the docs again for what you are doing. You may
               | perfectly 'know' them but sometimes there is an extra 'oh
               | if you are doing this do this other thing too'. Or worse
               | the call is _similar_ to some other call but does
               | something slightly weird. Does not come up often but has
               | caught me out a few times. Never hurts to re-read it. You
               | mostly can get away with it but sometimes...
               | 
               | A more human anecdote for example I have movies I know I
               | have seen dozens of times. Yet my recall of what happened
               | in them is not as good as it used to be as the last time
               | I watched them was a few years ago.
        
           | whatshisface wrote:
           | If the meta-interview system has even a modicum of sanity in
           | its design, that question will be discounted when none of the
           | candidates get it.
        
         | peakaboo wrote:
         | It's so stupid, all of it. They try to come up with random
         | questions that doesn't mean anything if the candidate remembers
         | the answer at that point in time.
         | 
         | I've read about Linux inodes. I know what they do. In fact I
         | even have had Linux systems where I get inode related error
         | messages because the partition had too many small files on it.
         | 
         | But given that question, in that situation, I would likely not
         | know what they even meant with that question. Am i supposed to
         | have all the inode details memoried forever in my mind? It's
         | fucking ridiculous.
        
           | corpMaverick wrote:
           | If I remember correctly the name of the file is not in the
           | inode. That allows you to have a file with different names.
           | (links)
        
           | [deleted]
        
           | laumars wrote:
           | I've written a few Linux file systems and I'm not even sure
           | I'd have answered that question correctly.
           | 
           | I've also failed job interviews where I was told there was no
           | coding expected in the face to face and then got given a
           | piece of paper and asked to solve 3 theoretical problems in
           | SQL on paper while 3 interviewers watched. 10 years prior I'd
           | worked for several years on Oracle middleware so I knew SQL
           | inside and and out but I still lost my nerve at that
           | interview and was told I wasn't experienced enough.
           | 
           | There was another telephone interview where I was asked all
           | sorts of command line questions, the problem there is they
           | spelt out the command line flags differently to how I
           | normally talk and read then (eg "what's see hatech em ohh Dee
           | seven hundred and seventy seven", had i seen it written down
           | I'd have been like "oh you mean see hatech mod seven seven
           | seven" (chmod 777) but they way they read it out sounded
           | cryptic has hell.
           | 
           | So there's a valuable lesson I've learned for interviewing:
           | putting pressure on interviewees is just as likely to filter
           | out good candidates as it is bad ones. So you're better off
           | making them comfortable during the process. Good but nervous
           | candidates will perform better. The interviewing process
           | shouldn't be about who can hold their nerve the longest.
        
             | jack_riminton wrote:
             | Seems like in these cases bad interviewers are a great
             | opportunity to glimpse into bad companies
             | 
             | A frustrating way to find out though
        
             | perryizgr8 wrote:
             | > hatech
             | 
             | I've never heard 'h' pronounced like that.
        
               | arthurcolle wrote:
               | hay'tch
        
               | TeMPOraL wrote:
               | There are moments in life when I wish everyone was forced
               | to learn NATO phonetic alphabet early in school.
               | 
               | "Charlie Hotel Mike Oscar Delta Seven Seven Seven".
               | 
               | The reason to cram into people a standard spelling
               | alphabet is that it minimizes confusion over the usual
               | "see as in $random-first-name". The reason to standardize
               | on the NATO one is that it's already an international
               | standard, and a subset of the population that goes to
               | work with anything resembling a radio transceiver will
               | have to learn it anyway.
        
               | laumars wrote:
               | It wouldn't have helped in the interview if they did use
               | the NATO phonetic alphabet because when you read CLI
               | commands or talk about them in the office, you don't
               | spell it out using the NATO alphabet.
               | 
               | The point was the interviewer read a written command
               | differently to how I'd typically hear it. It's a little
               | like the S-Q-L vs Sequal debate and how that can
               | sometimes throw people.
        
             | [deleted]
        
           | throwaway09223 wrote:
           | In terms of topical content it's a good question. The idea
           | that the name is a link stored in a directory entry is a key
           | part of filesystem architecture and anyone familiar with unix
           | filesystems should be able to immediately talk about why.
           | 
           | The problem here is that what could be an invitation to
           | showcase knowledge is reduced to a vague, one-dimensional and
           | non-obvious trivia question. There are a _ton_ of valid
           | answers to this question, like:
           | 
           | * The file data
           | 
           | * Extended attributes (ACLs, etc)
           | 
           | The topic is fine, but the framing of the question is
           | terrible.
           | 
           | If I wanted to test a candidate's knowledge in this area I
           | would probably ask: " _Why_ isn 't the filename stored in the
           | inode?" -- this initiates an architectural discussion, rather
           | than a poorly designed guessing game.
           | 
           | Guessing games in general are a red flag for the employer.
           | They tend to indicate the interviewer isn't competent freely
           | discussing the subjects at hand.
        
             | mike_hock wrote:
             | > They tend to indicate the interviewer isn't competent
             | freely discussing the subjects at hand.
             | 
             | Ding ding ding.
             | 
             | Even the question, as asked, was OK. The interaction with
             | the interviewee wasn't.
             | 
             | OP's joke was clearly just asking the interviewer to be
             | more specific. Instead of exploring the question with the
             | interviewee (e.g. "well, can you think of something that
             | one might naively assume to be in the inode, but that is
             | not"), they get pissed? lolwat?
        
             | snuxoll wrote:
             | > * The file data
             | 
             | Except on some filesystems really small files can actually
             | be stored directly within the inode, so even that's not
             | always true.
        
               | throwaway09223 wrote:
               | Yes and that's true of ACLs as well which I think
               | underscores my point: Questions should be an opener to
               | dialogue. A topic, not a conclusion.
               | 
               | Discussion of these whys and hows and whens is the most
               | valuable part of an interview and will more accurately
               | illustrate depth and breadth than any number of fixed
               | questions.
        
             | atoav wrote:
             | If your question has that "gotcha there is just one right
             | answer"-feel to it, you are doing it wrong.
             | 
             | I had a teacher once who constantly asked questions like
             | these in such an imprecise fashion there was _no way_
             | anybody could have guessed how the question was even meant
             | to be answered. I still cringe when I think about it,
             | because the only purpose of these questions was to show us
             | that he is really clever and we don 't know shit -- and it
             | didn't work at all.
        
               | throwaway09223 wrote:
               | Yes, absolutely.
               | 
               | Personally, I have always approached interviews as an
               | opportunity to either teach or learn. I pick a subject
               | and drill down until either the interviewee reaches their
               | limit of knowledge, or I do. Why is it like that? How
               | does that work?
               | 
               | Then, we have a discussion. One (or both) of us is
               | learning and we work out the whys and hows together. If
               | I'm the one learning, and I hope that I am, I fact check
               | the discussion after the interview. If not, I get a
               | strong indicator not just for the technical level of the
               | candidate but also how they operate at the edge of their
               | comfort zone. I've found this can be a strong predictor
               | of future growth.
        
         | pjmlp wrote:
         | After failing two Google interviews both triggered by being
         | reached directly by Google HR, telling me how my public
         | information and CV was impressive and I should be really at
         | Google, I told them to never ever contact me again.
         | 
         | My feedback was that, if the CV is so impressive, according to
         | them, why do I have to endure such interview processes?
         | 
         | Anyway I never bought into the whole do no evil marketing, nor
         | bothered to apply, if it wasn't for their HR reaching out to me
         | in first place.
        
           | coldpie wrote:
           | I had the same experience, some internal recruiter reaching
           | out that they were super impressed and wanted me for some
           | special group, then a phone call where they never bothered to
           | show up(!) so we rescheduled, then some stupid interview
           | where they asked me to estimate the value of 2^10 or
           | something and then told me they didn't want me for the
           | special group after all. Complete waste of time, especially
           | given I didn't really even want the job, they reached out to
           | me. Taught me a lesson, at least: I'll never work at a big
           | company, no salary is worth that kind of treatment of other
           | people.
        
         | mihaaly wrote:
         | Most processes are flawed I found, in most companies,
         | especially bigger ones. They try to come up so arbitrary
         | methods to differentiate between candidates that it has little
         | to do about the position in subject, a persons ability to
         | fulfill that position successfully throughout a prolonged
         | period. What they test if one candidate is better answering a
         | specific question or not. Some random question - usually
         | relevant to the subject. Impossible to cover all the knowledge
         | is necessary for that position, especially the adaptability,
         | capacity to learn (essential), accuracy, work ethics, all much
         | more important than if a specific fact is readily available in
         | the head of the candidate. Testing how good someone is in
         | tests. Or if the candidate can perform well while people are
         | watching and judging (very rare circumstance during the
         | workdays, except for actors or performing artists).
         | 
         | Based on perhaps a dozen intervies here and there I had the
         | conclusion that recruiters have no idea who they are going to
         | employ but practically draw a name from a hat (after filtering
         | out obvious incompetents, if at all). This includes the
         | position I won, and those I did not.
         | 
         | In one occasion I refused a fairly well paid and interesting
         | job because they tried to measure my competence by performing
         | quick basic calculations (related to financial topics), giving
         | impossible amount and urging as many answers as possible. Being
         | an engineering development position it was hopelessly
         | incompetent way to test, which they intended to be the base of
         | future promotions and assignments of roles too. They claimed it
         | is for the sake of fairness, testing every employee equally,
         | regardless of the role. How supid is this for god's sake?!
         | Roles and expectations of the roles are different and cannot be
         | tested the same way. It was just lazyness from the HR, pure
         | lazyness to rely on robotic methods. Robots from the HR (ironic
         | calling themselves !human! resources) pushed through
         | incompetent methods. Destroying fairness under the flag of
         | fairness, crazy. I considered better not be engaged with such
         | an organization.
        
         | neycoda wrote:
         | Why did the Google interviewer need their potential recruit to
         | know what wasn't in a Linux inode? Was knowing that part of the
         | job? That seems so esoteric.
        
         | peoplefromibiza wrote:
         | > The interviewer told me very matter of factly that it was in
         | fact, the filename.
         | 
         | which is not even true in some file systems that can inline
         | data directly into the inode, if the data is small enough.
         | 
         | for the downvoter(s):
         | 
         | > _If the data of a file fits in the space allocated for
         | pointers to the data, this space can conveniently be used. For
         | example, ext2 and its successors store the data of symlinks
         | (typically file names) in this way if the data is no more than
         | 60 bytes ( "fast symbolic links")_
         | 
         | > _Ext4 has a file system option called inline_data that allows
         | ext4 to perform inlining if enabled during file system
         | creation. Because an inode 's size is limited, this only works
         | for very small files_
        
           | gowld wrote:
           | I've never seen " _the_ file name " used to describe "name of
           | a symlink".
        
           | marcosdumay wrote:
           | > the data of symlinks (typically file names)
           | 
           | This means the name of the file the symlink points to. It's
           | not the file name of the symlink itself.
        
             | peoplefromibiza wrote:
             | true
             | 
             | but they are both paths in the end
        
         | danielmarkbruce wrote:
         | You have to understand the context of the interviewers. The
         | person may not have really cared. They probably weren't
         | interviewing for their own team. They may have their head in
         | the middle of some problem they are thinking about.
         | 
         | Google is hiring 10's of thousands of engineers a year. It's
         | really hard to do well. Most of the questions are deliberately
         | scripted because they are known to be good questions on some
         | dimension.
         | 
         | So... work with them. Most of them actually want you to do
         | well. Most of them are smart. Some of the questions are an open
         | invitation to just _talk_ and show that you can behave like
         | someone they 'd want to work with.
         | 
         | Your answer of "dinosaurs" etc, while the result of frustration
         | more than anything, just said to the interviewer "not someone i
         | want to work with".
         | 
         | It sucks, but you have to know your audience.
        
           | tragomaskhalos wrote:
           | In which case they should have teams dedicated purely to
           | technical interviewing, with members regularly rotated in and
           | out to keep them fresh.
           | 
           | When I did technical interviewing for my company for a
           | period, granted it was still on top of my 'day job ' but I
           | had the scope to get really invested in the process, and
           | wrote guidelines for other reviewers. Treat technical
           | interviewing as a respected role in its own right and not as
           | a chore that interferes with 'real' work and it's a better
           | outcome for all parties
        
             | danielmarkbruce wrote:
             | That might well be a good idea. I can imagine downsides to
             | it, but it might work.
             | 
             | The long and short of it is though - one has to face the
             | reality of the situation they are in. If you go interview
             | at Google (or any FAANG I would guess), you have to
             | understand what you are in for and do your best to get
             | through. Or, just don't interview there.
        
               | mLuby wrote:
               | One company I interviewed at in late 2019 referred me to
               | an interviewing-as-a-service. I forget the name, but the
               | gist was that this service hired and interview-trained
               | software engineers (at least part-time, maybe full-time)
               | who then conducted interviews and provided feedback to
               | the companies purchasing the interview-as-a-service.
               | 
               | From my perspective as a candidate, it was fine (the
               | interviewer was friendly and asked industry-standard
               | questions) but I do wonder how it goes for companies that
               | essentially outsource their hiring bar.
               | 
               | On the other hand, you'd need to be doing a lot of hiring
               | to make it worth dedicating a software engineer to just
               | interviewing people. Or you have someone who doesn't
               | really understand code--like a recruiter--run the
               | interview, with all the difficulties that creates.
               | 
               | TL;DR: hiring still isn't a solved problem.
        
               | danielmarkbruce wrote:
               | Yup, totally. It seems unsolvable.
        
         | janoc wrote:
         | Google is notorious for this.
         | 
         | I have been headhunted by them multiple times in the past. The
         | last time their recruiter called me and explained me that after
         | the usual screening and HR calls I would need to pass multiple
         | increasingly complex technical interview rounds - and then THEY
         | will decide on the role and project I am best suited for (if at
         | all). I have flatly asked the guy whether they are being
         | serious and turned him down.
         | 
         | To be fair to Google, though - their interviewing used to be
         | first class. When I got into the first call sometime in the
         | early 2000 or so, the interviews were difficult but with
         | competent interviewers and no BS scripted questions. But that
         | was because it was done in-house, I was talking directly to
         | some engineer in Palo Alto over the phone. Even the HR lady was
         | actually pretty technical and was asking me rather pointed
         | questions.
         | 
         | Later on they outsourced it to HR agencies and it became "the
         | process", with people being called over irrelevant/not
         | interesting jobs (entry level sysadmin in Ireland once - even
         | the HR guy on the phone recognized it makes no sense to call me
         | over it ...) and the "we decide ..." at last.
         | 
         | However, Google is by far not the only company doing it.
         | Microsoft's hiring process was very similar and Google's
         | explicitly inspired many smaller companies or "less desirable"
         | (for the candidates at the time) companies to ape this,
         | thinking it is somehow a good idea.
         | 
         | This seems to be pretty much the norm in the tech industry.
         | Along with attempts to effectively have the candidate redo all
         | comp-sci final exams during the interviews - because
         | "credentials can't be trusted", as someone told me.
         | 
         | Give me a break. It is high time tech companies should start
         | treat (especially experienced) engineers with a bit of respect
         | and dignity, we are not school kids anymore.
        
           | TeMPOraL wrote:
           | > _even the HR guy on the phone recognized it makes no sense
           | to call me over it ..._
           | 
           | Well, he had a quota to fill so -\\_(tsu)_/-.
           | 
           | There are situations where the market can be spectacularly
           | efficient. Outsourcing hiring to third parties is definitely
           | not one of them.
           | 
           | In this case, big companies can afford broken interview
           | process, because it's not _their_ time that 's being wasted,
           | and the inertia of a big corporation can hide a lot of
           | inefficiency.
        
             | crisper78 wrote:
             | facebook had me as someone who could fill their quota for
             | 1st rounds etc I sent an email asking them not to do this
             | twice now. It is quite funny though, because every time I
             | bring up NYC being the only possible location for me, the
             | recruiter usually grumbles says its "tough to get into NYC"
             | and then usually I get that the engineering manager
             | "doesn't like that many people" I wonder how many people
             | have been rejected working for Facebook because one person
             | in NY doesn't like them? I mean that person might be
             | amazing, but still seems limiting. They do fine anyway
             | though, most of the hard parts have already been done long
             | ago at Facebook I would suppose.....
        
           | 2OEH8eoCRo0 wrote:
           | >credentials can't be trusted
           | 
           | As much as I dislike interviewing I totally agree with this
           | statement. Almost none of my graduating classmates could
           | write a fizz buzz and I wish I were kidding.
        
         | cmrdporcupine wrote:
         | FWIW I've been at Google for a decade and I have done interview
         | training twice and each time opted not to do interviews,
         | because I think the interview process is terrible.
        
         | yobbo wrote:
         | The interview-process is a way for engineers (who might feel
         | underappreciated or insecure) to demonstrate how rare they are,
         | by asking questions no one seems to get right.
         | 
         | At one point, why not just drop the pretence and ask "repeat
         | back to me the algorithm on p. 343 in book xyz."
        
         | gretch wrote:
         | As someone who works at google, that guy has a stick up his
         | butt. Sorry for your experience.
        
         | maharajatever wrote:
         | That's nerds for you - making sure any kind of personality is
         | kept well away...
        
         | torginus wrote:
         | It's cruel and inhuman, but if you're Google, there's some cold
         | rationality behind this. I think the process goes for them like
         | this: There's 100 people applying for any given position, 10 of
         | which might be good hires. It's reasonable from their point of
         | view to subject the interviewees to a process that culls 83 bad
         | ones, and 7 good ones so that only 10 people need to be
         | interviewed by expensive on-staff engineers, even though it
         | looks like madness from the outside.
        
           | xvector wrote:
           | It's definitely questionable whether the process retains many
           | good engineers. That said, I suppose it works as long as it
           | culls more bad engineers than good engineers.
        
             | baobabKoodaa wrote:
             | > I suppose it works as long as it culls more bad engineers
             | than good engineers.
             | 
             | That's a pretty low bar. A Fizzbuzz test culls more bad
             | engineers than good ones.
        
           | thrwyoilarticle wrote:
           | The rationality doesn't reflect the reality of Google being
           | unable to innovate and continually competing with itself.
           | Will another engineer from the same cohort who knows the same
           | trivia and has the same education be able to shake things up?
           | 
           | What happens to the 3 that get rejected, do they try again
           | later and filter through? Or do they tire of the process,
           | give up, and work for competitors?
        
             | jack_riminton wrote:
             | When you're in such a dominant position they don't care
             | about people being able to shake things up
        
               | thrwyoilarticle wrote:
               | Neither did IBM, GE, Oracle.
        
             | konschubert wrote:
             | Have you seen their earnings, they're in a monopoly
             | position, none of this matters any more.
        
         | incrudible wrote:
         | Their process may simply be optimized for their particular
         | purposes. Google doesn't _need_ more engineers, but there 's a
         | certain kind of hire they don't want to pass up on. No company
         | really needs a genius rockstar coder that's going to quit after
         | two years to become competition. That's why the inode question
         | makes sense. It's a stupid question that deserves a stupid
         | answer. If you're the kind of person that actually gives the
         | stupid answer, you're clearly not a cultural fit. Google is
         | looking for the person that disregards the stupidity of it, who
         | has prepared themselves and gives the "expected" answer.
        
           | sdevonoes wrote:
           | Google wants soldiers, and they can get them.
        
         | ladberg wrote:
         | I had a similarly bad Google experience that I've talked about
         | before[0] but will copy here:
         | 
         | I was asked to do a task that eventually boiled down to a
         | topological sort, and I thought the question consisted of
         | recognizing that the answer was a topological sort and moving
         | on because it was over the phone.
         | 
         | However, that was not the case. The interviewer wanted me to
         | code it all out over Google Docs, but I didn't remember the
         | exact algorithm so I basically had to re-figure it out on the
         | fly, which took most of the interview (I even similarly mention
         | "in any real situation I would just look this up", but that
         | didn't help). At the end, I had a bunch of pseudo-C++-code that
         | should do it correctly.
         | 
         | I thought I was done, then the interviewer said she would go go
         | copy my code and compile it after the interview to see if I was
         | right, which blew my mind. It was never mentioned previously
         | that the code would actually be compiled and run, and with no
         | syntax highlighting or ability to compile and test the code
         | myself there is zero chance it was ever going to work.
         | 
         | I never heard back, so I'm assuming my code failed and they
         | left it at that. Anyway, I'm much happier now that I think I
         | would have been at Google.
         | 
         | [0] https://news.ycombinator.com/item?id=23848556
        
           | throwawayboise wrote:
           | I've never written a sort from scratch since my college days,
           | over 30 years ago. Also never had a job interview that asked
           | me do to so, or any other coding questions. I'm planning more
           | for retirement than a next job at this point, but I shake my
           | head at what my younger colleagues need to go through these
           | days for the opportunity to write JavaScript with IDEs that
           | do most of the work for you.
        
             | Demonsult wrote:
             | I happened to have, by chance, practiced writing sort from
             | scratch right before an interview where they asked me to do
             | just that. Doing it correctly in just a few minutes gave me
             | pretty high status. Higher than I deserve. The randomness
             | cuts both ways.
        
             | Consultant32452 wrote:
             | I had one interview where they asked me to write out some
             | fairly complex SQL joins on a white board. This was for a
             | Java dev gig, NOT a SQL admin gig. I decided to really lean
             | into how awful it was by putting in notations for three
             | different implementations (Oracle, MSSQ, and Postgres). I
             | was subtly making fun of them but they didn't pick up on
             | it.
             | 
             | I got the offer and took it because I do contracting and
             | had just unexpectedly gotten a contract canceled early, so
             | I was unemployed and have a family. At the end of the 3
             | month contract they offered me a full time position and I
             | declined.
        
               | throwawayboise wrote:
               | SQL I can do in my sleep. Still haven't ever needed to
               | write sorts (other than ORDERY BY).
        
             | alxlaz wrote:
             | Not all younger developers have to jump through those
             | hoops. There are plenty of companies that don't do that
             | kind of nonsense, because they're trying to hire good
             | engineers, rather than, specifically, engineers -- good or
             | bad, that'll get sorted out later -- who will happily
             | sacrifice their spare time to figure out how to jump
             | through the arbitrary hoops that their jobs entail.
             | 
             | Holding this kind of bullshit interview isn't a bad idea if
             | you're a megacorp with chaotic teams and fourteen levels of
             | management hierarchy where people spend most of their time
             | on infighting and career building. You _need_ people who
             | jump through hoops, because successfully delivering most
             | projects in these environments is 10% difficult technical
             | work (which the good engineers can handle, and you can
             | typically hire enough of them via recommendations), 40%
             | YAML-poking bullshit work, and -- optimistically -- 50%
             | jumping through all sorts of technical and non-technical
             | hoops, most of them self-inflicted.
             | 
             | I navigated this kind of process successfully early in my
             | career, and the only thing that made me more miserable than
             | interviews like these was the work I got to do afterwards,
             | after accepting the offers. Once is happenstance, twice is
             | coincidence, three times is probably just how these things
             | are -- I'm now pretty convinced that the quality of the
             | interview is (barring statistical accidents) highly
             | correlated with the quality of the actual position.
        
             | nicoburns wrote:
             | > I've never written a sort from scratch since my college
             | days, over 30 years ago
             | 
             | I didn't study CS at college, and I've never needed to
             | write a sort on the job, so I've only ever written sorts in
             | job interviews! I think I worked out a basic bubble sort,
             | and told them it probably wasn't the fastest way of doing
             | it but that it'd do the job.
        
             | simias wrote:
             | I sometimes have to implement a sorting algorithm when I
             | write bare metal code that doesn't have any sort of
             | standard library available. Of course, being a 1337 hacker,
             | I then resort to the state of the art bubble sort. Or maybe
             | an insertion sort if I'm feeling fancy. But enough
             | bragging.
        
               | jt2190 wrote:
               | OT: I wish I could relocate a blog post (on Microsoft's
               | site, I think) about a very a naive and "obviously wrong"
               | sorting algorithm that a dev identified in their (Excel?)
               | codebase. Turns out the code was naive because the vast
               | majority of their users were sorting very small sets of
               | data and the implementation actually performed much
               | better in those circumstances.
        
               | jhck wrote:
               | Maybe it's this one?
               | https://ericlippert.com/2020/03/27/new-grad-vs-senior-
               | dev/
        
               | JTbane wrote:
               | Funnily enough, if you're sorting small amounts of stuff
               | it does not matter what algorithm you use. If fact your
               | O(n log n) sorts are probably a lot slower on less than
               | some millions of elements.
        
               | bear8642 wrote:
               | > I then resort to the state of the art bubble sort
               | 
               | Remember reading Bentley's _Programming Pearls_ and
               | fairly sure that 's what he starts Sorting section with a
               | short implementation of
        
             | neutronicus wrote:
             | I do my own Graph algorithm implementations sometimes
             | 
             | Especially when I'm not sure the Graph approach is the
             | right one, it's easier than either
             | 
             | 1. Getting the Boost.Graph in the source tree to actually
             | compile
             | 
             | 2. Dealing with the bureaucracy of getting some, other,
             | Graph library requiring feats of compilation possible for
             | mere mortals into the source tree
             | 
             | This is, however, not something I do from memory - much
             | like the ancestor comment I see the relevant skill as
             | closer to recognizing positive-weight Shortest Path and
             | knowing you want Dijkstra than being able to write Dijkstra
             | without wifi
        
             | rubicon33 wrote:
             | I liken it to what lawyers go through with the bar here in
             | CA. It's gatekeeping.
             | 
             | Just like I don't think the CA bar should have a pass rate
             | in the 20% range, I don't think coding interviews should
             | ask riddles that are nearly impossible to solve on the fly
             | unless you get lucky and memorized THAT riddle in your
             | studying.
        
               | hmsshagatsea wrote:
               | While I do agree the CA bar is tougher than it should be,
               | a lot of the low passage rate comes from graduates of
               | less-than-stellar schools. If you look into passage rate
               | per school it's naturally much better at the higher
               | ranked universities.
        
               | enumjorge wrote:
               | Isn't that almost the definition of gatekeeping? Make the
               | process to enter the law profession so difficult that
               | only students from select universities have a good
               | chance.
               | 
               | Of course prospective lawyers should clear a certain
               | level of knowledge before they are allowed to practice,
               | but the passing rate is puzzlingly low. CA law schools,
               | as a group l, really only prepare such a low number of
               | their students to practice?
        
               | meta4s wrote:
               | Law school teaches you theory. The practical part is
               | supposed to come from competitive internships.
               | 
               | The bar is hard for CA because we go to school for the
               | theory and then no one really teaches you the formulaic
               | way to answer bar essays. Add on top of that it's a lot
               | of memorization and study. Most students I went to school
               | with had egos and thought they had it in the bag only
               | studying on the weekends.
        
               | hmsshagatsea wrote:
               | Well, not exactly. You need to have a certain level of
               | competancy to be an effective lawyer. Those who arent
               | "good enough" for the better law schools are often preyed
               | upon by overpriced and underresourced schools to give
               | false hope those who couldnt cut the mustard. Not saying
               | you cant be successful if you go to a crappy school, but
               | the chances of it happening are slim to none. Just look
               | at pass rates of Whittier (I think they're shut down now)
               | or Thomas Jefferson and then look at the tuiton rates.
               | And this isn't even counting the non-ABA approved
               | schools...
        
               | gmadsen wrote:
               | shitty law schools has become a huge problem in the last
               | couple decades. similar to ITT tech or phoenix online.
               | They drastically lower the lsats needed to get in, then
               | almost no one becomes an actual lawyer from that school,
               | but they do get 100K in debt.
               | 
               | also, gatekeeping has a negative connotation because it
               | is usually used when it seems unwarranted. If only
               | schools with high quality education are passing students,
               | that doesn't seem like a problem with the gate, but
               | instead with the other schools. I absolutely want lawyers
               | and doctors to be required to pass certain criteria.
        
               | actually_a_dog wrote:
               | Except that lawyers have to pass the California bar once
               | in order to get licensed; we SWEs have to pass the "bar"
               | every time we look for a new job.
        
               | bokchoi wrote:
               | Lawyers have to pay dues yearly and take a certain number
               | of CRE (continuing education requirement) hours every
               | year to maintain their license.
        
               | actually_a_dog wrote:
               | SWEs have to learn new things _every day_ to keep their
               | jobs. But, this is kind of stretching the metaphor past
               | its breaking point, really.
        
               | nicoburns wrote:
               | From what I've heard, the bar is _much_ harder than SWE
               | interviews.
        
               | pkaye wrote:
               | My first degree was civil engineering and I took the
               | California Engineers in Training exam back in my college
               | days and boy was it tough even though I had stellar
               | grades from a top university. You could bring mountains
               | of reference books to the exam but you had no time to use
               | them. You had to solve endless problems based on
               | fundamental techniques you already learned during your
               | education.
        
               | actually_a_dog wrote:
               | Oh, I'm not about to claim that these licensing exams
               | people in other professions take once and then never
               | worry about again (bar exam, medical boards, _etc._ )
               | compare in difficulty to a typical SWE interview.
               | 
               | But, here me out here:
               | 
               | Suppose the CA bar exam were changed in format to be more
               | like a SWE interview. That is, instead of being a 2 day
               | affair consisting of 5 essays of 60 minutes apiece, a
               | 90-minute performance test[0], and 200 multiple choice
               | questions, let's shrink it down to a format that fits in
               | one day and under 5 hours.
               | 
               | Now, let's nix the performance test right away, because
               | it would be incredibly difficult to shoehorn in any kind
               | of real, practical task in under 90 minutes.
               | 
               | According to [1], it looks like 100 multiple choice
               | questions are allocated 3 hours worth of time. So,
               | basically, our cut down format could be 100 multiple
               | choice and 2-3 essays. So, that's about half the amount
               | of testing that's done currently, more or less.
               | 
               | Now, if you have half the amount of testing available,
               | you have a choice: you can cover half as many areas of
               | law, you can cut down the depth of coverage in each area,
               | or some combination of the two. In any case, what you've
               | done is increase the variability in the test. In other
               | words, passing is now more likely to be influenced by
               | exactly which version of the test you get.
               | 
               | If there's an area of law you're weak in (say, bird law),
               | it might not even be covered. Conversely, if you're a
               | real expert in bird law, you won't get as much of a
               | chance to shine in the new format. That means our new
               | format both allows somewhat more marginal candidates to
               | pass, _and_ gives up some sensitivity in detecting people
               | who are really, really good.
               | 
               | So, in summary, the new format omits any sort of
               | practical task, increases the variability of the test,
               | increases the probability that marginal candidates will
               | get through, and decreases the ability to distinguish
               | truly excellent candidates.
               | 
               | Seems to me that's sounding more and more like a typical
               | day-long SWE interview, isn't it?
               | 
               | ---
               | 
               | [0]: Interestingly, this is essentially a work sample
               | test, which is the thing proven to correlate best with
               | job performance:
               | https://en.wikipedia.org/wiki/Performance_test_(bar_exam)
               | 
               | [1]: https://www.tjsl.edu/academics/bar-prep/california-
               | bar-exam
        
               | taude wrote:
               | Is there a shortage of attorneys in California?
        
               | anoonmoose wrote:
               | many people including myself believe that availability of
               | legal services is broadly lacking in the US. not
               | necessarily a shortage of attorneys, but a shortage of
               | attorneys that can do work for anything but top-quintile
               | clients. artificially restricting who is and isn't
               | allowed to perform certain jobs often has that sort of
               | effect.
        
               | ghoward wrote:
               | Not GP, but I never thought of this side effect before.
               | Thank you for making me aware of it!
        
               | mistrial9 wrote:
               | attorneys multiply when left to their own devices, which
               | is often bad for society.. (since like law enforcement
               | and middle management, LOTS of new people every year want
               | the job for all the wrong reasons) so California Bar
               | limits the new attorneys, which both lessens the total
               | number of attorneys, and also advantages the incumbents.
        
           | yawnxyz wrote:
           | we must have had the same interviewer! It boggles my mind how
           | this helps their business case / bottom line. And I was
           | applying as a UX designer lol.
        
           | gspr wrote:
           | It's also incredibly telling that the interviewer couldn't
           | figure out whether your code was correct or not without
           | compiling and running it.
        
           | FalconSensei wrote:
           | I hate this. People have IDEs and internet when working.
           | Having to write something that can be compiled in a doc is
           | just stupid.
           | 
           | As someone mentioned in another comment, I also never had to
           | actually implement a sort since I left university more than a
           | decade ago. I'm happy to discuss the different types and
           | approaches to how they could be done - as to evaluate problem
           | solving, logic, and general understanding - but to actually
           | code in an interview...
           | 
           | In a similar way, this week I even jokes on Twitter how I'm
           | doing many improvements and refactors on a codebase, but
           | there's the occasional 'how I do join 2 lists on Java again?'
           | moment when I completely forget something basic.
        
           | dekhn wrote:
           | i failed quicksort the first time I interviewed at google.
           | then got hired and worked there for 12 years and never wrote
           | a sort.
           | 
           | I also complained that google's coding solution (docs,
           | basically) was a terrible way to code, other companies use
           | coderpad or whatever, but I expect that Google will never
           | change this. They love to hire people who are excellent at
           | coding CS approximate solutions, but have little to no
           | judgement on how to do good software engineering.
        
             | telotortium wrote:
             | The pandemic has _finally_. forced them to move to
             | something more Coderpad-like
        
           | endtime wrote:
           | Standard disclaimer: everything below is my own opinion based
           | on my personal experience, and I'm not speaking on behalf of
           | my employer.
           | 
           | > I thought I was done, then the interviewer said she would
           | go go copy my code and compile it after the interview to see
           | if I was right, which blew my mind.
           | 
           | I've been interviewing at Google for nine years and have
           | never done this. I generally don't think it's fair to ding a
           | candidate for something I don't notice in an interview, where
           | I'm at a huge advantage. If it looks right to me then that's
           | good enough.
           | 
           | But that said, I have often asked questions similar to what
           | you describe. You have to write code in the shared doc
           | because hiring committees want to see it - fair to blame the
           | process for that, but not the interviewer. I actually
           | appreciate this for a couple reasons:
           | 
           | * It levels the playing field a bit, in the sense that code
           | is more objective than an interviewer's notes on how a
           | conversation went (especially for people who aren't native
           | English speakers)
           | 
           | * I sometimes find that candidates who communicate well
           | struggle to turn their ideas info code. Other times,
           | someone's communication and solution are kind of average, but
           | then they use all the little things I like seeing
           | (defaultdict(set), zip, etc. in Python). Lots of people claim
           | to be very experienced programmers; seeing how comfortable
           | and fluent someone is when actually writing code is a strong
           | signal. If you don't like the focus on data structures and
           | algorithms that you haven't thought about since college, you
           | should probably appreciate the coding part.
        
             | czep wrote:
             | > It levels the playing field a bit, in the sense that code
             | is more objective than an interviewer's notes
             | 
             | Except that writing code in a Google doc on the phone
             | doesn't in any way resemble the real "playing field". I
             | grant that it's level in that everyone faces the same
             | constraints, but to write code in a gdoc with red squiggly
             | lines underneath every keyword, automatic capitalization
             | after a dot, and variable width font? How does that give
             | you any kind of useful assessment? It's like handing a
             | butter knife and some twine to a doctor and saying "here,
             | show me how you'd stitch up this wound".
        
             | neemeizdabest wrote:
             | Google interview process is designed around how badly you
             | want to work there not what are your skills i.e practising
             | solving bunch of leetcode puzzles on whiteboard and
             | speaking out loud is all it takes to get through the
             | interview process. It just takes some time to prepare.
        
               | spookthesunset wrote:
               | I think that is basically it. I think many of these FAANG
               | companies interviews are more of a hazing than an actual
               | assessment. Everybody who works there had to go through
               | that interview... if you want to be part of the pack, you
               | too must endure it.
               | 
               | When viewed in that light it actually doesn't seem quite
               | as bad.
        
             | mox1 wrote:
             | How would you feel if you were going to a job as a writer,
             | and the interviewee asked you to put a story, poem, etc.
             | down on a napkin, with a crayon?
             | 
             | Like thats how I would feel writing code into freakin
             | google docs during a job interview...with Google.
             | 
             | Tie 1 arm behind by back as the synax goes wonky, I'm
             | fighting the spacing, etc. etc.
             | 
             | Or put mario Andretti into a ford focus, then test his lap
             | times, with 0 warning.
             | 
             | Yuck.
        
               | soheil wrote:
               | Google Doc is specifically designed for writing and
               | reading and used probably by more people than any other
               | piece of software ever for that task. And you think it's
               | fair to compare it to crayon and napkins? What a world we
               | live in. Programming is often about thinking through the
               | problem, but if you can't separate yourself form your IDE
               | when writing code and it's about syntax then that says
               | more about your style.
        
               | bostik wrote:
               | While I don't necessarily disagree with the sentiment, I
               | can provide a real life take. Not specific to GDocs, this
               | applies to _all_ browser based editors.
               | 
               | You may usually write code in a terminal based
               | programmer's editor (vim, emacs, ...) and realise the
               | code you've just written is not quite right. You want to
               | delete the last two words. There's even a default and
               | handy keybinding for doing that.
               | 
               | So you press ^W twice.
        
               | flavius29663 wrote:
               | > mario Andretti
               | 
               | If you're a world champion, you would probably enjoy an
               | exercise like this.
               | 
               | This lady pilot sure did:
               | https://www.youtube.com/watch?v=5KiC03_wVjc
        
               | nuclearnice1 wrote:
               | What a delightful video! Unfortunately, her first time
               | was 23 seconds over and she will not be getting a job on
               | the Google racing team.
        
               | spookthesunset wrote:
               | I mean tabs don't work like a normal editor. And it wraps
               | lines. And the default font is not monospaced.
               | 
               | If you are gonna require a candidate to write compilable
               | code at least use one of the many tools designed
               | explicitly for coding interviews.
               | 
               | I think I'd rather use straight notepad than google docs.
        
               | verticalflight wrote:
               | Just fyi - Mario Andretti and other similar drivers could
               | be placed into any car and would perform at a very high
               | level after a lap or so...
        
               | usefulcat wrote:
               | On one hand, I can appreciate that it's unpleasant to be
               | put on the spot. Or being forced to use crappy tools.
               | Nobody likes that.
               | 
               | That said, if a person is being considered for a coding
               | job, wouldn't that person want to demonstrate their
               | coding abilities? I mean, assuming they're actually good
               | at coding?
               | 
               | In interviews, I much prefer a concrete problem to an
               | abstract one, and coding problems are typically far more
               | concrete than most other subjects covered in SW dev
               | interviews.
        
               | nemonemo wrote:
               | I consider google doc coding an extension of the white
               | board coding, which often happens in pair programming. I
               | do not think it should aim perfectly working code, but at
               | least I would personally expect reasonably good
               | whiteboard coding hygiene from a colleague, at least for
               | a report to the committee.
        
           | markus_zhang wrote:
           | Sometimes I sarcastically think they already have a friend
           | who applies and needs to fail the others.
        
           | lawn wrote:
           | I had a similar experience interviewing years ago for Google,
           | although I can't remember the algorithm they wanted me to
           | implement.
        
           | biztos wrote:
           | I find it... troubling? That a technical interviewer can't
           | tell for herself whether your code will work. Wouldn't you
           | ideally want people who actually _understand_ code to be
           | giving the coding questions?
        
             | mLuby wrote:
             | Funny and illuminating examples of this are the excellent
             | "hexing the technical interview" series (read in any
             | order): https://aphyr.com/tags/interviews
        
             | ellenhp wrote:
             | Are you saying that because this interviewer needs to run
             | code to find logic errors, she's somehow not a competent
             | engineer? Because I usually need to run code to find logic
             | errors. Sometimes I use formal verification instead but
             | that's pretty rare. Am I also not a competent engineer?
        
               | agent327 wrote:
               | He's saying that in order to judge someone's ability at
               | something, you need to understand that thing yourself. If
               | you require the candidate to write perfect code using
               | nothing but a whiteboard, you need to be able to read
               | that code using nothing but a whiteboard as well.
               | 
               | If the interviewer cannot do this, how is he going to
               | judge the result? Does he know how to run a compiler?
               | Does he know how to run the code? Does he have the skill
               | to judge the output? Is it really a good policy for a
               | company to discard a possibly excellent candidate that
               | just missed something silly that would normally be
               | checked by a tool while you type?
        
               | gspr wrote:
               | Does this reasoning not also apply to the applicant,
               | though?
        
               | mlyle wrote:
               | So, we can have an interviewer perform a possibly
               | incorrect manual validation of an interviewee's possibly
               | faulty code. Reading code is harder than writing it, and
               | presumably the applicant has been asked to do something
               | tricky.
               | 
               | Or they can run it, asking the real arbiter of truth
               | whether it works or not.
               | 
               | Of course, "whether it works" is merely one (very
               | important) metric of quality.
        
               | tsukikage wrote:
               | The interview is a proxy for working with the person. In
               | this case, it's a proxy for pair programming / code
               | review. A good chunk of what the interviewer, ideally,
               | looks for when asking a coding question is communication
               | from the interviewee - can the interviewee communicate
               | what they are doing and why? Can they explain the intent
               | of the thing they've just written? Do they have a clear
               | picture of it in their head, and can they communicate it?
               | When the interviewer spots problems with it, what does
               | the ensuing discussion look like? - how well does the
               | interviewee collaborate in solving them? If the
               | interviewer is wrong, does the interviewee push back?
               | How? Can they understand you, and can they make
               | themselves understood?
               | 
               | Can you work with this person? Can you collaborate to
               | write code, or will it be a daily struggle?
               | 
               | Whether the code actually builds and runs after the hour
               | is up does not help answer these questions; it is
               | arguably the least interesting part of the whole process.
               | The time limit is artificial; if all the other things
               | align but you didn't happen to get it working in one
               | hour, you'll likely have got it in two. If they don't
               | align, you'd likely never have got it.
        
               | Hydraulix989 wrote:
               | Every recruiter says the same thing, but in practice the
               | interviewer is only looking for the right answer, and
               | that is what determines the outcome of the interview.
               | I've never seen anyone helped out by soft skills while
               | still having an incomplete solution.
        
               | shuger wrote:
               | The problem is it won't run. It was written in google
               | docs without IDE. Everyone who programmed in their lives
               | knows this. You cannot write out a whole algorithm like
               | that and not make any even trivial error.
               | 
               | This is like writing code in notepad and creating a PR
               | without building or running it to test once. What is this
               | testing? There is no real world scenario where you are
               | expected to work like this and for a good reason.
        
               | ellenhp wrote:
               | Yeah. If I were asking a trickier question and I got an
               | interesting new variant of the solutions I'm aware of,
               | I'd absolutely run it if I had time to type it up and
               | everything. Most solutions are either something I've seen
               | before verbatim or obviously wrong, though.
        
               | TheOtherHobbes wrote:
               | If you can't tell the difference between sketched-out
               | kinda sorta pseudocode and potentially workable C++ then
               | you're certainly not competent in C++.
               | 
               | And if you fail to communicate the requirement for one or
               | the other then you're certainly not a competent
               | interviewer.
               | 
               | You also have to ask what exactly is being tested here?
               | Is it the ability to remember syntax? To remember an
               | algorithm? To improvise an algorithm? To recognise which
               | algorithm is needed?
               | 
               | What, _exactly?_
        
               | Yacoby wrote:
               | Maybe they are a bad interviewer?
               | 
               | In my view, if the answer involves a topological sort the
               | interviewer should know how to solve it and be able to
               | follow and find errors in the candidates code. If the
               | interviewer, knowing the answer, cannot find any issues
               | then surely the code is fine (for code written in an
               | interview)
        
               | ellenhp wrote:
               | It's also possible that she hadn't seen the particular
               | algorithm used before, or that she was having an off day
               | or stressing about a meeting immediately after the
               | interview, or that there were errors that she did see and
               | she didn't want to say "yeah there are errors here"
               | because doing so could affect the candidate's confidence
               | in the interviews after hers. I could imagine any of
               | these being true. Or she could just be a bad interviewer.
        
               | shuger wrote:
               | That is irrelevant. Asking someone to type non trivial
               | code outside of IDE and then expecting it to compile and
               | run without issues is lunacy. Even junior programmers
               | know this. The interviewer in this story was either an
               | amateur, an idiot or on power trip.
        
               | ellenhp wrote:
               | I guess I'm also an idiot then, thanks, how kind of you
               | to say that.
               | 
               | Actually hang on, I'm editing this to be slightly meaner.
               | Your whole take that doing this is a sign that she's
               | either an idiot or on a power trip is a very familiar
               | thing that people say about women in tech and I'm
               | honestly tired of it, because I can see myself doing
               | exactly what she did and I don't like it when people say
               | those things about me. Please don't do that.
        
               | xenocratus wrote:
               | If you can't assess someone on their response then you're
               | not interviewing them, you're just giving an exam by
               | proxy. But that might very well be because the whole
               | recruitment process is thoroughly stupid.
        
           | ballenf wrote:
           | My lesson learned was "don't listen to what they say, watch
           | what they do". As in, don't trust them to tell you what
           | they're looking for, understand that figuring out what
           | they're actually testing is also part of the screening
           | process.
           | 
           | I don't see a lot of focus on the hide-the-ball aspect of
           | interviews, but is something I've experienced a few times and
           | bothers me way more than anything else.
           | 
           | The clearest time this happened I was told the company was
           | big on pair programming, so I'd be doing a pair programming
           | session. It turns out they meant I'd be tested on whether I
           | could finish a coding exercise in the allotted time with
           | someone watching. There was zero "pair programming" of any
           | kind involved and time spent on collaboration counted against
           | me.
        
           | trinovantes wrote:
           | I once had an in-person interview where they gave me a sheet
           | of printed code and asked me to point out the syntax errors.
           | Some interviewers are absolutely insane.
        
             | kevstev wrote:
             | We may have had the same interviewer- tbh I thought this
             | was pretty reasonable and more of a warm up really. I think
             | this also lead to a discussion on some questionable logic
             | and how you could improve the code.
             | 
             | I had 10+ years experience in C++, I thought it was
             | completely reasonable. Especially compared to their later
             | questions around something along the lines of finding a
             | shortest path in a tree. I interviewed there a bit before
             | their process was so well known to be game-able, I went in
             | with zero study time on obscure algorithms outside knowing
             | the O(N) of the most widely used, and certainly did not
             | practice actually writing or interacting with trees and
             | such.
        
               | neutronicus wrote:
               | Yeah, I had an interview like that
               | 
               | There was a function with a syntax error, that also
               | returned a pointer to stack memory, and made some logic
               | error where it assumed a class with no vtable would be
               | polymorphic.
        
             | ljm wrote:
             | I had to review someone's PR for one interview. Ultimately
             | I failed it because me feedback focussed solely on
             | implementation details and asking if there are better ways
             | to solve the problem (with some suggestions as a nudge).
             | Apparently, that was fantastic and showed all the qualities
             | of good coaching...but they expected me to point out all of
             | the instances of poor indentation and other aesthetic
             | things. My justification that it was unimportant and that
             | running rubocop would fix it wasn't good enough - the PR
             | had to know _all_ of the nitpicks.
             | 
             | You know, if I had to do that for every PR I reviewed, I'd
             | be burned out in no time.
             | 
             | It was a shame, but if I didn't flunk that interview then I
             | wouldn't be where I am now.
        
               | Verdex wrote:
               | Based on your description ... that wasn't a failure.
               | Success is not working at places like that.
        
               | dsr_ wrote:
               | "if I didn't flunk that interview then I wouldn't be
               | where I am now"
               | 
               | This is, I think, the closest thing there is to a
               | universal experience in this field.
               | 
               | Followed closely by "how did I miss that single-character
               | error?"
        
             | Ntrails wrote:
             | Github PRs also lack syntax checking etc - so it isn't
             | something you'll never see at work right?
             | 
             | (Admittedly if the PR doesn't build why are you reviewing
             | it but whatever)
        
               | rendall wrote:
               | This is incorrect. You can run tests on PRs and disallow
               | merging until it passes all the checks
               | 
               | https://github.com/features/actions
        
               | andix wrote:
               | That's why you are reviewing a pull request in your IDE.
               | 
               | And you are having a CI build and unit tests in place. If
               | it doesn't compile or a lot of tests are failing, a sane
               | person won't even bother to review a pull request.
        
               | pcthrowaway wrote:
               | Serious question, as I've never done a PR in my IDE;
               | hadn't even thought to.
               | 
               | If you check out the branch in your IDE, is there a way
               | to have it highlight the changes in the branch you're
               | reviewing? Or do you need to reference the output from
               | `git diff` or the github PR view?
        
               | Macha wrote:
               | VS Code:
               | 
               | 1. Open Source control window
               | 
               | 2. Checkout the PR branch
               | 
               | 3. Open the branches listing panel in the sidebar.
               | 
               | 4. Mouseover the target branch of the PR
               | 
               | 5. There's an icon that looks like two nodes with arrows
               | pointing between them. Mouseover text "Compare with ...".
               | Click it.
               | 
               | 6. The search and compare panel in the sidebar has a
               | listing of files changed, you can click a file to get a
               | diff view.
               | 
               | There are gitlab [1] and github [2] extensions which
               | streamline this workflow if your code is hosted on one of
               | those services, and let you leave comments in editor
               | which show up in the web UI.
               | 
               | IntelliJ has support for display a diff for a branch or
               | github PR built in [3] but I hate their diff modal view.
               | 
               | [1]: https://marketplace.visualstudio.com/items?itemName=
               | GitLab.g...
               | 
               | [2]: https://marketplace.visualstudio.com/items?itemName=
               | GitHub.v...
               | 
               | [3]: https://www.jetbrains.com/help/idea/contribute-to-
               | projects.h...
        
             | yobbo wrote:
             | It is disrespectful, but it is a proxy test for how many
             | hours you have spent reading and writing code in that
             | language.
        
               | sokoloff wrote:
               | What about it is disrespectful? It seems to me that it's
               | testing for something relevant and I don't see it as
               | otherwise bad (abusive, pure trivia, easily Google-able,
               | etc)
        
               | yobbo wrote:
               | It is akin to giving a spelling quiz to an author. There
               | is a level of decorum required when dealing with
               | professionals. A junior verbally pointing out a syntax
               | mistake reveals a naivete about the competency itself and
               | "the mission" of the field.
               | 
               | In this interview, I would have liked to receive two code
               | examples (that might contain errors) and discuss benefits
               | according various objectives.
               | 
               | If the interviewer makes it clear that pointing out
               | syntax mistake is not rude, I could mention them in
               | passing. This demonstrates not only attention to details
               | but also decorum.
        
               | yxhuvud wrote:
               | Then do it in a different way. Phrase it as a toy pull
               | request that the reviewer has to review, and let that
               | contain everything from minor syntax errors to logic
               | errors to missing core stuff (like missing test cases).
        
               | sokoloff wrote:
               | If I claim fluency in a non-native language because
               | that's a relevant qualification for the job, testing me
               | on it is fair game IMO.
               | 
               | That's true whether I'm an author writing in German, a
               | newscaster reporting in Italian, or a programmer coding
               | in C++.
        
               | thrwyoilarticle wrote:
               | OK then, I'm not fluent in any languages, I merely use
               | them to create products that people buy for money.
        
               | PeterisP wrote:
               | Definitely not - if an author has written a book in
               | German (even if it's not their native language) then
               | giving them a German test is definitely insulting, the
               | same applies for a newscaster in Italian if they have
               | done reporting in Italian previously.
               | 
               | What you say applies if you're hiring people for their
               | _first_ position at that task (e.g. the author writing
               | their first book in German or a newscaster who has never
               | done reporting in Italian professionally). If you 're
               | hiring people at some hypothetical "level 10" then your
               | interview needs to discriminate between "level 9 or less"
               | people and "level 10 or more" people, but asking them to
               | assert that they meet "level 1" implies that they might
               | not, and that implication is literally insulting.
        
               | allo37 wrote:
               | I think the issue is what happens if an author ghostwrote
               | a book in German? I guess that's the book version of
               | copying code off Stack Overflow and claiming it's yours?
               | People trying to game the system make it crappier for
               | everyone else.
        
               | sokoloff wrote:
               | In the interview case, you often have someone who _claims
               | they wrote a book in German_ (but you can't see the book)
               | or to be a professional Italian newscaster (but you can't
               | see any of their reporting).
               | 
               | Switching part of the interview to be in Italian or
               | German would not be seen as disrespectful, right?
               | 
               | It's interesting that some find the coding equivalent
               | insulting rather than merely a bar pointlessly laid on
               | the ground to be stepped over.
        
               | PeterisP wrote:
               | The difference IMHO is in the expectations of what's
               | required from the applicant. Switching part of the
               | interview to be in Italian or German would not be seen as
               | disrespectful as it does not add much (if anything) to
               | the length of the interview, but asking them to fill a
               | 30-minute quiz on basic Italian/German grammar would be
               | disrespectful.
               | 
               | A bar pointlessly laid on the ground to be stepped over
               | is reasonable iff it's you can just quickly to step over
               | it - but if they ask the candidate to waste half an hour
               | to prove their capacity for stepping over bars laying on
               | the ground, that is disrespectful of their time.
               | 
               | For programming, a trivial _short_ task (e.g. fizzbuzz)
               | is appropriate but a trivial _long_ task is appropriate
               | only for junior positions but disrespectful for senior
               | ones - ask something that tests whether they 're capable
               | of something serious, because passing the trivial task
               | can't be sufficient anyway.
        
               | Piskvorrr wrote:
               | TBH, aeons ago, we had this as a high-pass filter
               | (doesn't notice a glaring SQL injection hole, no problem
               | with eval() on user input? Nope.) and a conversation
               | starter (-why are you constructing a database handle
               | right in the middle of business logic? -indeed; how would
               | _you_ do this?)
               | 
               | It very much depends on the code - but I was genuinely
               | surprised how many applicants, claiming to be fluent _and
               | applying for a senior developer position_ , had problems
               | just grokking what the code did (a while loop reading
               | from database).
        
               | vidarh wrote:
               | I once halted an interview because of this kind of thing.
               | Told them their interview process suggested they were
               | looking for someone substantially less experienced. When
               | they then insisted everyone had to go through this, I
               | told them that was a warning sign to me that their hiring
               | process was a box ticking exercise rather than addressing
               | the actual needs of the positions they were hiring for
               | and that I was no longer interested.
               | 
               | Recruiters need to understand that these kinds of
               | processes will often filter out the wrong people, such as
               | those skilled enough to be able to pick and choose.
        
               | twic wrote:
               | But also the right people, such as those arrogant enough
               | to be upset by it.
        
               | Loughla wrote:
               | I mean, it all comes down to how that situation is
               | handled.
               | 
               | If OP was a dick about it, then yeah, it serves to filter
               | out an arrogant assbag.
               | 
               | But if OP simply explained that the interview led them to
               | believe the position was a more junior/entry level than
               | they were expecting, that seems fine. Further, to even
               | explain that the interview process seems to just be a
               | checkbox process seems fine; if you work in a critical
               | thinking/creative role, checkbox culture is an absolute
               | brain drain.
               | 
               | Getting that out in the open, in honest and respectful
               | terms, is a fine thing to do. Why wouldn't it be?
               | 
               | Further, any hiring institution that feels the need to
               | build in 'tricks' to filter people out of the interview
               | process is toxic. Even if the people they're filtering
               | are arrogant assbags.
        
               | Frost1x wrote:
               | A lot of interviewers have complete leverage, so they
               | don't get any sort of feedback or real check on their
               | ability or processes. It's only when a candidate isn't
               | desperate for the position, is competent, recognizes red
               | flags, and gives them the feedback that they'd ever be
               | aware of. You don't have to be upset to realize there's a
               | mismatch and withdraw your candidacy.
               | 
               | Candidates often have to call out nonsense otherwise it
               | may never be called out. Processes need feedback to
               | adjust and adapt, otherwise they'll typically continue
               | with momentum alone.
               | 
               | With that said you can give feedback in a polite and
               | professional way, you don't have to be arrogant about it.
               | "Based on the questions, it appears you're searching for
               | these specific abilities which are often attributed to a
               | junior role, so I believe I may be a mismatch for this
               | specific role. I'm going to politely withdraw my
               | continued involvement in this process. I appreciate your
               | time and interest and hope you will contact me if a more
               | senior role is available." Or something to that effect.
               | You don't have to be arrogant to give feedback.
               | 
               | If you were like "what, this is ridiculous, what am I am
               | an intern? Good luck filling this trash position!" And
               | then walk out then sure, that person clearly had some
               | anger management issues.
        
               | ryoshu wrote:
               | I once interviewed for a director role and the first
               | round went something likes this:
               | 
               | Interviewer: How would you reverse a string? Me: _boggle_
               | Any language I want to use? Interviewer: Yes. Me: Okay,
               | Ruby.  "somestring".reverse! Interviewer: _boggle_ Me: I
               | don 't think we're aligned on what this role is. _says
               | thank you and leaves_
               | 
               | Interviewers need to understand what they are
               | interviewing for.
        
               | naruvimama wrote:
               | I usually write python code, I stick to pythonic styles,
               | consistency and good practices.
               | 
               | If there is an error, I can quickly figure out what that
               | is and what I should do to fix it. I would know why the
               | error occurred.
               | 
               | Beyond that deliberate interview practice is the only way
               | to get a lot of interview questions right.
        
               | kamaal wrote:
               | A while back Indian companies were notoriously famous for
               | giving questions from _Let us C, from Yashwant Kanitkar_.
               | 
               | The questions go like,
               | 
               | What is the output of the expression below?
               | int i = 10;         ****++&&*+p;
               | 
               | Followed by a myriad of options. Including things like
               | _Syntax error_.
               | 
               | Not sure how this measures language proficiency.
        
               | rdedev wrote:
               | My diskile of C and C++ were particularly due to such
               | questions. Its always in C or C++ I see such convoluted
               | questions
        
               | mlindner wrote:
               | I've been working in C for most of my career and I've
               | never heard of such questions. They're not in any
               | textbook I'm familiar with. In fact they're incredibly
               | pointless and irrelevant.
        
               | Bayart wrote:
               | I wonder how many Indians partake in the IOCCC [1].
               | 
               | [1]: https://www.ioccc.org/
        
               | roland35 wrote:
               | Ooof... I have done a few double pointers in my day *,
               | but anything beyond that seems like bad practice!
        
               | merlincorey wrote:
               | > What is the output of the expression below?
               | 
               | > int i = 10;
               | 
               | > **++&&*+p;
               | 
               | > Followed by a myriad of options. Including things like
               | Syntax error.
               | 
               | I consider myself fluent in C and to a lesser extent C++
               | -- that's a Syntax Error in C, at least.
               | 
               | This isn't a particularly difficult one to spot, but I
               | can understand how it would be if you weren't very
               | familiar the language.
        
               | kamaal wrote:
               | They mix the correct ones and wrong ones in a way, in a
               | time constrained situation.
               | 
               | Eventually your eyes will give being a lexical analyser.
        
               | lloydatkinson wrote:
               | That probably explains a few things...
        
             | xorcist wrote:
             | I have done this. Is it really such an insane idea? Makes
             | for a nice break from "what does this code do"? You need
             | some technical "anchor" to make for more concrete
             | discussion points.
        
               | skeeter2020 wrote:
               | Would you accept "my build toolchain and linter will
               | catch all of these syntax and stylistic errors." as an
               | answer? 'Cause that's what all your devs are going to do
               | IRL.
        
               | xorcist wrote:
               | Not really since that doesn't leave much room for
               | discussion, but that is my problem not theirs. The point
               | is to have something to discuss, not to listen for a
               | singular answer. Now we can discuss hypothetical
               | situations and philosophy but I'd much rather have a
               | concrete piece of code to go through.
               | 
               | Seeking out problems and errors can be a good
               | conversation piece. Hopefully you get to hear some
               | anecdotes, prod the taste in style and how well that that
               | taste might play with others. The interview situation
               | isn't easy for anyone, and anything that can if something
               | is even remotely qualified helps.
        
             | bluedino wrote:
             | I worked at a place that did something similar. VBA code,
             | printed out in a proportional font, no word wrap so long
             | lines spilled over...
             | 
             | "What does this code do?"
             | 
             | That was a pretty easy one to figure out, it pulled
             | coordinates from a database table, and then it stepped
             | along all the lines trying to find the longest one (they
             | were a metal shop).
             | 
             | "Do you see any evidence that this code has been
             | optimized?"
             | 
             | That was the dumb question.
        
             | siva7 wrote:
             | wait until you see this asshole move being pulled to find a
             | bug in production code under time pressure their team has
             | failed in the real environment by being given out some
             | thousand-lines long printed code from the development
             | branch.
        
             | liveoneggs wrote:
             | you prefer being asked to write it out long hand?
        
             | hdjjhhvvhga wrote:
             | Actually this one might make sense, depending on the code
             | and the position you applied for.
        
               | smt88 wrote:
               | Your IDE can check your syntax. For people who have to
               | switch between languages regularly, precise syntax
               | memorization is difficult and a waste of time.
        
               | Piskvorrr wrote:
               | An IDE can check your syntax, sure. It can even catch
               | low-level bad practices ("you're making a database call
               | in a tight loop, this is horribly inefficient"). This is,
               | in my opinion, basic tool usage: warn of LHF early.
               | 
               | Last time I saw one of those test-ish pieces of code,
               | though, an IDE+static analysis would have caught about
               | 1/2 of the problems; the other half required actual
               | thinking (not statistical pattern matching, aka AI):
               | "don't trust user data, _that_ should not go _there_ even
               | though the call signature matches, you 're holding it
               | backwards."
        
               | smt88 wrote:
               | > _" don't trust user data, that should not go there even
               | though the call signature matches, you're holding it
               | backwards."_
               | 
               | Good type systems do this, although it's beside the
               | point.
               | 
               | The point I was making is that the IDE remembers
               | unimportant things so that my only concern _is_ the
               | actual thinking part. It abstracts away the minor and
               | sometimes very important syntax differences.
        
               | handrous wrote:
               | I'd struggle to code a five-line program that'd compile
               | in languages I've written tens of thousands of lines of
               | code in, in Notepad, that'd actually compile & run on the
               | first try. I might fail that in a language I was writing
               | _last week_. I mean, I might manage it, but it 'd be
               | sheer luck. Decent chance I forget, in the moment and
               | under pressure and without examples to crib off of, IDE
               | support, or the ability to check the manual, the correct
               | way to do _comparisons_ for all types, even, or basic
               | stuff like how to print to the console or what this
               | language 's sugar for a "for-each" is, or whether it
               | _has_ such sugar. Reading input? The right calls for file
               | IO? Anything more complicated than that? Oh god, there 's
               | no way.
               | 
               | Luckily I never fucking ever have to do that in my actual
               | job. If I did, I might well get good at it. Since I
               | don't, I... don't. I also haven't gotten much better at
               | driving semi trucks or framing a wall, in my over-a-
               | decade career writing software. Go figure.
        
               | kragen wrote:
               | Your IDE can tell you if your syntax failed to represent
               | _any_ valid program. It can 't tell you if your syntax
               | represents _the wrong_ valid program. If you can 't even
               | spot _invalid_ syntax, you have no hope of spotting
               | _bugs_ , because you can't _read what the code says_.
               | Which turns out, contrary to your beliefs, to be
               | important for many purposes.
               | 
               | That doesn't mean you can't debug. You can step through
               | the code step by step in the debugger, or add more and
               | more logging around the bug, until you figure out which
               | expression has a meaning unintended by its author. But
               | that means that, if we're working in a language someone
               | knows well, you're likely to spend hours debugging a
               | problem that they can just _see_ immediately when they
               | 're reviewing a merge request. That's an orders-of-
               | magnitude difference in productivity when it's important
               | for code to be correct, precisely due to what you call
               | "precise syntax memorization".
               | 
               | Most of programming isn't writing code. It's reading
               | code.
               | 
               | It's possible to go overboard with this. There are other
               | skills that are more important than being able to look at
               | some code and immediately see what it means. There are
               | excellent programmers with severe dyslexia who will just
               | never be able to do this. But it's foolish to think that
               | gaining this skill is "a waste of time" for those who
               | can.
               | 
               | There are languages I've used where I don't know the
               | syntax that well. PHP, Ruby, x86 assembly, OCaml. There
               | are languages where I know the common syntax well, but
               | there are plenty of obscure corners of the syntax that I
               | don't: C++, Perl, bash. But I regularly switch between C,
               | Python, and JS, and I'm pretty confident that I know
               | their syntax, as well as numerous other languages like
               | Tcl, Lua, Prolog, PostScript, and arguably Scheme and
               | Elisp, which I don't use regularly but still wouldn't
               | have any trouble spotting syntax errors.
        
               | DougBTX wrote:
               | I don't buy that argument, as a programmer you have to
               | write out code following a precise syntax all the time.
               | Programming would be insanely tedious without knowing
               | correct syntax.
               | 
               | Having said that, if someone came up with an interview
               | test which used especially esoteric parts of the language
               | in unconventional ways and then asked to spot the errors,
               | the could be a dubious question.
        
               | smt88 wrote:
               | > _as a programmer you have to write out code following a
               | precise syntax all the time_
               | 
               | When did I claim that the IDE absolves you of needing to
               | know the syntax?
               | 
               | It doesn't. But between autocomplete, hinting, linting,
               | and any other static analysis, it makes it close to
               | painless to switch between languages without making
               | horrifying mistakes. The top-tier JetBrains IDEs
               | (IntelliJ and Rider come to mind) will even tell you ways
               | to make your code more efficient or modern, like changing
               | a bunch of if/else to pattern matching.
               | 
               | Why should I have to remember the full truthiness table
               | of JavaScript? Why should I have to remember what all the
               | different string delimiters do in every language? It's
               | not important. My IDE can (and does) know that I'm trying
               | to do some kind of string interpolation and will just fix
               | it for me.
        
               | MrDresden wrote:
               | While I understand where you are coming from, I disagree.
               | 
               | IDE tools are great performance enhancers, but they can
               | also be crutches.
               | 
               | I would always expect a professional software developer
               | to be able to parse some code on a page and point out its
               | syntax errors (as well as suggest edits).
               | 
               | edit; here I am thinking about something more substancial
               | then just a missing ';' or a lack of a closing "
        
               | megous wrote:
               | Let's use (C++) something not common, but not all that
               | crazy:                   bool x = false;         x ||=
               | something();
               | 
               | How many multi-lingual programmers will remember which
               | one of the 7 languages they know does have a boolean
               | assignment operators and which do not without looking it
               | up? Does that make them unprofessional?
               | 
               | How many do remember exact operator precedence rules for
               | all those languages, when in practice you may need just
               | the basic ones and use () to work around the lack of
               | exact knowledge.
               | 
               | Also which version? Something not working in PHP 7.3 may
               | be ok in PHP 8, but company wants you to code in PHP 7.3,
               | or ES5. In practice you get quickly acclimatized to any
               | of the languages you know after working with them for a
               | few days or a week, but good luck remembering exact rules
               | of any of them at any given time when asked.
        
               | HWR_14 wrote:
               | You're not mentioning or alluding to the one obvious
               | syntax error. I don't know how to spoiler it so I will
               | say there is an issue on the second line that, again
               | repeating, I don't know how to call out.
               | 
               | And yes, I work in multiple languages.
        
               | leetcrew wrote:
               | also if you can't spot that error, you might not realize
               | a subtle, yet important, detail about that line (if
               | written correctly). contrary to what you might expect, it
               | cannot short-circuit the way || does, leading to possible
               | performance or even correctness issues.
        
               | HWR_14 wrote:
               | This is very true. I hope that people are not using the
               | short-circuit feature in a way that impacts correctness!
               | I would have an issue with that code for trying to be too
               | clever even if there were no bugs and it worked well.
               | 
               | Performance issues, on the other hand, I can see
               | accidentally arising.
        
               | bryondowd wrote:
               | I see short-circuit for correct behavior all the time,
               | most frequently in the format: if (pointer &&
               | pointer->member == value)
               | 
               | Where you want to make sure a pointer you've been given
               | isn't null before you try to dereference it. Without
               | short-circuit, this becomes a segfault.
        
               | lucumo wrote:
               | That boolean assignment operator was addressed. Whether
               | or not C++ has them (it doesn't) is exactly the point of
               | that code snippet.
               | 
               | They do exist in other languages. ES has it in exactly
               | that form. Java has it in the |= form, not to be confused
               | with the bitwise OR of the same form.
               | 
               | Whether or not these short-circuit is not all that
               | interesting for most boolean logic. (Though it can be
               | useful to know if these are used as hacky error-handling
               | and default-setting. It depends on how you read
               | "something" whether or not that's going on here.)
        
               | HWR_14 wrote:
               | > That boolean assignment operator was addressed.
               | 
               | Where and when? Because I was the only person alluding to
               | it, and the replies to my post.
               | 
               | > Whether or not C++ has them (it doesn't) is exactly the
               | point of that code snippet.
               | 
               | C++ has boolean assignment operators that operate the way
               | that the code is clearly meant to operate. That code does
               | not have have a valid one. Where do you think Java got
               | them from?
        
               | megous wrote:
               | C++ does not have boolean assignment operator in a sense
               | the ||= syntax works in ES.
               | 
               | https://www.w3schools.com/cpp/trycpp.asp?filename=demo_op
               | er_...
               | 
               | ||= will not assign anything unless the LHS variable is
               | falsy. It will not even evaluate the right side unless
               | LHS is falsy.
               | 
               | |= will work the same in C++ and ES mostly (depending on
               | types)
        
               | lucumo wrote:
               | > > That boolean assignment operator was addressed. >
               | Where and when? Because I was the only person alluding to
               | it, and the replies to my post.
               | 
               | The words "boolean assignment operator" are in the first
               | sentence after the code snippet in megous' post.
               | 
               | > C++ has boolean assignment operators that operate the
               | way that the code is clearly meant to operate. That code
               | does not have have a valid one. Where do you think Java
               | got them from?
               | 
               | As far as I can tell the |= operator in C++ is the same
               | as in C, i.e. a _bitwise_ OR operator. It works for
               | booleans due to their bit pattern, but it 's not the
               | same. My C++ knowledge is extremely limited, so I looked
               | it up and I may be misinformed though.
               | 
               | Java's |= is different for ints and boolean. There are no
               | bitwise operators for booleans: bool1 | bool2 is a strict
               | logical operation (that doesn't short-circuit). bool1 |=
               | bool2 is a logical operation that will fail when other
               | types are mixed in. int1 |= int2 is a bitwise operation.
               | Java does not have a short-circuiting ||= operation (but
               | ES does).
               | 
               | For the most part these differences aren't that
               | important, but they do trip people up when switching
               | between languages.
        
               | AdrianB1 wrote:
               | How many of the multi-lingual programmers that know 7
               | languages are really good in all 7? As an interviewer and
               | hiring manager I am more impressed of people than know 2,
               | max 3 languages very well than 7 at an intermediate
               | level.
        
               | AnIdiotOnTheNet wrote:
               | I think you overestimate the value of being super
               | intimate with any given language. Pretty much no language
               | in common use is so different from the others that you
               | drastically have to change how you express any given
               | thing you're trying to do. Knowing concepts and when and
               | how to apply them is more important in my considered
               | opinion.
        
               | Frost1x wrote:
               | In my opinion, if you're hiring for an expert in a
               | specific language, you're not hiring a software engineer,
               | you're hiring X language developer or X language software
               | engineer. The language needs to be explicit in the
               | position listing and perhaps even job title. That's fine
               | if that's what you want but be specific about it so you
               | don't waste people's time looking for a language
               | specialist when most people anymore are generalists that
               | have all sorts of knowledge distributions for any given
               | set of technologies but can most likely adapt and learn
               | to fit your distribution of technology given just a bit
               | of time and opportunity.
               | 
               | Modern development requires juggling too many
               | technologies for most people to specialize in a single
               | language unless their career goal is to niche themselves
               | to that language.
        
               | megous wrote:
               | Someone doing webdev fullstack for more than 10-15 years
               | will know at minimum ES + (PHP/Python/Ruby/Java/Go...) +
               | SQL + HTML/CSS and a few utility languages.
               | 
               | So at least 4. If you combine webdev with something low
               | level/embedded, you need at least one systems language,
               | so you're at 5 languages you need to be proficient in.
               | 
               | Add one hobby language or a second web backend or systems
               | language, and you're at 6 major languages.
               | 
               | 7 is a lot. But 5 is plausible to be proficient in for
               | someone who switches between webdev and lowlevel stuff to
               | not burn out, or has a FOSS hobby.
        
               | ryoshu wrote:
               | I've shipped production code in 17 different programming
               | languages. I wouldn't say I'm proficient in any one of
               | them, they are all just tools to solve a problem and the
               | knowledge of language specifics comes and goes. Need to
               | hyper-optimize a DB query on an Oracle RAC cluster?
               | PL/SQL. Need a shader? GLSL works fine. Need a webpage?
               | HTML/CSS/JS. Need to build a 7' long flying robot fish?
               | C. Programming languages are just tools.
        
               | AdrianB1 wrote:
               | In over 20 years of working in IT I never found a single
               | webdev-type of person that can write an efficient SQL
               | query by himself. Yes, most are able to write a query to
               | bring the correct result, but I saw way too many cases
               | where the perf test on a database with the expected
               | production volume was running in completely inacceptable
               | times and the developer had no idea how to fix that; for
               | each version of SQL perf-tuning is very specific.
               | 
               | Also proficient != expert. I met enough developers that
               | were brilliant in their work to be convinced that 5x
               | developers are not a myth, but they are real, while rare,
               | occurrences. For me a senior developer in X knows the ins
               | and outs of that X to the level that his code is an order
               | of magnitude better in term of efficiency, performance,
               | productivity and security. A regular developer can be
               | just proficient, but it is not what I wrote about.
        
               | ryoshu wrote:
               | As a hiring manager for over 15 years I prefer people who
               | can pick up a language based on the need. Good problem
               | solving is language agnostic.
        
               | AdrianB1 wrote:
               | It is an option, but how fast will they be very
               | efficient? It takes years to master something and some
               | people, not all, need to have that mastery level.
        
               | handrous wrote:
               | I know what a language _ought_ to be able to do and where
               | the usual foot-guns are. I haven 't even attempted to
               | really learn a _language_ thoroughly since my first one
               | (Perl--and yes, that 's probably part of where my brain-
               | damage comes from). It's all the same stuff, more or
               | less. Understand pointers and how things like how OO
               | systems are usually implemented, how stacks work, that
               | kind of thing, and all the languages start to blend
               | together.
               | 
               | 99% of the pain in a new language usually ends up being
               | the (often god-awful) tools, platform/SDK bullshit, and
               | learning where the clearest path is incorrect (no no no,
               | the official docs and tutorials say to do it this way,
               | but _everyone_ who knows what 's what actually replaces
               | that entire part of the language/first-party libraries
               | with this other library developed & open-sourced by some
               | other company, since the official way is obviously so
               | terrible, and you just have to know that, or notice by
               | reading other people's projects--ahem, looking at you,
               | Android). The language itself is typically nothing.
               | 
               | This has worked out fine for me. It does mean I've
               | gradually grown to hate languages that lack static
               | typing. I don't want to remember or look up things when I
               | can make a quick note and then let the computer remember
               | or look it up for me. I thought that was kind of our
               | _whole thing_ , no? Having computers do stuff for us,
               | when they're able?
        
               | smt88 wrote:
               | I see this attitude in the corporate world and among
               | people who are newer to programming a lot.
               | 
               | For skilled, experienced programmers, most mainstream
               | languages become an implementation detail. You have to
               | spend time learning idioms, footguns, and generally the
               | way the language manages memory, but you _absolutely can_
               | be great at 7 languages because they fundamentally do
               | many of the same things.
               | 
               | I haven't hired people based on "their stack" in a long
               | time, and it's been completely fine. Someone with skills
               | can quickly learn your stack and be productive in it. I
               | personally jumped on a project as a coder a few years ago
               | having never written C# before, and I was productive in
               | about a day. All the concepts were familiar, and the
               | stuff I had to learn was mostly syntax.
        
               | rimliu wrote:
               | Exactly. "If a person can drive a Honda, how well can he
               | drive a Mazda?". Duh, just as well as Honda. And just
               | like the natural languages, the more you know, the easier
               | it gets.                  > All the concepts were
               | familiar, and the stuff        > I had to learn was
               | mostly syntax.
               | 
               | This reminds me how I have learnt to program. I grew up
               | in then USSR, we had no computers at our school but we
               | had programming lessons. So I was introduced to all the
               | fundamental concepts: variables, assignment, loops,
               | control structures, etc. When I went to university I
               | finally got access to the computer (Yamaha MSX). And then
               | it was exactly as you say: "what's MSX Basic's syntax for
               | this particular concept?".
        
               | AdrianB1 wrote:
               | If a pilot is only type-rated to fly an Airbus 320 he is
               | not allowed to even try to fly an 737 nor a different
               | type of Airbus. This attitude of "a car is a car, what
               | can go wrong?" is deadly in some domains.
        
               | AdrianB1 wrote:
               | In my (corporate) role most of the people around me have
               | over 20 years of experience in a very specific domain
               | (manufacturing execution systems) and it takes about 5
               | years to train a new person. Having someone new
               | productive in month is a dream for us, but it never
               | happened.
               | 
               | If you can be productive in about a day, please explain
               | why a pilot gets ATPL (airline transportation pilot
               | license) after a minimum of 1500 hours of flight. Also
               | please tell if you would board a plane where the pilot
               | has 100 hours - that's an awful more than a day or even a
               | week.
        
               | smt88 wrote:
               | > _they can also be crutches_
               | 
               | Yes, they are absolutely crutches. All great tools,
               | libraries, and abstractions are crutches. I _want_
               | programming to be easier for myself and my employees.
               | 
               | The only problem with a crutch is that you might end up
               | not having it when you need it. That's not an issue in
               | this case.
               | 
               | > _here I am thinking about something more substancial
               | then just a missing ';' or a lack of a closing "_
               | 
               | The original example that I was responded to was about an
               | interviewer who expected their code to compile. That
               | would include incredibly pedantic things.
               | 
               | For example, if you're the kind of person who uses single
               | quotes in JavaScript and then you're suddenly writing a
               | different language where '' is different from "" and ``
               | and $"" and whatever, you could easily make an
               | unimportant mistake that prevents compiling.
        
               | beberlei wrote:
               | Yes! Because the IDE cannot help in Github Pull Request
               | reviews for example.
        
               | rendall wrote:
               | If a company did not run automatic tests and lints on
               | whatever they felt was important to have when merging to
               | production, to the fullest extent possible, I would stop
               | everything and write those. This leaves reviewers free to
               | focus on the intangibles: architecture, expressiveness,
               | logic and data flow, and so on.
        
               | RHSeeger wrote:
               | In my experience, Pull Requests aren't about catching
               | syntax errors... the build will fail if there's errors
               | like that. Rather, a Pull Request, and the code review
               | involved, is about the underlying logic of the code; both
               | with what it's doing it and how it's doing it.
        
               | [deleted]
        
               | ladberg wrote:
               | Design mistakes maybe, but syntax errors are just not
               | representative of any real debugging experience IMO.
        
               | rwmj wrote:
               | I think some of this is filtering out bullshitters. In a
               | previous job I used to interview a lot of unfiltered
               | candidates. What we did was sit them down at a Linux
               | command line and ask them to show us the files in the
               | directory, open a file for editing and that kind of
               | thing. A surprising number of people who claimed years of
               | Linux experience had clearly never used the command line
               | at all.
        
               | roland35 wrote:
               | I've tried questions like this (super basic but can
               | quickly filter out people who know nothing), but
               | sometimes the candidate seems insulted! I try to quickly
               | move on to a harder question.
        
               | hdjjhhvvhga wrote:
               | If you start with "I'm sorry if you find this question
               | offensie, but recently we had a wave of candidates who
               | had problems with basic things so we need to start from
               | the beginning" and the candidate still feels offended,
               | well, they're being offended too easily which might cause
               | problems in the future.
        
               | lordnacho wrote:
               | I don't think the problem is offending the ones who know
               | how to do things. It's making them think they're applying
               | for a worthwhile job.
               | 
               | I remember thinking what you're writing about there, that
               | there's a lot of people to be filtered out, and that good
               | candidates wouldn't be offended.
               | 
               | So we had this simple two-part quiz question for people,
               | starting with "what is the expectation of a dice roll?".
               | Amazingly a lot of people can't figure this out.
               | 
               | But also a lot of people know the answer immediately and
               | will wonder WTF you are asking such a simple question
               | for. I remember this one lady who interviewed with my
               | firm, the look on her face when she realized we weren't
               | asking anything complicated. You could just tell she
               | thought we were a bunch of amateurs, and she'd better be
               | on her way to see some other proper hedge funds.
        
               | unishark wrote:
               | I think people can still find it off-putting that after
               | all the evidence they provided you to get to that point,
               | you're challenging them to prove they aren't complete
               | frauds. Like you could has spent 30 seconds googling them
               | and verify they are legit, but it seems you didn't even
               | bother to read their resume. Not saying it's the case,
               | but rather that not everyone is aware of how good the
               | frauds can be at presenting themselves and bullshitting
               | through interviews.
        
               | zealsham wrote:
               | How did people like this even make it to the interview
               | rounds
        
               | rwmj wrote:
               | Sadly because in that disfunctional start-up we didn't
               | pre-screen except to have someone look through their CV
               | to check that boxes were ticked :-(
               | 
               | But I think the point in this thread is the Google
               | question about Linux inodes was actually part of a pre-
               | screen interview done by an outside agency.
        
               | Terr_ wrote:
               | I could see it if you're resume talks about a whole bunch
               | of intense recent development in the exact same language
               | they want to test, but only then.
               | 
               | In contrast, I've been stuck in a giant multi-language
               | integration-fest, and... well, there are definitely
               | languages on my resume that I would not be comfortable
               | being pop-quizzed on, simply because I've been using
               | others for the past two years.
        
               | agent327 wrote:
               | I've been doing C++ full time since 1996, and yet I
               | frequently have intellisense warning me about forgetting
               | something silly - like a missing capture in a lambda, or
               | even forgotten semi-colons. That's because I'm not an
               | f'ing compiler.
               | 
               | _Can_ I make sure the code is 100% correct before even
               | compiling? Sure, but I'll spend an hour checking every
               | detail, while intellisense does it while I type.
        
               | HWR_14 wrote:
               | I mean, yes. In a whole program, typos or mistakes
               | happen. No need to try to prevent those. So do spelling
               | or grammar errors when writing in English. We expect a
               | professional writer to have a human editor to catch those
               | and not be perfect. But asking an applicant for a writing
               | job to find the spelling/grammar errors in a paragraph
               | seems reasonable to me.
        
               | agent327 wrote:
               | The simple fact that you think so tells me that you
               | aren't a programmer, and that you should stay far away
               | from interviewing or managing programmers. About the only
               | thing the two situations have in common is that both are
               | based around a text-based medium; for the rest there is
               | just no comparison between writing computer code, and
               | writing text for humans. Have you ever noticed how very
               | few people can actually write both good computer code,
               | and good documentation for the users of that code? That's
               | because they are completely different disciplines,
               | requiring a completely different mindset.
               | 
               | Let's turn this around: if I were interviewed by someone
               | who flagged down my code for missing a #include or lambda
               | capture (both very easy mistakes to make), I'd know that
               | the people I'm interviewing with are idiots with no
               | understanding of the thing they claim to be testing me
               | on. Would I want to work there? Nope.
        
               | [deleted]
        
               | HWR_14 wrote:
               | You seem very confused. At first I was worried you
               | misunderstood my text: maybe you have trouble with
               | natural language but not programming (or maybe English
               | but not code). That would certainly explain your claim
               | that they are disjoint skillsets. But as you went on, you
               | committed a logic error, so now I'm just thrown.
               | 
               | There is a difference between "find the errors in this
               | provided code" and "write code on a whiteboard with no
               | errors". At no point was I talking about code you wrote.
               | 
               | Also, it's an aside, but I find people who can program
               | well write excellent documentation for the users, if what
               | they are writing is an API. Of course, they are not the
               | best at explaining the steps in a GUI, but that probably
               | has less to do with communication skills in general and
               | more to do with the difficulty understanding how they
               | perceive the problem.
        
               | rplnt wrote:
               | e.g. a compiler
               | 
               | But yeah, I think I've seen questions like that for an
               | intern positions. It's basically a "have you ever seen
               | this language?" to weed out people quickly.
        
               | baobabKoodaa wrote:
               | > It's basically a "have you ever seen this language?" to
               | weed out people quickly.
               | 
               | It's not that. People who constantly use multiple
               | languages in an IDE will not be able to point out most
               | syntax errors outside the IDE. So it's not a "have you
               | ever seen this language" filter.
        
               | trinovantes wrote:
               | It was for a junior c# position so I doubt it's
               | applicable considering Visual Studio will point out the
               | problems.
               | 
               | But I'm curious what position would this question make
               | sense?
        
               | burntoutfire wrote:
               | It doesn't sound that stupid, it checks whether you know
               | the syntax of the language you'll be programming in.
        
               | mns wrote:
               | It's literally asking someone to write perfect code in a
               | time limited situation, under pressure, how can someone
               | with any kind of coding experience ask someone else to do
               | in an interview?
        
               | killtimeatwork wrote:
               | It not literally asking to write any code, just to read
               | it.
        
               | coldcode wrote:
               | Not one person ever code reviews code that was not
               | already compiled. Requiring you know the syntax of a
               | programming language (in my case, Swift, changes syntax
               | in every release) outside of a compiler is pointless. I
               | remember in the early days of J2EE people asking you for
               | the home interface of an EJB stateful session bean. Like
               | who the hell cares about memorization in the era of
               | Google, and that was 20 years ago when Google did no
               | evil. This isn't first year computer programming 101, you
               | are paid to make things that work, not regurgitate
               | syntax.
        
               | exdsq wrote:
               | Depends... imagine getting four pages of C# code and
               | having to play Where's Wally but you're not even sure
               | what Wally looks like. Surely it'd be better to just
               | write FizzBuzz.
        
               | michaelt wrote:
               | _> I 'm curious what position would this question make
               | sense?_
               | 
               | I was once asked a similar but better posed question: I
               | was given some code and asked what I'd point out if asked
               | to do a code review on it.
               | 
               | And the code had loads of things wrong with it, from bad
               | variable names and incorrect comments, through unit tests
               | that didn't have any assertions and loops that weren't
               | actually loops, all the way to choosing a non-secure
               | random number generator in an application that needed a
               | secure one*
               | 
               | In other words, it was a test of my ability to code
               | review, with some glaring issues to give me some easy
               | marks and set me at ease, and some subtle issues where
               | talented people could really set themselves apart. It was
               | fair and relevant to the job because I was presenting
               | myself as a senior programmer with lots of experience
               | doing code reviews and coaching junior developers.
               | 
               | It's possible trinovantes's interviewer intended to give
               | the same sort of test - but either didn't explain the
               | question clearly enough, or trinovantes misheard or
               | misremembered.
               | 
               | * A bug right out of puzzle 94 in 'Java Puzzlers'
        
               | RHSeeger wrote:
               | I tend to believe that "walk me through a peer review of
               | this code" is a great interview question. It speaks to
               | the user's familiarity with the language, with problem
               | solving in general, and also people skills. Sure, it's
               | not the end all/be all, but someone needs to be pretty
               | amazing to want to work with them if they are incapable
               | of doing a peer review.
        
               | whynaut wrote:
               | This is awesome and I think every company should do
               | something like this. You get to ballpark technical
               | ability really well while getting some very relevant
               | behavioral information (i.e. what will it actually be
               | like to work with this person, without lame 'culture fit'
               | questions). It can be hard to test competence in a way
               | that allows all kinds of devs to shine; code reviews are
               | pretty unavoidable on the job though so it's a good fit.
               | 
               | Coding is a mostly solitary activity that you probably
               | don't want candidates spending more than ~60 minutes on,
               | ideally on something that resembles the actual day-to-day
               | instead of sucking all the Leetcode possible out of them.
               | Even just quickly pair programming on something nets you
               | more data points in the same time.
        
               | w0mbat wrote:
               | Citrix gave me a page of code which had a lot of tricky
               | obfuscated syntax problems. Code that looked live but was
               | actually commented out, nested comments that were not
               | terminated properly, code formatted in a very deceptive
               | way, strings that were not quoted correctly so they would
               | not end where expected on the page. It was all very
               | contrived stuff that was deliberately deceptive, not like
               | real broken code, and the errors would have shown up with
               | syntax highlighting. I caught most but not all of the
               | tricks. This is also the only interview I have ever had
               | where a panel of engineers stood behind a desk and all
               | barked questions at me. I did not get the job.
               | 
               | At a different interview, this one with Microsoft, the
               | lead engineer showed me a page of actual code from their
               | app and asked me what I thought. Luckily the bug
               | instantly leaped off the page to me, although many people
               | would not see it. That was a good way of proving that I
               | have a useful ability, and a better use of time than
               | whiteboard coding or quizzes. I got the job and they were
               | glad they hired me.
        
             | tsukikage wrote:
             | A past employer of mine used to have one of these. It was a
             | true work of art: around two dozen lines of code with
             | something to discuss in EVERY SINGLE LINE, ranging from
             | dumb syntax errors to logic errors to problems of overall
             | design. Made for some great conversations.
        
               | skeeter2020 wrote:
               | The problem I see is that it probably looks really dense
               | and complex the first time a candidate sees it. This is
               | not a great way to start the interview. To me it comes
               | across like "find Waldo in the next 30 seconds. Also
               | there's a bunch of other characters hidden in there. Go!"
               | We all know what we're looking for (kind of) but it's a
               | very stressful approach. It might work better if you
               | paired and wrote this crazy code, and looked to them to
               | identify issues as you built it up.
        
             | skeeter2020 wrote:
             | What is super frustrating is that these same companies and
             | people are convinced they can find game-changing
             | productivity gains in software development, like magnitude-
             | level improvements, yet ask questions that, what little
             | increases we've made in the past 50+ years have made
             | trivial.This is just a lazy question.
        
             | dspillett wrote:
             | Done right there will be a lot more in there than syntax
             | errors. A good example of this sort of test will separate
             | those who have revised syntax without really thinking
             | (they'll get the syntax errors but little or nothing else,
             | great if you want to employ a human linter) from those who
             | actually think about what they are looking at will spot
             | much more (a logical error that would cause an infinite
             | loop, a point where a comment and the code disagree, an
             | incorrectly validated input, an injection flaw, a heavy
             | expression inside a loop that could be done first and
             | result-cached for efficiency (your compiler cannot always
             | identify such situations), hard-coded credentials, bad
             | naming, ...). The best may identify some but also state why
             | in the grand scheme of things is might not matter
             | (efficiency in code that runs once so 10ms and 100ms is
             | statistical noise) or where other priorities might take
             | precedence (for example readability and therefore ease of
             | maintenance).
        
               | read_if_gay_ wrote:
               | Does this kind of trick question work well in practice?
               | If they explicitly ask for syntax errors it would be a
               | waste of time to also check the code for other errors. I
               | can't imagine many people opting to do that unless they
               | know it's a trick question.
        
               | flemhans wrote:
               | If you'd see an obvious SQL injection, wouldn't it be
               | hard to resist telling them?
        
               | scrose wrote:
               | I don't see what information people can glean from those
               | trick questions.
               | 
               | Any time I've interviewed people I've made it a point to
               | emphasize that none of my questions are trick questions
               | and if anything is unclear, they should ask clarifying
               | questions. The result? Interviewees are more comfortable
               | and are far more honest about what they know, what they
               | don't know, and you get to see a glimpse of what they're
               | really like.
        
               | dspillett wrote:
               | It shouldn't be a trick question, but an open one. "What
               | can you see wrong in this code?, there are a few things,
               | we don't expect you to see them all". For non-junior
               | starters it is effectively a simulated code review -- can
               | this candidate spot problems before they get committed
               | further into the pipeline (and hopefully avoid them in
               | their own code).
        
             | robinson-wall wrote:
             | More than a decade ago I had an amazon interviewer write
             | some perl on a whiteboard, and ask me to find the error.
             | 
             | There were two - I pointed out both and they didn't seem
             | super happy about it. To this day I'm still not sure if one
             | of them was an unintentional error.
        
           | MattGaiser wrote:
           | A friend encountered this with Amazon, although their tool at
           | least has some code help (at least when I tried a year ago).
           | The interviewer tried to compile his code.
        
           | [deleted]
        
           | TGImemegen wrote:
           | Googler here. At some stage of the interview process, we have
           | to check whether you're able to code, there's no way around
           | it if you're applying for a coding position. So yes, we'll
           | have you code the solution to a problem. Of course in the
           | real world we'd use a library or look up the algorithm on
           | stack overflow like everyone else. Good for you if you came
           | up with a workable algorithm for the problem quickly. But
           | that's not the only point of the interview. An important goal
           | there is to check if you can really code. We don't usually
           | care if you don't know find the perfect algorithm (unless
           | it's for a senior position), and in fact it's a desirable
           | property if you don't, because that allows us to see your
           | thinking process. Some of the best interviewees I've had,
           | they didn't have the right solution, but impressed me with
           | how they thought about the problem and dealt with the
           | situation of having a problem in front of them that they
           | didn't know how to solve. How they considered possible
           | boundary conditions and restrictions and extensions. Someone
           | saying "yeah, this is just depth-first-search" and then spits
           | up a memorized solution gives me zero insights on whether the
           | candidate is good (and will likely not allow me to write
           | great feedback on the candidate, unless they're able to sell
           | me that they understand what they are doing and why and how).
           | It's usually expected that most of the interview will be
           | taken up by you implementing some algorithm, and it's
           | expected that you won't get every detail right.
           | 
           | We do NOT require you to produce token-by-token perfect code,
           | and nowhere in the process will I ever have to give feedback
           | on whether the code produced was actually valid. So maybe you
           | misunderstood your interviewer's intention, or something else
           | went wrong, or maybe they were just joking. But it's not the
           | interviewers task to copy code into GCC and try it out,
           | that'd be a huge waste of time. So let me be very clear and
           | explicit: no-one gets classified as "no hire" because they've
           | forgotten a semicolon somewhere. You messed up somewhere
           | else.
           | 
           | With that said, if a candidate says they can write in a
           | language, we expect them to know the language, its idioms and
           | at least parts of the standard library. Not every nook and
           | cranny (e.g. I'd often instruct candidates "just pretend you
           | have some library that implements a heap, and invent an API
           | for it, I don't care about that part"), but if you call
           | "strlen" in the termination-condition of your for-loop
           | instead of before, or do other stuff that shows you don't
           | know the language well, that's a red flag. After all, we
           | expect you to be able to write production-level code that
           | servers billions of users.
        
             | gregkerzhner wrote:
             | This statement "we don't usually care if you don't know
             | find the perfect algorithm (unless it's for a senior
             | position)" made me chuckle.
             | 
             | I can see this interviewer writing feedback like "Well,
             | this candidate didn't come up with a perfect implementation
             | of Dijkstra's shortest path algorithm, but its OK, they
             | were pretty close. Oh wait, they are a senior engineer?
             | Nevermind... they should have really mastered these
             | algorithms while building CRUD APIs all these years."
        
             | bborud wrote:
             | Well, in real life this varies. I've seen interviewers from
             | among the first 200 Google employees, nitpick their way
             | through someone's whiteboard code, obsessing over every
             | comma and semicolon. It was embarrassing. And I have to say
             | that while shadowing these interviews I couldn't help but
             | think "I've seen your code - you have bigger problems than
             | getting the syntax perfect, mate" (about the interviewer).
             | 
             | It depends on who you get as your interviewers, so
             | generalizing isn't really useful. Some interviewers can't
             | relate the interview to what it is supposed to tell you.
             | I've seen that in inexperienced interviewers and I've seen
             | that in very experienced interviewers who had enough GOOG
             | stock to buy a small country.
             | 
             | If the interviewer can't think of a better way to test
             | candidates, that's on the interviewer. Not the candidate.
        
             | fidesomnes wrote:
             | I would never want to work with someone like this.
        
             | luffapi wrote:
             | How does Google interview for product development skill?
             | That's seriously lacking in that organization, definitely
             | the worst of the FANGs.
             | 
             | The arrogance displayed in your comment isn't backed up by
             | the ultra-low quality of product being produced by Google.
             | Something is clearly wrong with the culture and hiring
             | process there. Maybe instead of fretting over people using
             | strlen as an exit condition, you should look for people who
             | can actually produce software people enjoy using. You don't
             | even need to do a coding interview! Just browse GitHub for
             | people you want to hire and get to work convincing them to
             | join you.
        
             | tchalla wrote:
             | > So let me be very clear and explicit: no-one gets
             | classified as "no hire" because they've forgotten a
             | semicolon somewhere. You messed up somewhere else.
             | 
             | How much money can you bet that this never or does not
             | happen? If you can't put your money, I find it difficult to
             | take this seriously.
             | 
             | > We don't usually care if you don't know find the perfect
             | algorithm (unless it's for a senior position)
             | 
             | The unless clearly means that you "do care".
        
             | notJim wrote:
             | This is all ridiculous. Of course you have to test that
             | people can code, but it doesn't follow that people must be
             | able to code without any references available, or without
             | using standard libraries. I can code just fine, but I still
             | have to look up the arguments to functions I don't use very
             | often, etc.
             | 
             | As far as algorithms/data structures, most of what we do on
             | a day-to-day basis is more about selecting the appropriate
             | data structures and algorithms that fit the problem, and
             | assembling them together correctly. I've never needed to
             | code a hashtable, but I need to think about their
             | characteristics and whether they're appropriate all the
             | time. I've never written a btree, but I do understand
             | database indices pretty well. So in my view, asking
             | candidates to code up these things on the fly in an
             | interview with no reference materials is a total waste of
             | time. What matters more is if they can correctly apply
             | them. If you're really sure someone needs to write these
             | things, then a more realistic move would be to sit them
             | down with a standard textbook or paper and see if they can
             | get the code working.
             | 
             | > After all, we expect you to be able to write production-
             | level code that servers billions of users.
             | 
             | And you do all this through sheer clairvoyance, rather than
             | using tools like unit tests, code review, design specs,
             | etc, right? No? Then why are you expecting people in
             | interviews to do it without those things.
        
             | cheschire wrote:
             | There's enough counter anecdotes here on HN when this topic
             | comes up that the wording of your post comes off as tone
             | deaf. You actually seem to believe every interviewer at
             | Google behaves like you, for the same reasons, to the same
             | standards.
             | 
             | "We do NOT"
             | 
             | "You messed up"
             | 
             | "let me be very clear"
             | 
             | "whether you're able to code"
             | 
             | These types of statements come off as patronizing. If your
             | whole process sounded like this, and if you somehow
             | actually do represent a majority of Google interviewers,
             | then it's no wonder so many folks have a distaste for the
             | experience.
        
               | TGImemegen wrote:
               | I tried conveying what I was told when I was trained for
               | conducting interviews, what I've explicitly seen demanded
               | on the interview forms I have to fill out and what I get
               | as feedback from hiring committees. Thus I indeed assume
               | that my opinion represents the majority of interviewers.
               | Whether that assumption is warranted or not, I wouldn't
               | know.
        
             | hownottowrite wrote:
             | "servers billions of users"
             | 
             | And therein lies the problem.
        
           | bborud wrote:
           | I worked at Google and did a fair share of interviews. Two
           | observations:
           | 
           | When you have 3 interviews per week for a prolonged period,
           | you, as an interviewer, are not going to do a stellar job
           | every time. What's worse: you will develop a routine and it
           | becomes very easy to give candidates that do not fit your
           | routine a lower grade. It takes effort on the interviewers
           | part to recognize talent that perhaps doesn't fit your
           | routine or your expectations. If you are not going to end up
           | being a bad interviewer you also have to try to relate what
           | you see in interviews to what you know about work.
           | 
           | For instance I _never_ asked people to code live (mostly on
           | whiteboards back then) because it just isn't a relevant
           | exercise. And I was kind of horrified at experienced
           | interviewers who asked people to code and then got obsessive
           | about small details that the tooling would have taken care
           | of. Absolutely pointless.
           | 
           | The only piece of advice I found useful from the interview
           | training was this: this is the candidate's big day. For you
           | it is a chore, for them it is their big chance. Keep that in
           | mind and respect it. I kept telling myself this for every
           | interview - and some days I felt really terrible because I
           | wasn't properly prepared.
           | 
           | The other thing that horrified me was when we let
           | inexperienced people who had been out of school for less than
           | a year interview people. These interviewers barely knew how
           | to write software themselves, and they'd get even more hung
           | up on irrelevant stuff because they simply had no idea how to
           | be software engineers.
           | 
           | I doubt that I would have done very well in those kinds of
           | interviews because this isn't how I work and it certainly
           | isn't how I teach people to do problem solving. Problem
           | solving requires more time because any even mildly tricky
           | problem worth solving tends to have a lot of facets far
           | beyond picking an algorithm or knowing how to code it up.
           | That's the easy part because for that part, you have books,
           | papers, tools and other people to seek advice from.
           | 
           | Junior programmers right out of school with no engineering
           | experience have no business interviewing developers. They
           | make poor and overly judgemental interviewers and only rarely
           | are able to spot talent if it doesn't fit their template.
           | They also aren't going to fight for candidates that may not
           | fit the imaginary template, but have some special gift
           | because they are junior programmers. It takes a certain
           | amount of balls to say "I know you think this candidate is
           | rubbish, but I see something here and I don't care what you
           | say, I am going to insist".
           | 
           | (btw, statistically, this used to be a good predictor for
           | later success: candidates that were somehow "controversial"
           | in that they didn't make the grade with some interviewers,
           | but displayed something that made other interviewers fight
           | for them)
        
             | neilv wrote:
             | Thanks, these seem like the most thoughtful Googler/Xoogler
             | comments I recall hearing on the topic.
        
             | tchalla wrote:
             | > The only piece of advice I found useful from the
             | interview training was this: this is the candidate's big
             | day. For you it is a chore, for them it is their big
             | chance. Keep that in mind and respect it. I kept telling
             | myself this for every interview - and some days I felt
             | really terrible because I wasn't properly prepared.
             | 
             | Thank you for being kind and respectful.
        
           | bb88 wrote:
           | Back when I wanted to interview at google, I sensed some
           | frustration between HR and the engineering. Some engineers
           | just didn't make good interviewers.
           | 
           | HR wished I had gotten a different interviewer.
        
             | vidarh wrote:
             | I had a recruiter obtain approval to have my technical
             | review ignored because I pointed out so many flaws in it.
             | At that point I had too much of a distaste for the process
             | to continue.
             | 
             | But I kept being approached by Google recruiters, kept
             | recounting what had happened last time and asked if I could
             | expect better this time. None could promise things had
             | improved, and a few did express that kind of frustration.
             | 
             | This was years ago now. Could have changed of course. But I
             | started telling them to go away.
        
               | bb88 wrote:
               | I was getting HR hits like every six months and
               | eventually I told them I would get back in touch when I
               | was ready.
               | 
               | Now I'm getting an email every month from FB, and about
               | ready to do the same with them.
               | 
               | The last time I passed the first and second rounds and
               | Google let me languish on the third round for a month. I
               | still probably would not have made it through, but it was
               | surprising that my candidacy was dropped like that.
        
             | papito wrote:
             | The problem is that many out there try to copy the
             | dysfunctional FAANG interview style. Google was asking
             | those dumb brain-teaser questions for years, which were
             | obviously useless to the naked eye, and then they realized
             | themselves that those were counter-productive.
             | 
             | Yet, you could expect one of those in almost any interview
             | process. Seemingly smart people are ready to jump on
             | bandwagons, too.
        
               | dagw wrote:
               | _Google was asking those dumb brain-teaser questions for
               | years_
               | 
               | Microsoft started doing this, realized it was a bad idea,
               | and stopped before Google even really started this
               | practice. So Google is as guilty of bandwagon jumping as
               | everybody else here.
        
           | sltkr wrote:
           | Let me first concede a few points:                 1. You
           | should have been better informed about the expectations of
           | the interview, so you would have had a chance to prepare
           | yourself.            2. Coding in a Google Doc is a terrible
           | experience. It's a step up from coding on a whiteboard, but
           | that's not saying much. Google has since moved away from
           | both, prefering an online text editor that's not quite an IDE
           | but at least more programmer-friendly.            3. The goal
           | shouldn't be to write 100% correct code without any compiler
           | feedback. That's insane. Still, there is a big difference
           | between "candidate forgot a semicolon once" and "candidate
           | did not know how to write a for-loop without IDE feedback".
           | 
           | But beyond those valid complaints, it sounds like you were
           | also unhappy that you were asked to write any code at all. I
           | don't think that's reasonable. The point of a phone interview
           | for an entry-level SWE is to determine two things:
           | 1. Can they figure out how to solve a nontrivial problem?
           | 2. Are they able to translate ideas into reasonable, working
           | code?
           | 
           | For an algorithm question that boils down to a topological
           | sort, the interviewer will see three kinds of candidates:
           | 1. Those that don't have a clue how to solve it.       2.
           | Those that recognize it boils down to a topological sort.
           | 3. Those that recognize it boils down to a topological sort
           | and are able to implement a solution.
           | 
           | Each of these candidates is strictly better than the last,
           | and Google only wants to hire the third one.
           | 
           | > I didn't remember the exact algorithm so I basically had to
           | re-figure it out on the fly
           | 
           | Yes! That was the whole point of the question! You had
           | already demonstrated that you were at least a "type 2"
           | candidate, so now the interviewer was trying to move beyond
           | that and figure out if you were actually a "type 3"
           | candidate. Nobody expected you to have the exact solution
           | memorized, but they expected you to be able to figure it out
           | from first principles.
           | 
           | > I even similarly mention "in any real situation I would
           | just look this up", but that didn't help
           | 
           | That was missing the point, which was to test your ability to
           | actually implement a solution.
           | 
           | In the real world, if you encounter a standard problem (which
           | happens often, like "I need this list sorted" or "I want to
           | put this stuff in a hash table for O(1) access") you wouldn't
           | even look up how to solve it. You would just call the
           | existing standard library function and move on.
           | 
           | Logically, the problems that you end up spending most of your
           | time on are _not_ of the standard variety, and involve
           | actually thinking about how to break down the problem and
           | actually implementing your intended solution. Those are the
           | problems Google needs you to solve on the job. If you can 't
           | even implement a topological sort from scratch, why should
           | anyone expect you to do anything more complicated than that?
        
           | XorNot wrote:
           | At this point I'm pretty sure FAANG hiring is just a random
           | walk. Every now again someone happens to have looked at all
           | the questions they ask recently for that particular interview
           | cycle (or avoid the trap ones like that) and that person gets
           | hired (and then put on the ad targeting team or whatever).
        
             | saagarjha wrote:
             | You don't pass a FAANG interview by looking up all the
             | questions and memorizing them, you just get a feel for what
             | they'd ask you and learn how to respond with what they
             | want.
        
               | skeeter2020 wrote:
               | That's what they're trying to achieve, but it's imperfect
               | at best, so I'm not sure you can state that professional
               | leetcoders don't get jobs at FAANG
        
             | lordnacho wrote:
             | > At this point I'm pretty sure FAANG hiring is just a
             | random walk. Every now again someone happens to have looked
             | at all the questions they ask recently for that particular
             | interview cycle (or avoid the trap ones like that) and that
             | person gets hired (and then put on the ad targeting team or
             | whatever).
             | 
             | This might actually be part of the retention strategy. If
             | everyone who works at FAANG knows that they're somewhat
             | lucky to get in, regardless of ability, it means they are
             | less likely to jump ship. What's the point in applying for
             | another job when you're already paid well and it's unlikely
             | to end in anything but lost time? You're unlikely to win a
             | 10% lottery twice, given the amount of time you'd bother
             | investing.
        
               | oblio wrote:
               | Congrats, you're discovered why hazing rituals have been
               | a thing for thousands of years!
        
               | eatbitseveryday wrote:
               | One can interview without quitting the current job. That
               | allows for multiple attempts over time while retaining
               | the current status. People may do so to see what pay
               | they'd be offered.
        
               | cainxinth wrote:
               | You're forgetting that it's easier to get a FAANG job
               | once you've already had one. They love to poach each
               | other's people.
        
               | Lio wrote:
               | If that's true it's at least is a change from the "no
               | poaching" agreements that used to exist.
        
               | Twirrim wrote:
               | It's very true, and very natural. It's one reason why
               | FAANG salaries have been getting so high.
               | 
               | If I change jobs, and find myself in a good situation,
               | and need more head-count, I'm going to reach out to
               | people I like that I've worked with before, see if they
               | might be interested in a job change. I know I can work
               | with them, know we'll build good stuff.
               | 
               | There's a constant drive in FAANG to hire more people,
               | most teams have open headcounts. To the degree that it's
               | extremely hard to build up that funnel of candidates. If
               | my team has a head-count of 5, that realistically means
               | I've got to find a bare minimum of 30-40 candidates to
               | enter in to the pipeline from somewhere, to maybe get
               | close to that target. That's a slightly optimistic
               | conversion rate. Now scale that up across a company with
               | thousands of teams that are hiring. Getting that pipeline
               | filled on that scale is crazy. It's just one of many
               | reasons why FAANG go all in on college hiring events.
               | 
               | I can almost 100% guarantee to get someone I've worked
               | with in a FAANG co-worker through the interview pipeline
               | and in to a job. They know their shit, they know what
               | they're doing, and they know what the process is like.
        
               | heavyset_go wrote:
               | It's because the DoJ Antitrust Division came down on them
               | hard in 2010[1], and part of the settlement forbade the
               | companies from engaging in that behavior again.
               | 
               | [1] https://en.wikipedia.org/wiki/High-
               | Tech_Employee_Antitrust_L...
        
               | bigbillheck wrote:
               | > They love to poach each other's people
               | 
               | The 'FA.N.' part of it maybe:
               | https://en.wikipedia.org/wiki/High-
               | Tech_Employee_Antitrust_L...
        
               | Bodell wrote:
               | Sometimes I see articles about a wrongfully convicted man
               | being let out of prison. This usually comes with a cash
               | payment of some sort. The whole we took 20 years of your
               | life, oops, here's a million dollars. Every time I see
               | this though I think 'no, no way does money replace my
               | time.' That's simply not good enough. And not because the
               | payments are usually ludicrously low, but because there
               | is no amount of money that would buy off my life.
               | 
               | Same as there is no amount of money you could give me to
               | end my life, a position which I assume is shared by a
               | vast majority of humans.
               | 
               | Time is not money. It's not even close as an exchange
               | rate. I would never put myself through these types of
               | interview processes (not to mention that I would assume
               | that sort of thing to be indicative of the job itself and
               | company as a whole) because I value my actual life and
               | dignity far and above what I value as an upper middle
               | class income.
        
               | dagw wrote:
               | _I value my actual life and dignity far and above what I
               | value as an upper middle class income._
               | 
               | I am at least 90% sure that part of these interviews is
               | to filter out people who these sorts of views. These
               | employer would much rather have someone who wants to work
               | 100 hour weeks and be the 'hero' over someone who works
               | exactly 8-4 monday-friday and then goes home.
        
               | notJim wrote:
               | IDK, if the interview is just a few hours of misery to
               | get a significant financial upside, it's not such a big
               | deal. People always assume the job will be miserable too,
               | but that varies from team to team. Especially because the
               | salary is high enough that you may be able to save enough
               | to buy your life back if you're careful and have time on
               | your side.
        
               | pintxo wrote:
               | Be sure to price in general life risks like accidents,
               | cancer, stress induced hearth attacks etc. The problem
               | with this approach is, that a non zero number of people
               | will not live long enough to buy their life back.
        
               | notJim wrote:
               | Very fair point, important to try to enjoy every stage of
               | the journey.
        
               | bbarnett wrote:
               | Yes and what this means is that Google, and others, are
               | hiring those most willing to do _anything_ for money.
               | 
               | That always works out well.
        
               | BurningFrog wrote:
               | > _Same as there is no amount of money you could give me
               | to end my life, a position which I assume is shared by a
               | vast majority of humans._
               | 
               | Pretty sure a lot of older parents would take a deal with
               | lethal injection + $1M for their kids to inherit.
        
               | throwaway9191aa wrote:
               | I'll just +1 this as a datapoint.
               | 
               | I am not looking externally until I'm sure I'm done at
               | AWS. I've done 80+ interviews here, and I'm consistently
               | amazed by what drives people to say "The candidate wasn't
               | up to the coding bar". As far as I can tell, you are
               | almost never up to the coding bar. I think we interview
               | so many people just to remind ourselves that if we leave,
               | we aren't getting back in.
               | 
               | Just to head off the "So why don't I argue for change?"
               | questions, I'd rather work on self improvement than fight
               | tooth and nail to make the hiring process a little bit
               | better. I'll let somebody else add that to their promo
               | doc.
        
               | pm90 wrote:
               | You don't need to fight tooth and nail for change.
               | Expressing dissent or disagreement with the status quo is
               | a good start.
        
               | pinewurst wrote:
               | At Amazon, that's considered volunteering for a PIP.
        
               | the_only_law wrote:
               | I remember seeing a comment about Amazon once claiming in
               | order to be seriously considered for a role, you have to
               | be better than 50% of the existing team you'd be coming
               | onto.
        
               | themulticaster wrote:
               | To be fair, that would mean that your ability level is
               | the median ability of the team you'd be joining, which
               | doesn't sound all that far-fetched to me. If the skill
               | level of new hires is always close to the median, the
               | overall team ability should stay the same in the long
               | run. This line of thought obviously depends on the
               | assumption that you can measure the exact ability using
               | just a single quantity.
        
               | QuercusMax wrote:
               | Exactly. Who wants to hire somebody who's dumber than
               | half their teammates? That's a recipe for failure.
               | Assuming inaccurate measurement, you'll actually have
               | some below median, so you need to bias upward or else
               | you'll just end up with a bunch of mediocre eng.
        
               | treis wrote:
               | The logical end to that is that you wouldn't hire half
               | your employees again. When put that way it's pretty
               | clearly an unreasonable standard.
        
               | crmrc114 wrote:
               | Yep, and that point has been brought up ad-nauseum
               | internally. Also Jeff did comment how he would probably
               | not be hired by his own company. I personally saw the
               | business pushing the scales to the point of 'just get
               | them in the door, oh my god we are growing too fast and
               | don't have time for your bickering'. Depending on the
               | business unit and how hungry the hiring manager is that
               | issue of raises the bar can just be a hand wave and 'get
               | em` in'. For some technical positions you have a 'bar
               | raiser' interview you who is often an IC who was promoted
               | to Management ranks and has to serve penance by being the
               | one to conduct countless BR interviews. 99% of them were
               | pretty chill on the Clark/Fufillment side of the
               | business. Cant speak to the Jassy/AWS side of the house.
               | Their concept of BR may be more concrete. We rarely kept
               | people out just because they did not 'raise the bar'
               | since that is subjective as hell and personally I like
               | qualified metrics.
               | 
               | I never interviewed for the AWS side of the house since I
               | knew I wanted free time, and a life.
        
               | kergonath wrote:
               | That's true if we assume that ability does not change
               | with time. But if you have a spectrum of experience in
               | the team, it might be unrealistic to expect rookies to
               | match the median.
        
               | crmrc114 wrote:
               | Inside that is called raising the bar. Often times I
               | would personally aim to find people who were 50% better
               | than the best person I knew in that role. Often times I
               | would still incline on people during their POD. I would
               | just strongly incline with 'raises the bar' on folks who
               | met that rare exception. Honestly I was on the Dave Clark
               | side of the business and we were much more chill about
               | things vs the Jassy/AWS cult. Those dudes might as well
               | be from the moon. So take my statement with a grain of
               | salt. We worked for the same company... but we also
               | didn't, Amazon is just that big.
               | 
               | I had plenty of times where an entire hiring pod would
               | incline on a candidate because they had the soft skills
               | we were looking for in that role and we knew we could
               | sharpen their technical skillset in house. You don't have
               | to be a rocket scientist to work at a FAANG... you just
               | have to be interviewed by a team that is hungry and likes
               | you.
        
               | nobleach wrote:
               | That culture is so foreign to me. Each place I've left in
               | the past 10 years, I'm pretty sure I could go back. I
               | know enough folks or at least have been told by C-Suite
               | that "the door is always open, just give me a call". I
               | went through a few rounds of Amazon interviews in 2020...
               | I don't think I'd ever way to experience that again.
        
             | matthewaveryusa wrote:
             | I interviewed 100s of candidates and there was this one guy
             | that I would pair up with and he never said yes. I'll never
             | forget one candidate absolutely nailed it and his retort
             | was "no, she clearly memorized the answers" so yeah, don't
             | take it personally.
        
             | bb88 wrote:
             | What's funny is that I specifically remember a conference
             | where some library that a google employee wrote was
             | terrible. The one google developer talking about it,
             | disavowed any responsibility of it.
             | 
             | Whatever metrics that google is using in their interviews
             | have probably become worthless in the past decade as people
             | game the system.
        
               | pjmlp wrote:
               | Just check the Android code, specially the early versions
               | looked like "C dev (not even C++) tries to create a Java
               | based framework".
               | 
               | And the NDK clearly is anything but modern C or C++.
        
               | ChrisMarshallNY wrote:
               | Google is famous for having a C++ implementation that
               | eschews a lot of what makes C++ powerful.
               | 
               | I've heard it referred to as "C+-".
        
               | pjmlp wrote:
               | Yes and apparently clang is now suffering from Google not
               | caring about latest C++ compliance.
               | 
               | Apple mostly cares about LLVM based tooling in the
               | context of Objective-C and Swift, Metal is C++14 dialect,
               | and IO/Driver Kit require only a subset similar in goals
               | to Embedded C++, so that leaves the remaing of the clang
               | community to actually provide the efforts for ISO C++20
               | compliancy.
               | 
               | https://en.cppreference.com/w/cpp/compiler_support/20
        
               | logicchains wrote:
               | Yep. If Clang doesn't have C++20 support by the time
               | C++23 is out, I'm pretty sure my workplace at least will
               | completely drop Clang and build solely with GCC. A win
               | for open source, if nothing else.
        
               | kergonath wrote:
               | That's fine. Having 2 (free software) tool sets competing
               | on features is a good thing. Both need to stay relevant.
        
               | TchoBeer wrote:
               | Is clang not also open source?
        
               | GuB-42 wrote:
               | Clang has a permissive license, GCC is (of course) GPL.
               | 
               | Which one is best for open source is debatable.
               | 
               | Permissive licenses make it easier for companies to make
               | proprietary software, or even a closed source version of
               | the original project.
               | 
               | Copyleft licenses (like GPL) are intended to promote
               | free/open source software but they can be a legal
               | headache, which can make users favor proprietary
               | solutions.
               | 
               | On HN, I think that people tend to prefer permissive
               | licenses (but complain when large companies "steal" their
               | work, go figure...).
        
               | Macha wrote:
               | Go is also an outgrowth of the Google idea that was first
               | expressed in their style guide of basically "engineers
               | are too dumb for harder features, let's ban them in the
               | style guide (for C++) or just not have them (for Go)"
        
               | ChrisMarshallNY wrote:
               | But I thought that Google engineers were all genius-
               | level.
               | 
               | Aren't they the company that pretty much requires an Ivy-
               | League sheepskin to be a janitor?
        
               | rualca wrote:
               | It's my understanding that there is a colossal gap
               | between the hiring bar imposed by recruiters and the
               | companies' HR department and what's actually the
               | company's engineering culture and practice.
               | 
               | My pet theory is that HR minions feel compelled to
               | portray their role in the process as something that adds
               | a lot of value and outputs candidates which meet a high
               | hiring bar, even though in practice they just repeat
               | meaningless rituals which only have a cursory
               | relationship with aptitude and the engineering dept's
               | needs.
        
               | unishark wrote:
               | Well there might be a defense of that one.
               | 
               | "Data-oriented programming" (to distinguish from object-
               | oriented) is largely C-style C++ that is written for
               | performance rather than
               | reusablility/abstractness/whatever. In the embedded
               | programming world where performance is paramount, a lot
               | of people have low opinions of many C++ features. One
               | could also never completely trust compilers to implement
               | everything correctly.
        
               | ChrisMarshallNY wrote:
               | I'm not saying that's a bad thing. Google usually has a
               | good reason for what they do (not everyone is always
               | happy with the reason, but Google can always explain why
               | they do stuff).
               | 
               | I come from an embedded background, and understand that.
        
               | amalcon wrote:
               | This one is extra weird to me because I've written a
               | _lot_ of C++. I don 't think I've ever committed a bug
               | related to dynamic dispatch, templates, or some other
               | "fancy" features. Not that I haven't committed bugs, but
               | they're mostly either language agnostic logic issues or
               | things one could have written just as easily in C.
        
               | GuB-42 wrote:
               | How much of the early Android code was made by Google?
               | Android existed for two years as an independent company
               | before Google bought it.
        
               | laurent92 wrote:
               | In my startup I interviewed a 48 years old senior Java
               | programmer with excellent resume, who took 1hr to write a
               | String.contains(), it only worked for the requested 4
               | letters, didn't work if a letter was repeated twice, and
               | didn't work with Chinese characters. At least it had the
               | JUnit. I asked an employee to do it too and he made his
               | code pass the JUnit in 6 minutes.
               | 
               | The candidate hated the interview, claiming it was
               | discouraging. Coding is erratic, talent is strange, it
               | really is a craft and we still don't know how to reliably
               | raise someone to competency.
        
               | mattkrause wrote:
               | But which is more likely?
               | 
               | 1. The candidate was a complete and utter fraud and their
               | previous (and apparently well-regarded) employers were
               | too stupid or negligent to notice this, wasting literally
               | millions of dollars (48-21 * $100,000+).
               | 
               | 2. Something about the interview failed to let this
               | person demonstrate the skills that had kept them employed
               | for two decades. Maybe their mind went blank under
               | pressure, or at the end of a long day. Maybe they got
               | hung up on something trivial (that a quick search---or
               | nudge from the interviewer---would have resolved), or the
               | question was unclear.
        
               | jnwatson wrote:
               | The second is certainly more likely, but I'd wager the
               | likelihood of the first is greater than 10%. I've
               | encountered my share.
               | 
               | There are _so many "developers"_ just faking it, I can
               | certainly understand using a test that would reject 90%
               | of the good candidates if it could reject 99% of the bad
               | ones.
        
               | [deleted]
        
               | stupendoustrace wrote:
               | I had number two happen on an interview recently and I am
               | incredibly happy the interviewer didn't hold it against
               | me. I forgot an otherwise simple word/term, but the
               | pressure of the interview just made my mind go completely
               | blank. I think everyone has a tendency sometimes to
               | forget what it's like to be on the other side, and will
               | hammer on small mistakes, or not consider all the
               | factors.
        
               | mattkrause wrote:
               | Me too!
               | 
               | I'm sure I'm on somone's list of incompetent bozos for an
               | interview that went like this: "Please, describe _Python_
               | programming language. " That's it. I had no idea what I
               | was supposed to be doing, and the two fellows
               | interviewing me would not elaborate.
               | 
               | I talked about what I had done with Python. Stony stares.
               | Do I talked about the nature of Python itself
               | (interpreted, multi-paradigm, lexical/LEGB scope, the
               | GIL). Stony stares. I wrote some trivial programs on the
               | board. Stony stares. Had I brought an actual snake, I
               | might have tried to charm it.
               | 
               | At the end, the CEO told me they weren't overwhelmingly
               | sold on me, but would think about it. Never heard from
               | them again.
        
               | handrous wrote:
               | I've repeatedly had employers _very_ happy with my
               | abilities  & results, and am also entirely sure I've, on
               | a few occasions, convinced interviewers I'm entirely
               | unable to write code and am one of these frauds
               | everyone's sure exist and that they need these coding
               | tests to "catch".
        
               | lumost wrote:
               | To add to this, I've found engineers more likely to hang
               | on time series and string manipulation problems. Likely
               | due to a combination of not having to code low level
               | functions in these areas, as well as infrequently
               | encountering the problem.
        
               | BizarroLand wrote:
               | Sounds like the solution then would be to give
               | interviewers all of the systems and support they would
               | normally have access to on the job and see how well they
               | adapt to a conventional task or an issue that was
               | recently solved by someone in a similar position on your
               | company, and have their result evaluated by someone
               | involved with the implementation or fix.
               | 
               | That would tell you if their workflow would fit your
               | company much more than knowing how to run a coding
               | challenge would.
        
               | lumost wrote:
               | On the other hand, tools tend to be fast to teach and
               | pick up relative to fundamentals. Most companies have
               | rough around the edges tooling that a candidate either
               | wouldn't know about or need a couple weeks to get
               | productive in.
        
               | skeeter2020 wrote:
               | Yes, strings are hard and times/dates have a ridiculous
               | number of edge cases, and sometimes very poor language
               | support. This works both ways though; if the problem is
               | easy enough (calculate average cycle time) it can give
               | you lots of edge cases to discuss and really show how
               | someone problem solves, which is really the point of a
               | programming interview. If someone even mentioned non-
               | english language support that would be enough for me,
               | forget about implementing it.
        
               | lumost wrote:
               | I personally dislike giving questions with too many
               | rabbit holes. My observation on a few questions is that
               | it's a 50/50 shot if the candidate who freezes on a
               | question recognized more nuances than the candidate who
               | didn't which means I'm not getting any data.
               | 
               | Fizz buzz was a great question in that it had pretty much
               | a Boolean success criteria.
        
               | mattkrause wrote:
               | The interviewer needs to be good/prepared to make it
               | work.
               | 
               | If the interviewer only says "Write String.contains that
               | passes these test cases" goes back to playing with their
               | phone, several things may happen. One person will take
               | that absolutely literally ("It's a test; better do as I'm
               | told"), and you'll dismiss that apparent garbage _or_
               | move onto the  "real" assessment where they're hoping to
               | shine.
               | 
               | Another will get bogged down in something the interviewer
               | regards as a distraction, and "waste" a bunch of time on
               | something the interviewer regards as a distraction. "He
               | handled unicode, but not substring matching (KMP or
               | Booyer-Moore) or vice versa." _Maybe_ someone will
               | goldilocks it and hit the right (not-explicitly-
               | specified) balance of (also unspecified) features and
               | time, but...
               | 
               | If you structure it as "Please, do the dumbest possible
               | thing and we'll iterate"--and don't hold that initial
               | pass against them--I could see it working well.
        
               | nuclearnice1 wrote:
               | I would say 1 is possible enough that it's worth checking
               | for. Remember that insanely too hard programming detail
               | is a reaction against a situation where 99% of candidates
               | couldn't program at all.[1]
               | 
               | [1] https://wiki.c2.com/?FizzBuzzTest
        
               | padthai wrote:
               | I interview for my company. 80% of the DS applicants
               | (some of them with SWE background) that apply for our
               | senior positions fail with FizzBuzz or some riddle of
               | similar difficulty. This is already pre-filtering for
               | seniors from established companies. We do not pay bad for
               | the market. They also do equally bad with other FizzBuzz-
               | level tests in other areas that they claim to have worked
               | in.
               | 
               | It is still a very useful test.
        
               | geebee wrote:
               | Thanks for posting. I'm always very interested in hearing
               | form people who mention how ostensibly senior people fail
               | fizz buzz.
               | 
               | My question is: what happens after people pass fizz buzz?
               | Failing fizz buzz is how you filter people out, but it's
               | unlikely that coding up fizz buzz passes the technical
               | screen. What kind of questions do you use to establish
               | this, once you're past fizz buzz?
               | 
               | I've failed far more tech screenings than I've passed. I
               | could easily do fizz buzz, and when I've prepped for an
               | interview, I could some tree and set permutation stuff.
               | But the questions get so much more difficult than this.
               | Since difficulty varies, an example of a difficult
               | question for me is "find all matching subtrees in a
               | binary tree" (at the whiteboard, in 45 minutes). When I
               | got feedback about the no-hire, the explanation was that
               | I had a good grasp of algorithms and made some progress,
               | I didn't solve enough of the problem in code (tight
               | pseudocode would have been ok) in time allotted (again,
               | this was ~45 min at the whiteboard, one in a series of 5
               | one-hour technical exam style interviews during a day of
               | interviewing).
               | 
               | I can't claim to be a great coder. I have understood how
               | to code merge sort and quick sort and more complicated
               | tree structures, and I could do them again if I studied
               | and loaded it all back into short term working memory,
               | but I'm content to know how the algorithms work generally
               | and get back into the details when I need... but when
               | anyone mentioned "Fizz buzz", I do insist on stating that
               | my impression, based on quite a few interviews, is that
               | fizz buzz isn't what is screening out software engineers.
               | Lots and lots of people who can write fizz buzz (and
               | build and print a binary tree pre order and post order,
               | and do dfs and bfs, and solve problems with them) are
               | still frequently screened out.
               | 
               | I'm at the point where I just won't do tech interviews
               | anymore (or take home tests). I won't study for exams or
               | do mini capstone projects for an interview that may or
               | may not work out. I would do these things for a degree or
               | licensing exam, but not for a job interviews. It's just
               | too much of a time sink.
               | 
               | I accept that this may cost me good opportunities (in
               | fact, it has), though of course I don't know if the
               | interview would have gone anywhere, other than costing me
               | another long prep session with "cracking the coding
               | interview".
               | 
               | I'll finish the way I usually do, by 1) acknowledging
               | that you are free to interview how you like, and that
               | nobody owes me a job, and 2) mentioning that many
               | companies complain incessantly about hiring difficulties
               | without realizing that their own interview processes may
               | be filtering out talented people and that nobody owes
               | them an employee either.
        
               | alisonatwork wrote:
               | This is exactly my experience too. Sometimes it's
               | incredible just how little applicants understand about
               | how to develop software. I've even interviewed people
               | where they were allowed to have a web browser and IDE
               | while coding a solution, and they still struggled.
               | 
               | Personally I am a much bigger fan of using FizzBuzz as a
               | gate than an algorithm question. I think algorithm
               | questions optimize for the kind of developer who doesn't
               | mind memorizing algorithms to get a job, which might be a
               | useful skill, but you can test that same skill of
               | memorization using FizzBuzz, and then you don't end up
               | also filtering out people who can code but don't care
               | about memorizing algorithms.
               | 
               | In any case, I always think it's worth using their
               | solution as a jumping-off point to ask other, more
               | language-specific questions. Things like: how would you
               | change this if it was intended for use in a FizzBuzz
               | library, how would you annotate this if you needed it to
               | be injected as a Spring dependency, why did you use a for
               | loop instead of a Java 8 stream (or vice versa), what are
               | the implications of declaring this thing as final or
               | static, can you write a unit test for this, and so on.
               | That's when you can get past the point of memorization
               | into figuring out if they actually understand what they
               | typed, which is helpful to ascertain their level.
        
               | geebee wrote:
               | "how would you annotate this if you needed it to be
               | injected as a Spring dependency"
               | 
               | well, I mean, you get to ask what you like... but this is
               | how you determine if someone understands what they've
               | typed on a conceptual level?
        
               | alisonatwork wrote:
               | No, it's just an opening to discussion. For example,
               | depending on the experience of the person, it might lead
               | to a conversation about dependency injection in general,
               | the transition from Spring-specific to JSR-330 notation,
               | maybe they can give some examples of where Spring-
               | specific annotations are still useful, they could talk
               | about constructor over field injection, or when it might
               | be better to use a static/pure function instead of a
               | bean, all kinds of stuff.
               | 
               | For me there are basically two questions to answer when I
               | am interviewing someone. The first is if they have any
               | real programming ability at all, which hopefully FizzBuzz
               | should answer. (Many people do not pass that threshold.)
               | After that I'm looking to figure out where they could fit
               | into the team, or the company. That means seeing if they
               | are already familiar with the frameworks they will be
               | working with in the position (usually, but not always the
               | case for junior applicants who have held at least one job
               | before), but then also if they can speak critically about
               | some of concepts used in those frameworks, and perhaps
               | compare different approaches that have been taken to
               | solving similar problems over the years (if they are more
               | senior).
               | 
               | It's not a wrong answer if they don't know the framework
               | or the concepts behind it at all, since they might be
               | switching specializations, but that's important to know
               | at the interview stage because they might be better
               | suited for a different role than someone who is deep in
               | the framework and more likely to be able to hit the
               | ground running.
        
               | mattkrause wrote:
               | What proportion of your colleagues do you think are
               | _wildly_ incompetent? Not just a bit sluggish, subpar, or
               | sloppy, but not even remotely able to do something
               | resembling their job description.
               | 
               | There are certainly a few. The job market, being a
               | combination of people who want new jobs and those that
               | can't keep their old ones, is undoubtedly enriched for
               | them.
               | 
               | Even so, it seems unlikely to me that there are
               | _anywhere_ near as many as most people say. You certainly
               | don't have to hire someone who flubs your interview, but
               | you also don't have to assume they are frauds.
        
               | nuclearnice1 wrote:
               | I should clarify I lifted the 99% stat from the linked
               | wiki. I agree it seems high.
               | 
               | I'll estimate zero to 10% wildly incompetent. Many of the
               | folks who aren't able to program find other ways to be
               | useful: Testing, requirements, prod support, sys admin,
               | config. It's not even clear they couldn't program, but
               | maybe came to prefer the other work at some point.
               | 
               | What's your _wildly incompetent_ estimate?
        
               | mattkrause wrote:
               | A few percent maybe, but not as high as 10 percent. It's
               | also not just people who "can't" do it, but also those
               | that aren't motivated or cooperative (for whatever
               | reason).
        
               | LorenPechtel wrote:
               | The problem is the percentage of wildly incompetent
               | applying for your job is a lot higher than the percentage
               | of wildly incompetent overall.
        
               | nuclearnice1 wrote:
               | Didn't mattkrause acknowledge as much in his comment?
               | 
               | > The job market, ..., is undoubtedly enriched for them.
        
               | dnautics wrote:
               | absolutely. The incentives to train for the job search
               | and then apply (and succeed at) a job with zero relevant
               | competency, are quite high. And there are...
               | geographies... which have a deserved reputation of being
               | mills for those sorts of individuals, likely because the
               | economic incentive is even stronger than the median,
               | which I suspect is quite annoying for actually competent
               | people that come from those geographies.
        
               | alisonatwork wrote:
               | The problem is that it only takes one or two wildly
               | incompetent people to completely disrupt the quality of
               | the software. These are the kinds of developers who
               | actively create bugs, usually by building (or
               | copy/pasting) solutions that only work by accident, or
               | who decrease the velocity of everyone around them by
               | generating reams of overcomplicated and brittle code that
               | is hard to test, hard to review and hard to maintain. It
               | costs a lot of management time too, trying to find a way
               | to get them to improve, or to build a solid case for
               | letting them go.
               | 
               | I think the reason why every developer tends to have a
               | story about these sorts of incompetent colleagues is not
               | necessarily because 50% of their colleages are
               | incompetent, but because even if just 2% (one person in
               | the department) or 5% (one person in your larger project
               | team) is incompetent, that can be enough to cause a
               | seriously negative impact.
        
               | dnautics wrote:
               | > What proportion of your colleagues do you think are
               | wildly incompetent
               | 
               | 30%, minimum. I was hired alongside a guy with a
               | fantastic resume. He pushed zero lines of usable code in
               | 4 months. When he left I purged about 20 files which were
               | tests that were just completely commented out (but I
               | guess those count for LOC according to github's crude
               | measure). I would say that not only was he incompetent,
               | he was worth negative (thankfully, nothing critical) -
               | Maybe in order to cover his tracks? he had moved certain
               | classes of tagged tests (e.g. skip, broken) to "ignore"
               | status instead of 'yellow star'/red dot, I now, months
               | after his departure, have a pr reverting those changes
               | months after because I didn't notice he had done that.
               | Thankfully it had not covered up any major defect in our
               | codebase (someone could have left a corner case test as
               | "broken" with the intent to fix it later and wound up
               | forgetting to and sending it to prod).
               | 
               | But hey. Programming isn't that bad. In the physical
               | sciences it was 60-70%.
        
               | laurent92 wrote:
               | I'm the interviewer, I'm still wondering what happened.
               | 
               | This was the introductory question before launching 200
               | threads and asking him to solve the
               | deadlocks/inefficiencies, which was the real question
               | supposed to let him show off his skills in front of my
               | employees, specifically crafted for him because I wanted
               | to persuade my employees he was an excellent hire. So he
               | had a taylored chance to show off his skills but failed
               | at the introductory question.
               | 
               | But on the other hand, how can you be asked "Here's a
               | substring, return true or false if it contains the
               | substring, this is the introduction of 5 questions so
               | don't sweat it" and not just write two nested loops and
               | an if? I'd pass on UTF8 problems, but when you've been
               | working with Java for CRUD apps, you still should have
               | your UTF8 correct. This is how you end up with passwords
               | that must be ASCII because the programmer is bad.
        
               | mattkrause wrote:
               | I've seen an actual Nobel Prize winner get stuck
               | describing their research.
               | 
               | People's brains just occasionally lock up.
        
               | BurningFrog wrote:
               | Unfortunately, both are fairly likely.
        
               | BossingAround wrote:
               | What was the goal of the question? Why did you want the
               | person to implement a contains method? Did you really
               | want to verify they understood String implementation in
               | Java?
               | 
               | And if the candidate was able to do this in 6 minutes,
               | what would you have thought? "Great, let's hire"?
               | 
               | In my humble opinion, the question is a waste of time
               | either way. You'll get much further trying to probe what
               | the candidate does know rather than randomly creating an
               | exercise that you think they "should be able to do if
               | woken up in the middle of the night". People forget how
               | stressful interviews are and how easy it is to assume
               | shared context.
               | 
               | The fact that your employee was able to do the test might
               | be indicative of the fact that you share context with the
               | employee that you did not share with the candidate, thus
               | confirming your bias.
        
               | Lio wrote:
               | > The fact that your employee was able to do the test
               | might be indicative of the fact that you share context
               | with the employee that you did not share with the
               | candidate, thus confirming your bias.
               | 
               | This! When giving interviews last I really worried if the
               | questions I asked where just indicative of my own
               | Dunning-Kruger effect.
               | 
               | i.e. Do I only ask questions I already know the answer to
               | and not questions I don't know the answer to?
               | 
               | If I do then am I just filtering for people with the same
               | background and knowledge and missing out on people with
               | other skills I don't know, because they're in my blind
               | spot, I need yet?
        
               | magnetic wrote:
               | > i.e. Do I only ask questions I already know the answer
               | to and not questions I don't know the answer to?
               | 
               | I've been advocating for a "coding interview" where both
               | the interviewer _and_ interviewee draw some random
               | question from leetcode or other problem bank, and try to
               | work at it together.
               | 
               | This would show collaboration skills, and you can tell
               | pretty easily how helpful the candidate is with his/her
               | contributions, and whether you find there is an impedance
               | mismatch somewhere.
               | 
               | It probably also maps more closely to the kinds of
               | interactions you'd have after the person's been hired.
               | 
               | I think it would also help calibrate: if you can't figure
               | it out, is it fair to expect the candidate to figure it
               | out? Maybe it's just a hard problem!
        
               | mattkrause wrote:
               | Beating up on this example some more:
               | 
               | Multi-lingual support seems _really_ _really_ hard,
               | especially in six minutes. I would think most people
               | would need to look at technical (i.e., unicode) and
               | linguistic references to get it right.
               | 
               | Should does the ligature f l match itself, or the ASCII
               | constituents 'f' and 'l'? How about combining vs. pre-
               | composed characters? Some Chinese characters show up in
               | other languages (Japanese, Korean) and are sometimes
               | split between Hong Kong/Taiwan/Mainland language tags
               | too. In fact, there's a mess of work devoted to this
               | ("Unihan"
               | https://www.unicode.org/versions/Unicode13.0.0/ch18.pdf).
               | Having figured out what you _can_ do, you then need to
               | decide what you ought to do. Not being a Chinese-speaker,
               | I have no idea which options would seem natural....
               | 
               | In fact, having written this all out, there's no way
               | someone "solved" it from scratch in six minutes. It would
               | be a great discussion question though....
        
               | laurent92 wrote:
               | for (int i = 0 to text.length() - substring.length()) {
               | boolean found = true;           for (int j = 0 to
               | substring.length()) {             if (text.charAt(i) !=
               | substring.charAt(j)) {               found = false;
               | break;       }           if (found) return true;
               | }
               | 
               | We're not taking rocket science here. This code already
               | properly handles surrogates and Chinese characters. The
               | question about characters that can be written in two
               | different ways should only be raised as a second level,
               | once the first implementation is done.
        
               | laurent92 wrote:
               | Parent here.
               | 
               | > What was the goal of the question?
               | 
               | This is the introductory question before solving
               | concurrency problems, because it's much easier to
               | understand what a thread does when you've coded the body
               | yourself.
               | 
               | > Why did you want the person to implement a contains
               | method?
               | 
               | The job is CRUD + integrating with Confluence + parsing
               | search queries from the user, so finding "<XML" in a page
               | and answering "Yes! This is totally xml, I'm positive!"
               | is a gross simplification of realistic tasks in the real
               | job (and in fact in most webapps), with characters
               | instead of XML or JSON.
               | 
               | I have the feeling that you think this question is
               | entirely abstract, but I both tailored the exercise
               | because he touted being good at improving app performance
               | on his resume (including using JProfiler) and I took care
               | of using a realistic on-the-job example.
               | 
               | > Did you really want to verify they understood String
               | implementation in Java?
               | 
               | Well, what consumer product _can_ you work on if you trip
               | into all UTF-8 traps? Telling customers "Just write
               | English because we can't be bothered to learn the easy
               | thing in Java that handles UTF-8 properly" is... is
               | acceptable unless he also fails the fuzzbizz test. And
               | once UTF8 is mastered, it's good for life! I wouldn't
               | mind teaching him if he didn't fail the rest, but as a
               | senior you should really know the difference between
               | .getBytes() and .codePointAt(i).
               | 
               | > If the candidate was able to do it in 6 minutes, what
               | would you have thought? "Great, let's hire"?
               | 
               | The 4 other questions were classic gross concurrency
               | errors, tailored because he touted it in his resume and I
               | wanted him to shine. A senior should be able to guess
               | them blindfolded as soon as I tell them "There are
               | concurrency problems", without even looking at the code
               | ;) Volatile, atomic, ArrayList non-synchronized, 200
               | threads for a connection pool of 10, a DB accepting 7 cnx
               | (note the prime numbers make it easy to spot which
               | multiple is causing the issue), and strings of 10MB each
               | with Xmx=100m, if he finds any 3 of the 12 problems, and
               | 2 more with help, I'd hire him. If he ditched the code
               | and postes tasks into an ExecutorService (as they teach
               | in the Java certification level 1), I'd hire immediately.
        
               | bigbillheck wrote:
               | I don't do interviews in my current job (mostly because
               | the pandemic really did a number on hiring) but in my
               | previous job the only coding question I asked was what I
               | thought was a fairly simple string problem. They could
               | assume ascii, use any language they wanted, and make any
               | other assumptions to simplify the problem.
               | 
               | My then-co-workers liked to ask harder algorithmic
               | questions but I wanted to give the candidates a little
               | bit of a break with something easier.
               | 
               | It didn't always work, but at least I tried.
        
               | walshemj wrote:
               | Why would you not use the language built-ins?
               | 
               | I am not a Java programmer but it took me 30 seconds to
               | find the contains() method.
        
               | eloisius wrote:
               | Did they have to write it in a google doc with no ability
               | to compile and run their code?
        
               | notJim wrote:
               | Curious about the age of the person who supposedly wrote
               | it in 6 minutes. If you're fresh out of school,
               | "String.contains" may be top of mind, but the vast
               | majority of people never write that function in practice,
               | so it's easy to not think about.
        
               | wheelinsupial wrote:
               | What was the problem statement you gave to the candidate?
               | 
               | What were you trying to tease out from the problem
               | statement?
        
             | OOPMan wrote:
             | My profile on LinkedIn for the longest time stated "No PHP
             | jobs please" as a way to weed out recruiters that would
             | send me job offers for PHP roles on the basis that I once
             | did some PHP.
             | 
             | I've updated the profile to include "No FAANG companies"
             | because I'm pretty sure I would not be a good fit for them
             | but that didn't stop their recruiters from pestering me.
        
               | __app_dev__ wrote:
               | Good one, I get contacted by Amazon several times a week
               | on LinkedIn to apply.
               | 
               | For my LinkedIn I listed minimum requirements and it
               | saves me 100+ inquiries per week but I still get a ton of
               | irrelevant jobs.
        
               | mring33621 wrote:
               | Ahh, reverse psychology!
        
             | ownagefool wrote:
             | I got an offer for Production Engineering tail end of last
             | year and the interviews were mostly reasonble but the
             | process was mega long.
             | 
             | I took a different offer in the end, but the recruiters
             | reach out every few months for a chat.
        
             | Twirrim wrote:
             | 100%, speaking as someone who's been both sides of the
             | equation in FAANG hiring.
             | 
             | Part of the problem is the sheer scale of hiring, but I
             | think most of the problem comes down to the lack of
             | feedback or evaluation mechanisms on the interviewing side.
             | 
             | They train you up, half a days worth, training tells you
             | not to be an arsehole, not to ask stupid questions, not to
             | have unreasonable demands of candidates, not to be biased.
             | They don't train you in valuable skills like active
             | listening.
             | 
             | Next thing you know, you've done training, and you're
             | interviewing candidates every week or two (or more often),
             | and there is _zero_ feedback mechanism. No one evaluates
             | your interview questions, no one asks candidates to provide
             | feedback on the interviewers. No one looks to see if you
             | 've got unreasonable expectations as an interviewer, or
             | have your expectations set too low.
             | 
             | You do have to do a post-interview group discussion with
             | the other interviewers to make a yay/nay decision, but it's
             | super easy to present what you did/asked in a positive
             | light.
             | 
             | The whole system is designed around the interviewer being
             | right and infallible. Is it any wonder the process is so
             | completely and utterly broken?
             | 
             | edit: > or have your expectations set too low
             | 
             | This is where I bias towards in worrying, imposter syndrome
             | and all that jazz. I've made a conscious choice to not
             | raise that bar higher. I think the questions I ask are
             | good, I think they're set up well enough to encourage
             | candidates to go as deep as they feel comfortable with. I
             | try to design them with no one true answer but have a few
             | in mind so I can go where the candidate goes.
        
               | tschwimmer wrote:
               | I also did interviewing at a FAANG and this was not my
               | experience.
               | 
               | 1. We trained 4-5 times on each type of question. The
               | first few were shadows, and then we did reverse shadows
               | where someone watched us give the interview and gave
               | feedback later. In one category I asked for and was
               | allowed to reverse shadow an extra 1-2 interviews.
               | 
               | 2. There was auditing. In debriefs where you discussed
               | the candidate and reviewed notes, the debrief lead was
               | supposed to closely examine what questions you asked and
               | how you conducted the interview, with the explicit goal
               | of making sure that the interview was conducted within
               | spec and your recommendation made sense given
               | performance. Shortly after I was certified to do
               | interviews, a debrief leader (correctly) identified a
               | major issue in an interview that I had conducted. That
               | candidate was given another interview in the same
               | category. Although I didn't face any official sanctions,
               | it was definitely an embarrassing experience and made me
               | handle future interviews more thoughtfully.
               | 
               | Overall, I was fairly comfortable with the rigor of the
               | process that I saw. I'm certainly not saying the process
               | is perfect but my experience did not align with yours.
        
               | notJim wrote:
               | > No one evaluates your interview questions
               | 
               | Are you saying each interviewer just makes up their own
               | questions?! That's ludicrous if so. Where I work, we have
               | a standardized pool, with standardized evaluation
               | criteria.
        
               | Twirrim wrote:
               | Everyone makes up their own. I can't for the life of me
               | fathom how this doesn't subject them to all sorts of
               | discrimination etc. claims (one of the reasons lots of
               | companies favour standardised questions).
               | 
               | Obviously the drawback for FAANG is that standardised
               | questions would rather rapidly leak. Very quickly you'll
               | just end up with candidates that know how to answer your
               | questions.
               | 
               | Where I work now, it's a mix of pool questions ("soft"
               | skills) and interviewer-made questions (technical
               | skills), but it's not a hard and fast rule to use the
               | pool questions. I rarely use the precise wording for the
               | pool questions, and instead adapt them to match the
               | conversation with the candidate.
        
             | res0nat0r wrote:
             | I've mentioned before but at my previous FAANG gig everyone
             | only looked at the resumes they were assigned to interview
             | like 15 minutes before the interview time was scheduled
             | down the hall / building somewhere.
             | 
             | No one knew who they were interviewing or what was on the
             | resume until they glanced at it while walking to the
             | interview room. I suspect all interviews and the process
             | are just made up as folks go along, and half the time you
             | get a gig or not mostly based on if one of the people you
             | talk to is in a good mood or not.
        
             | rcthompson wrote:
             | I think there's probably one or more "real" filtering steps
             | to start with, but after those steps there's still way more
             | qualified candidates than positions to fill, and at that
             | point the only possible solution is to choose randomly. But
             | that's not "satisfying" so instead they just keep
             | interviewing and finding reasons to reject people (all
             | completely arbitrary, since everyone is already qualified)
             | until they reach the target number, at which point all
             | remaining candidates get offers. Which effectively results
             | in wasting a bunch of everyone's time and then choosing
             | randomly anyway.
             | 
             | (This is a massive oversimplification, of course, but you
             | get the idea.)
        
             | Waterluvian wrote:
             | It may be a random walk but I think the goal is to convince
             | whoever gets hired that they're special and talented and
             | elite members of their discipline.
        
               | skeeter2020 wrote:
               | Oh you mean a real rockstar? a code ninja?
        
               | cptaj wrote:
               | You think they're doing this to make you feel... good?
        
               | ZanyProgrammer wrote:
               | Well they do pay a bit more than 15 dollars an hour. Hard
               | to not feel good about that.
        
               | handrous wrote:
               | Harsh hazing and initiation rituals are a pretty
               | effective way to build team "spirit" and make people
               | believe the group they've joined is special, and being a
               | part of it makes them special or better than non-members.
               | It may or may not be part of why FAANG interviews the way
               | they do, but it is likely part of the outcome.
        
             | AJRF wrote:
             | Geohotz had a good rant about this once - the kind of
             | people who need to cram leetcodes and memorize algorithms
             | are not the kinds of people who Google wants to pass these
             | interviews.
             | 
             | Makes a lot of sense, you could solve all these questions
             | without knowing specific algorithms as long as you are good
             | at problem solving - which is, I assume, the intent of the
             | process.
             | 
             | Obviously it doesn't always work like that.
        
               | sdevonoes wrote:
               | > the kind of people who need to cram leetcodes and
               | memorize algorithms are not the kinds of people who
               | Google wants to pass these interviews.
               | 
               | I thought it was exactly those who Google wants to pass.
               | Anecdote: ex-colleague of mine who is not specially
               | bright studied 3 months how to "crack the coding
               | interview" and got a job at Google. His knowledge about
               | algorithms and data structures was like mine: I know what
               | a tree is, I know there exists operations one can perform
               | on them and some of them are more performant/efficient
               | than others... but I would need to Google how to "reverse
               | a binary tree" if I had to do it in less than 1h.
        
               | pinewurst wrote:
               | I read an article recently about Google's fairly awful
               | interactions with HBCUs (historically Black colleges and
               | universities). One thing that caught my eye was Google's
               | disapproval of seemingly standard CS programs in favor of
               | a syllabus for cramming algorithms into student heads.
               | That was one of their excuses for hiring differentials.
        
               | kwertyoowiyop wrote:
               | I'm trying to think of how many tree structures I've
               | encountered in all the projects I've ever programmed on,
               | in my entire career. Maybe one or two?
        
               | AJRF wrote:
               | You probably aren't the demographic Google want/needs to
               | hire by the sound of it.
        
               | Macha wrote:
               | A perusal of Google's recent software track record would
               | indicate that optimum efficiency aided by a wide
               | knowledge of a library of algorithms and manual
               | implementation of the same is either not what Google
               | actually cares about, or if it was what they think they
               | care about, not effectively delivered by the steps they
               | take to achieve it.
        
               | Macha wrote:
               | A tree for performance? I've used a rope once or twice.
               | 
               | Plenty of times where I've used trees because they're the
               | logical representation of the problem (ever had a field
               | called "children" in your code? HN comments are a tree.
               | Etc.)
        
               | missingrib wrote:
               | >ex-colleague of mine who is not specially bright studied
               | 3 months how to "crack the coding interview" and got a
               | job at Google.
               | 
               | Sounds bright to me.
        
               | tchalla wrote:
               | > Geohotz had a good rant about this once - the kind of
               | people who need to cram leetcodes and memorize algorithms
               | are not the kinds of people who Google wants to pass
               | these interviews.
               | 
               | And yet, they routinely do pass these interviews.
        
               | [deleted]
        
               | keyb0ardninja wrote:
               | > Makes a lot of sense, you could solve all these
               | questions without knowing specific algorithms as long as
               | you are good at problem solving - which is, I assume, the
               | intent of the process.
               | 
               | You could solve all these questions as long as you are
               | good at problem solving, *given enough time*.
               | 
               | However, with tight time constraints and perfomance
               | pressure, the only way you could solve all these
               | questions is memorizing and practicing all these
               | algorithms.
        
               | jiggawatts wrote:
               | There was a hilarious rant about a FAANG hiring question
               | that was something like: "Write an algorithm for
               | detecting if a linked list has any loops in it, in linear
               | time, using a constant amount of memory."
               | 
               | Apparently the correct answer is to use "Robert W.
               | Floyd's tortoise and hare algorithm", which is trivial to
               | explain and code.
               | 
               | The catch?
               | 
               | It took a _decade_ of computer science research between
               | the original statement of the problem and Floyd
               | discovering the solution.
               | 
               | So... no worries, you have an hour, a marker, and a
               | whiteboard. Your time starts: now.
        
               | porb121 wrote:
               | it took a few million years until Newton figured out
               | basic mechanics. but i don't think it's unreasonable to
               | ask a junior engineer some basic kinematics questions!
        
               | mattkrause wrote:
               | Subtly different, IMO.
               | 
               | You're expecting the mechanical engineer to _recall_
               | something they learned about kinematics, not derive it on
               | the spot. It's a test of knowledge, rather than
               | cleverness. The equations of motion are also more central
               | to physics and engineering.
               | 
               | A decent programmer should know that linked lists exist,
               | their general properties, pros and cons, etc. However,
               | cycle detection is not a particularly common operation,
               | so not knowing Floyd's algorithm tells you very little---
               | and their failure to do years of research in 45 minutes
               | even less.
        
               | neutronicus wrote:
               | Yeah, I think a closer analogue would be asking something
               | like "derive the conserved quantities of the
               | gravitational two-body problem" and then dinging
               | candidates for forgetting about the Laplace-Runge-Lenz
               | vector
        
               | RichardCA wrote:
               | It would bias toward people who are comfortable doing
               | basic calculus on a whiteboard.
               | 
               | Also, it took around 13.8 billion years for Newton to do
               | what he did.
        
               | Macha wrote:
               | A software engineer? Sounds totally unreasonable. A
               | mechanical engineer, sure, it's going to be required
               | material on their education.
               | 
               | The tortoise and hare algorithm is not the foundational
               | skill required to make software work the way an
               | understanding of motion is for building structures.
               | That's why it's often omitted from educational material
               | yet these people are able to produce usable software
               | after even something like a bootcamp (which I guarantee
               | basically no bootcamps ever touched this algorithm).
               | 
               | I'm not sure I approve of asking even more well known
               | algorithms like Djikstra's algorithm or A* in a job
               | interview, unless the role was something that
               | specifically required that area of knowledge like
               | building pathfinders for video games or robots or
               | something.
        
               | abledon wrote:
               | ya its dumb, but also CTCI question 4 or something or
               | linkedlist chapter
        
               | gorbachev wrote:
               | Which becomes forgotten knowledge in about 6 - 12 months
               | time after you've last needed to apply it, depending on
               | how often you'd have to use that information.
               | 
               | These sort of questions have an incredible recency bias,
               | and have zero relevance to engineering competence.
        
               | josephdviviano wrote:
               | I have a theory that these q's _legally_ favor recent
               | grads without having any explicit requirement to do so.
               | Helps them filter for young, freshly-trained students who
               | they can mould into whatever they like inside of the
               | FAANG-bubble.
        
               | dragonwriter wrote:
               | > These sort of questions have an incredible recency bias
               | 
               | Of course; how else do you do back-door age
               | discrimination?
        
               | ramimac wrote:
               | This is exactly the point!
               | 
               | If they actually aren't looking for people who just cram
               | CTCI or leetcode, coming to this answer from first
               | principles is demonstrably far more difficult than you'd
               | expect achieved in an interview.
        
               | Verdex wrote:
               | I'm just imagining an engineer coming up with a novel
               | solution to this problem in under the hour deadline and
               | then not getting hired because it's not the "Robert W.
               | Floyd's tortoise and hare" algorithm.
               | 
               | "So we specifically asked for linear time."
               | 
               | "Uh, yeah, I did it in log(n). That's better."
               | 
               | "It doesn't match what's on this paper they gave me.
               | Thanks for your time. We'll be in touch."
        
               | deepGem wrote:
               | It's funny you put it this way. I actually did a couple
               | of hard level Leetcode problems and I thought they would
               | help me immensely in my day to day life in addition to
               | helping me get better at interviews.
               | 
               | No such avail. In fact, unless these algorithms and
               | problem solving methodologies are baked into your memory
               | there's no way you are white boarding a Leetcode hard
               | level problem in an interview.
               | 
               | What I was impressed at an Uber interview was their
               | system design interview process - which basically boiled
               | down to 'how do I abstract retrying a 429 - rate limit
               | exceeded.
               | 
               | What I take is that - the interviewer is expecting a very
               | specific solution even in an open ended system design
               | question. It's like throwing a needle in a haystack at
               | you and expect you to get to the needle in like an hour
               | :).
        
               | skeeter2020 wrote:
               | >> which basically boiled down to 'how do I abstract
               | retrying a 429 - rate limit exceeded
               | 
               | They're probably looking for some sort of variable
               | refilling leaky bucket implementation, which is funny
               | because I believe this is exactly what they do
               | internally. It was probably the task the interview had in
               | front of them in their day-to-day and wanted you to do it
               | for them!
               | 
               | This is a fair design question for a senior role (which
               | this sounds like) that promotes disccussion, but
               | expecting a specific solution is really only testing
               | "does this person match my preconceived ideal for what a
               | <dev> is?" which is really dangerous and has very little
               | value.
        
               | pawelwentpawel wrote:
               | I went through a marathon of interviews for one FAANG
               | company (8 in total - coding screen, 4x in first round,
               | 3x in second round). I did enough preparation to remember
               | quite a couple of the Leetcode solutions by heart. I was
               | pretty much a code printer if I got one of those, not
               | much thinking involved anymore. I reckon it was clearly
               | visible that I've seen a similar question before which is
               | unavoidable if you've done enough prep.
               | 
               | While it's probably not what an interviewer is looking
               | for, having the most common solutions memorised gives you
               | an advantage of time. A coding interview usually consists
               | of two challenges. If you get stuck on the first one and
               | take too much time to answer it, you won't have enough
               | time to go through the second one.
               | 
               | To avoid the code printer perception you can always go
               | through an explanation what alternative solutions could
               | be applied to the given problem, what their complexities
               | would be and why the one presented is the best.
        
               | bcrosby95 wrote:
               | You need to act and pretend to think it through. Then you
               | seem like a brilliant programmer they want to hire rather
               | than someone that recently worked on the problem.
        
               | omgwtfbbq wrote:
               | >Makes a lot of sense, you could solve all these
               | questions without knowing specific algorithms as long as
               | you are good at problem solving - which is, I assume, the
               | intent of the process.
               | 
               | That's just absurd. If someone with no "algorithm"
               | experience who was a good problem solver had to work out
               | an answer from scratch for the interview its almost
               | certain they're going to find the brute force answer and
               | FAANGs pretty universally want the most efficient one so
               | these people would routinely fail.
               | 
               | Its totally clear that what FAANG hiring optimizes for is
               | recent CS graduates who passed tough Algorithm weed out
               | courses at well known colleges in the past 18-24 months.
               | They are young with no families or obligations and are
               | happy to work 12 hour days at Google because they have
               | hip open offices and ping pong tables.
        
               | zealsham wrote:
               | I've always said that FAANG don't hire professional
               | software engineers, they only hire professional leet
               | coders
        
             | crispyambulance wrote:
             | The experiences that people describe here just confirm
             | something that many of us has learned a long time ago:
             | 
             | NOBODY HAS "FIGURED OUT" HIRING !
             | 
             | Not Google, not Apple, no one. Sure, some places (and
             | individual interviewers) are better at it than others. But
             | at the end of the day, hiring is a deeply subjective
             | process with lots of error and uncertainty built into it's
             | nature. The subjectivity is intrinsic.
             | 
             | Places like Google can afford to be nonsensically picky and
             | not suffer drastic consequences from it. They have a thick,
             | never-ending stream of highly qualified candidates. At
             | their volume of hiring, it doesn't matter to them if they
             | screen out some folks that would have been brilliant hires,
             | nor does it matter if they hire some promising but
             | ultimately disappointing duds. All of that is OK.
             | 
             | Sadly, however, it seems that small shops are trying to
             | cargo-cult Google's hiring practices. That IS harmful to
             | the company and the candidates, IMHO. I think folks in
             | these non-FAANG companies should get trained on how to
             | conduct interviews, especially if they're interviewing non-
             | senior candidates. Interviewing is a skill in itself. It's
             | not something that comes automatically with expertise nor
             | is it something that can be left entirely to HR drones.
        
               | heywherelogingo wrote:
               | There's nothing to figure out. Relationships aren't a
               | maths sum. They work out to varying degrees, and have too
               | many variables and depth to predict. But the group of
               | people with a reputation for having maths skills, a
               | reputation for not have social skills are going to figure
               | it out - what could go wrong?
        
               | ghaff wrote:
               | Or you hire people you know. Which isn't perfect, has
               | it's own set of problems, and doesn't scale. But I can't
               | really complain given it's how I've gotten every job
               | (just a few) after grad school and my interviews have
               | been mostly perfunctory.
        
               | ghaff wrote:
               | >The good news is, it's a very open network.
               | 
               | I'll accept the statement. But I will say that hiring
               | from a network is at least a very _different_ thing from
               | hiring through a grueling set of often artificial
               | interview hoops. It requires a potential candidate to
               | have genuinely interacted at a higher than superficial
               | level with a lot of people in a professional capacity.
               | Which may not be harder than  "leet code" but is
               | certainly very different.
               | 
               | And yes, all the big companies have referral programs but
               | that's mostly just a very rough first pass as a lot of
               | referrals are basically I'm connected with this candidate
               | on linked in. Referral bonus please.
        
               | blacktriangle wrote:
               | Here on the other side of the FAANG spectrum working with
               | and for other independent contractors and various small
               | (5-20ish devs) consultancies, I'd say that hiring based
               | on who you know and you your peers recomend is far and
               | away the primary way work is done.
               | 
               | The good news is, it's a very open network. We have a
               | highly active Meetup scene, pretty regular public
               | hackathons, annual small software conferences and un-
               | conferences, and coworking spaces are (well were) packed.
               | 
               | For the most part this has worked, people new to the
               | community are able to find jobs and the people hiring
               | them know what hey are getting. But also like you say,
               | this doesn't really scale to larger operations.
        
               | woofie11 wrote:
               | Pretend there's a Programming Quotient (PQ) which is like
               | IQ.
               | 
               | Let's say Google would like candidates with PQ>130 with
               | 95% confidence. Google has an error with std. div. of 15
               | points in measurement of PQ in jobs interviews. Google
               | then needs to set the hiring bar at 160 PQ in order to
               | get those candidates. This:
               | 
               | - screens most qualified candidates out; but
               | 
               | - most candidates who do screen in are qualified
               | 
               | Statistics would suggest this leaves you with 95%
               | qualified candidates. A more precise Bayesian analysis
               | will show you don't end up with 95% qualified employees,
               | but the basic idea works -- it's still a majority. You
               | set an impossibly high bar, so that candidates hired need
               | to be qualified AND lucky. You discount unlucky
               | candidates, but you don't hire (many) unqualified ones.
               | 
               | The problem, of course, is that all Googlers are
               | convinced they all have a PQ>160, and are superior to
               | everyone else. That's where you get the obnoxious Google
               | incompetent arrogance.
        
               | lifeisstillgood wrote:
               | This is an excellent way of looking at this and many
               | other high bar organisations - thank you !
        
               | woofie11 wrote:
               | It's helpful to explain this to recent grads.
               | 
               | A lot of really good people are discouraged by repeated
               | rejection. However, high levels of rejection of very
               | qualified people are built into this (and many similar)
               | systems. You have to be qualified AND get a lucky die
               | roll to get in the front door. Once people stop taking
               | rejection personally, they can start acting more
               | rationally, and there's less emotional harm. People feel
               | really bad about themselves otherwise.
               | 
               | There are back doors with less luck involved.
        
               | CoolGuySteve wrote:
               | I've used Google's software. I'm not sure they're all
               | that great.
               | 
               | Someone just released a product that offloads Chrome to
               | the cloud. Gmail has a very long loading screen. Hangouts
               | was replaced by something like 4 incompatible apps.
               | Android phones are significantly less power efficient
               | than iPhones. YouTube copyright notices are trivial to
               | game. Etc
        
               | nobleach wrote:
               | The number of things Google farms out to "the
               | contractors" is crazy. I've talked to a few folks that
               | got to work in the big beautiful facility but, the code
               | they were writing was the worst, "pound it out, who cares
               | how it looks or how well it performs" quality.
        
               | woofie11 wrote:
               | I think the bar I gave, PQ of 130, is about right for
               | Google. Your typical Google programmer is pretty bright
               | and pretty competent, but not spectacular.
               | 
               | Most of what makes big companies succeed or fail is in
               | the overall culture, organizational design, incentive
               | structure, and corporate structure -- properties of a
               | network of individuals rather than of those individuals
               | themselves. I think most of Google's success and failings
               | can be explained that way, much more so than the success
               | or fault of employee quality.
               | 
               | Organizational design is really hard to get right. A
               | senior manager described it like a herd of cats. If you
               | get them all mostly moving in a beneficial direction,
               | you're doing okay.
               | 
               | That's why they pay executives the big bucks. Executives
               | fake understanding how to manage this stuff. Most don't,
               | but they do a good job of convincing boards that they do.
        
               | CoolGuySteve wrote:
               | Yeah I don't know, I've been extremely disappointed with
               | Abseil, protobuf, and gMock. So whatever metric they're
               | using, it's not generating particularly great C++.
               | 
               | I wouldn't care about some company's code quality but in
               | these cases Google's clout (due partly from their
               | maladaptive hiring practices) causes these bad libraries
               | to get grandfathered into many projects that I have to
               | deal with.
        
               | marcosdumay wrote:
               | Except that the measurement error is very clearly fat-
               | tailed, and the std.div. is clearly much larger than one
               | std.div of competence of the population.
               | 
               | Place the bar high enough and you will get more and more
               | people far into the tail, and less and less people that
               | actually fit your bar.
        
               | cbm-vic-20 wrote:
               | > all Googlers are convinced they all have a PQ>160, and
               | are superior to everyone else.
               | 
               | And likewise, other employers looking to hire ex-Googlers
               | are convinced of the same.
        
               | wsc981 wrote:
               | Well no-one ever got fired for buying IBM.
        
               | russh wrote:
               | They do now.
        
               | graphenus wrote:
               | I very much agree with everything you wrote, except for
               | the arrogance bit. Many actually suffer from the impostor
               | syndrome and just a few I could call arrogant. I'm sorry
               | you had to deal with them but please don't generalize
               | from just a few.
        
               | woofie11 wrote:
               | Outwards arrogance is often the manifestation of impostor
               | syndrome, but I digress.
               | 
               | Corporate arrogance isn't a property of individual
               | personalities. Most Googlers are perfectly nice people.
               | The Google corporate culture is a whole is rooted in a
               | deep superiority complex and dripping with arrogance.
               | Google believes it knows better than its users, and that
               | translates to all aspects of product design. If you moved
               | those same engineers to a different company, you wouldn't
               | have the same behavior.
               | 
               | I'll also mention that each organizational design has
               | upsides and downsides.
               | 
               | This culture seems to work well in Google's early markets
               | (e.g. search) where users are statistics, and where most
               | problems are hard algorithmic problems, and users are
               | secondary. It has upsides in B2C markets like Google Docs
               | or Android. It crashes-and-burns in a lot of B2B markets,
               | like Workspace or GCP, where customers have a high degree
               | of expertise which ought to be respected.
               | 
               | I'll mention a lot of fintech companies, as well as elite
               | universities, have a similar culture. Those are domains
               | where it leads to success as well.
        
               | nobleach wrote:
               | I think you've hit the nail on the head. I've been on
               | both sides of the desk so many times. When I'm hiring,
               | I'm trying so hard to recognize the person is nervous,
               | probably interviewing at multiple places, and they don't
               | want to be asked to solve stupid algorithmic puzzles that
               | will never come up in their daily work. While
               | interviewing, I try to recognize that they NEED to
               | ascertain whether I can actually solve problems
               | performantly and quickly. They also need to quickly
               | decide if I'm worth the high dollars they're about to
               | offer me.
               | 
               | Because of this, I often hire people I've already worked
               | with. I'm also often hired by people who've already
               | worked with me. I hate that this leads to a very
               | homogeneous experience... or even what might seem like
               | gatekeeping. I've just found that the best indicator of
               | how a person will perform, is already being familiar with
               | their work.
        
               | ricardobayes wrote:
               | we have, we don't have technical interviews anymore, just
               | a 'cultural fit' discussion. coding has become so trivial
               | anyone with a brain can piece together snippets from
               | stackoverflow. do yourself a favor and if all you do is
               | crud operations in a web app, don't even bother with tech
               | rounds.
        
               | actually_a_dog wrote:
               | I'm really curious what company "we" is.
        
               | actually_a_dog wrote:
               | > Sure, some places (and individual interviewers) are
               | better at it than others.
               | 
               | In my, admittedly not super extensive experience, I tend
               | to believe that about 1 in 10 companies actually knows
               | how to run a hiring process. I'm not sure precisely what
               | kind of error bounds I'd put on that, but I doubt I'm off
               | by more than a factor of 2 either way.
        
         | eplanit wrote:
         | I lose respect for their engineers, if that one was typical.
         | 
         | Egos are the worst parts of humans. A lack of sense of humor is
         | a personality or character flaw.
        
         | tech_tuna wrote:
         | Inodesaurus would like to have some words with you.
        
         | aseerdbnarng wrote:
         | Good for you for having a spine. I had a similar experience
         | (not google). I was expected to do prepwork and the interviewer
         | couldn't be bothered to think up any questions other than
         | following a script is incredibly rude and telling of that
         | company's culture
        
         | commandlinefan wrote:
         | > more books to study
         | 
         | Curious if you happen to remember what any of those books were.
        
           | axaxs wrote:
           | I have some of the correspondence but not others, for some
           | reason. I went digging through my email and found these -
           | this was from 2014. Most were 'Google Research' links.
           | 
           | "Programming Interviews Exposed: Secrets to Landing Your Next
           | Job"
           | 
           | Authors: John Mongan, Noah Suojanen, and Eric Giguere (Wiley
           | Computer Publishing)
           | 
           | "Programming Pearls"
           | 
           | Author: Jon Bentley
           | 
           | "Introduction to Algorithms"
           | 
           | Authors: Cormen, Leiserson, Rivest & Stein
        
         | lrem wrote:
         | Now, the inode question is part of the pre-screen. That's
         | normally _before_ you get put on phone with any engineers. How
         | the heck did you get it in "round 3 or 4"? Was your process
         | started from scratch for some reason?
         | 
         | The question is meant to be asked by a sourcer - a contractor
         | whose list of requirements does not include being answer
         | themselves any of the questions they ask. Famously even if you
         | know the answer pretty well, say because you were the original
         | creator of the thing, but answer in a way that they can't link
         | to the answer key, you still fail.
        
           | rsynnott wrote:
           | Wait, seriously? That's an absurd screening question.
        
           | xorcist wrote:
           | > Famously even if you know the answer pretty well,
           | 
           | Everything above would make sense if the question was "what
           | is an inode?". But it was "what is an inode _not_? ". That
           | wording doesn't make much sense to ask anyone, no matter how
           | you spin it.
        
           | janoc wrote:
           | >Famously even if you know the answer pretty well, say
           | because you were the original creator of the thing, but
           | answer in a way that they can't link to the answer key, you
           | still fail.
           | 
           | Which is the most ridiculous part of it. You are being
           | examined and evaluated over trivia in a subject that the
           | examiner likely has no idea about and where there are only
           | 1-2 possible "correct" answers.
           | 
           | That's like sending a janitor to "source" surgeons by asking
           | questions to people in white coats in a competing hospital
           | about appendectomy.
           | 
           | Yet this is considered effective (and acceptable) somehow ...
        
             | lrem wrote:
             | What alternative would be more efficient and acceptable? A
             | typical team of 6-8 replaces two persons per year. The
             | number of resumes per opening is measured in thousands.
        
               | marcosdumay wrote:
               | If you want to mechanically apply a trivia test, then at
               | least make it multiple choice.
               | 
               | You will still be choosing people through a mechanical
               | procedure, what is quite stupid, but it's less stupid
               | than that way.
        
               | VonGallifrey wrote:
               | > A typical team of 6-8 replaces two persons per year.
               | 
               | How is this fact not seen as a complete failure of hiring
               | practices or company/team leadership?
        
               | bostik wrote:
               | In an industry where the median tenure for a SWE is ~2.5
               | years, that's "doing no worse than the industry average".
               | 
               | Turns out upper management rates predictability quite
               | high.
        
               | lrem wrote:
               | Internal mobility is strongly encouraged. People
               | typically move after promotion, which is expected after 2
               | years. Some people don't like to move, bringing it down
               | to about 2/year. All working as intended. Then, people
               | moving out tend to want to join new teams, for the career
               | growth opportunity, while you want new hires in
               | established teams.
               | 
               | Note: that's anecdotal from a couple years of
               | observation. I haven't looked into any Google-wide
               | statistics (and if I did I would not blabber about them).
               | But I'd be surprised if this was way off.
        
               | TheOtherHobbes wrote:
               | Are you saying a company with the resources of Google,
               | which expects all of its employees to answer trivia and
               | whiteboard answers in interviews - all of that brainpower
               | and money _can 't invent a better process?_
        
               | incrudible wrote:
               | Having too many resources tends to lead to sub-optimal
               | processes. Just look at the Joint Strike Fighter program.
        
               | lrem wrote:
               | I don't think it's a matter of impossibility. The current
               | process is simply a local optimum. Most practicing
               | software engineers can pass the trivia quiz. Most time
               | wasters can't, unless they googled for the answer key.
               | The result is a pool of candidates that usually can
               | understand a real interview question an engineer will
               | ask. The system works, at the price of being annoying.
        
               | mcv wrote:
               | If there's only a single correct answer that the
               | interviewer doesn't understand and an expert might get
               | wrong, it's people who google the answers that have the
               | best chance of passing.
               | 
               | I tend to ask open-ended questions. Let them talk about
               | code, and I can probably figure out whether they're full
               | of shit or not. And a real coding challenge proves better
               | whether someone can code than any code question or
               | whiteboard challenge.
        
               | lrem wrote:
               | But you're an engineer, aren't you? Do you think you
               | could figure out if someone is bsing you about their
               | experience in mRNA manipulation?
        
               | radiator wrote:
               | If the applicant has graduated from a university,
               | technical school, whatever, then look at the records from
               | their exams there. Also taking into account the average
               | level of the university, technical school in question.
        
               | tnecio wrote:
               | That'd be really unfair on people who were busy e.g.
               | gaining actual work experience
        
         | pwdisswordfish8 wrote:
         | > Google caliber, whatever that means
         | 
         | It means the sort of people for whom Golang was designed.
        
         | aix1 wrote:
         | I'm curious, how long ago was this? And, if you don't mind,
         | which job ladder were you interviewing for?
        
         | raffraffraff wrote:
         | Same-ish. I got through several phone interviews and was asked
         | on-site for a full day of interviews, back to back, with a
         | lunch break in the middle. The HR girl was honestly running
         | around like the mad hatter, apologising for being late and then
         | running away as soon as she had left me in the general area
         | where my interviewer would be. Some of the interviewers left me
         | with the next, others just wandered off, leaving me in a room.
         | One of the interviewers was in a different office so we talked
         | over video conference. I say "we talked" but he was reclining
         | so far back in a chair that he might as well have been in bed,
         | and he read questions from a sheet without once looking at the
         | camera. After that I did actually get a decent interview from
         | someone who was on the team I interviewed for. During the lunch
         | break someone had to take me for lunch, and from the moment she
         | showed up I gathered that, like perpetual interviewering,
         | bringing ten-percenters for lunch was another boring part of
         | the job. I also got a really bad 'vibe' just walking through
         | the building. Lots of fun-looking-stuff like games and beer
         | fridges, but everywhere, people with headsets on staring into
         | screens, never once looking up to see who is in their vicinity.
         | Anyone ever seen Coraline? The people with buttons for eyes...
         | 
         | After that whole depressing charade was over, I figured it
         | would be an offer or GTFO. Nope, I got called for another
         | interview. I said "eh, no thanks".
        
         | mrb wrote:
         | As an ex-Googler who interviewed 100+ candidates (mix of phone
         | & onsite interviews) I can tell you that there is a great
         | variance across the company groups in the quality of questions
         | we ask. And the reason is simple: it's up to the interviewer to
         | choose his questions. Questions aren't standardized.
         | 
         | I took great pride in the fact that my questions were unique. I
         | designed them myself, about 30: some quick knowledge tests,
         | some elaborate coding challenges, and everything in between.
         | And for a given candidate I would pick about 6-7 questions of
         | the 30 to ask them.
         | 
         | I didn't care if the candidate didn't know or didn't find an
         | answer. I would entice the candidate to drop it and just move
         | to the next question. Some candidates make it hard because they
         | want to keep persevering, keep thinking, but there is limited
         | time in an interview. As an interviewer, my goal is to
         | (quickly!) find and evaluate what you are good at, not what you
         | don't know.
        
           | rsynnott wrote:
           | > I took great pride in the fact that my questions were
           | unique. I designed them myself, about 30
           | 
           | ... Is this part of the process? Questions made up by random
           | person? That sounds absolutely ridiculous if you want any
           | sort of consistency.
        
           | jonathankoren wrote:
           | Given that you probably had 60 minutes tops, you expected a
           | candidate to answer each question in nine minutes at most? If
           | you left time for candidate questions (I'm assuming you
           | didn't), there'd only be 7 minutes a question.
           | 
           | I don't think you learned this style of questioning in
           | interview training. Going off script like this uncallibrates
           | the entire system. In fact, if I was your coworker, let alone
           | manager, I'd recommend you for remedial interview training.
           | This is not how you conduct an interview for any role.
        
           | manish_gill wrote:
           | Unique questions? What's there to be so proud of in selecting
           | questions? Are you playing jeopardy with the candidates
           | careers? Enticing the candidates to moving on and not
           | answering questions in what is probably the biggest interview
           | in their life? "Quickly!"?
           | 
           | > Some candidates make it hard because they want to keep
           | persevering, keep thinking
           | 
           | Yeah, amazing that some candidates want to demonstrate their
           | perseverance even in face of problems that they find
           | challenging. Crazy right?
        
             | ljm wrote:
             | I'm wary of pushing people to move on to something else
             | because I know that if I was on the receiving end, I would
             | think that I fucked up and the interviewer is trying to get
             | the interview done early.
             | 
             | A candidate who spends far too long on a part of the
             | problem without getting anywhere will get some guidance and
             | nudging. If they take that on board and get back on track
             | then that's great - they're responding to feedback and
             | correcting course. If they remain too committed to their
             | chosen approach and continue to struggle, then we've seen
             | it with our own eyes.
             | 
             | At the end of the day, we're giving candidates the benefit
             | of the doubt and recognising that, a lot of the time, it's
             | their nerves that are doing the talking and you need to
             | work with that.
        
             | mrb wrote:
             | Well, as evidenced by this thread, candidates are
             | frustrated by the interviewing process at Google, in
             | particular by poor/generic/boring questions that test a
             | narrow/irrelevant topic. So, yes, I took pride in selecting
             | questions that aren't like this in order to find what the
             | candidate is good at, not what they don't know.
             | 
             | And rest assured that I always made it very clear to the
             | candidate that abandoning a question they are stuck on is
             | best to maximize their chance of doing well in the
             | interview. If I have a 45-min time slot to spend on a
             | candidate, I don't want to waste 30 min on a single coding
             | challenge that they do poorly on and have barely 15 min to
             | cover other topics. If I get a sense they won't do well
             | after 10 min, I stop it, move on, and that leaves us 35 min
             | to do other coding challenges. I have more chances of
             | finding what the candidate is good at in 35 min than in 15
             | min.
        
           | fidesomnes wrote:
           | You were really terrible at these and everyone thought so.
        
         | [deleted]
        
         | Analemma_ wrote:
         | Google is infamous for jerking people around in the interview
         | process. I had a very similar experience, as did several people
         | I know.
         | 
         | They do it because they know they can get away with it, but I
         | do wonder if they have a backup plan if the lustre of working
         | for Google ever fades, because it's an open secret that their
         | interview process is a fucking nightmare for no reason.
        
           | billytetrud wrote:
           | That lustre has faded already.
        
             | newsyyswen wrote:
             | Yeah, it's probably been 3-4 years since I've heard anyone
             | use the word "Xoogler" in a positive or unironic way.
             | 
             | Darn the wheel of the world! Why must it continually turn
             | over?
        
               | [deleted]
        
             | SCUSKU wrote:
             | Mine (and the public's) growing awareness of surveillance
             | adtech really has taken away from my desire to apply to
             | Google or Facebook.
        
               | swader999 wrote:
               | Restoring my faith in humanity ^^^
        
             | axaxs wrote:
             | Yeah... reminds me of a past coworker. He spent weeks
             | writing weird comments in code, then writing weird code to
             | read comments. From the actual source files. Then when
             | deployments didn't work, he said they worked on his machine
             | the deployment must be broke.
             | 
             | He was hired by FAANG less than a month later.
        
               | grp000 wrote:
               | To solve the hiring problem that seems rampant in the
               | industry, I propose for all resumes that get past the
               | auto-filter, we just implement a lottery system. Maybe
               | it'll be even more effective than the current method!
        
           | devnull3 wrote:
           | > fucking nightmare for no reason
           | 
           | Absolutely! To add, the amount of nit-picking that happens is
           | staggering. I was downgraded from strong-hire to lean-hire
           | because:
           | 
           | 1. I did not use classes in Python. That problem could easily
           | be solved using simple functions. The feedback I got was
           | "candidate does not know idiomatic use of modules & classes"
           | 
           | 2. I did not use one of python's standard lib functions and
           | instead I coded it myself (I could not remember it at that
           | instant)
           | 
           | 3. I could not spot a scenario in the first 5-7 min of
           | interview. I eventually spotted it and coded it well within
           | the time limit.
           | 
           | Somehow I felt that I am supposed to feel grateful for lean-
           | hire
        
             | wwweston wrote:
             | > 1. I did not use classes in Python. That problem could
             | easily be solved using simple functions. The feedback I got
             | was "candidate does not know idiomatic use of modules &
             | classes"
             | 
             | Apparently they missed this classic HN discussion:
             | 
             | https://news.ycombinator.com/item?id=3717715
        
             | paganel wrote:
             | > The feedback I got was "candidate does not know idiomatic
             | use of modules & classes"
             | 
             | Many googlers probably haven't read this blog-post from
             | some time ago [1]: "Python Is Not Java". I mentioned that
             | at my first interview for a Python programmer job ~15 years
             | ago, i got hired (truth be told the interview was for a
             | small-ish startup, not for a behemoth like Google).
             | 
             | [1] https://dirtsimple.org/2004/12/python-is-not-java.html
        
             | aix1 wrote:
             | Did you choose Python or were you asked to use Python by
             | the interviewer?
        
               | devnull3 wrote:
               | I chose Python because its faster to code
        
               | aix1 wrote:
               | It's quite a common pattern these days: I often see
               | candidates who choose a language because they think it's
               | better suited for interviews, not because they know it
               | well (we leave the choice of programming language to the
               | candidate).
               | 
               | Sometimes this works well, sometimes it really backfires
               | on them. Coding is one of key rubrics on which we assess
               | software engineering candidates, and if the only signal I
               | have is that they don't know know their chosen language
               | very well, it's hard to justify scoring that rubric
               | highly.
        
               | TheOtherHobbes wrote:
               | The root comment is saying the interviewee knows the
               | language well enough to consider one solution better than
               | another solution.
               | 
               | And this was _misinterpreted by the interviewer_ as not
               | knowing the language.
               | 
               | An effective interviewer would have asked "Why are you
               | doing it this way?" instead of assuming - wrongly - it
               | was all the candidate knew.
               | 
               | This actually matters. Before you even get to coding
               | skill you want people who can parse reality accurately,
               | and not make incorrect assumptions about what's happening
               | in front of them - either out of narcissism and
               | arrogance, or because of poor communication skills, or
               | because they're following a set process which is
               | bureaucratic and inflexible and operates with a poor
               | signal to noise ratio. (Among other possible reasons.)
        
               | devnull3 wrote:
               | I really well versed with Python, Golang & Rust. I will
               | not choose Rust for interviews. For me, Python is much
               | more productive in an interview setting.
               | 
               | But I get what you are saying though.
        
               | aix1 wrote:
               | I didn't mean to imply that this applied to your case.
               | Just a general observation (rather frustrating for
               | someone like me, who wants candidates to do well but not
               | that infrequently sees them being let down by their own
               | choices).
        
             | bostik wrote:
             | > _I could not spot a scenario in the first 5-7 min of
             | interview._
             | 
             | This is endemic and part of a much wider malignancy in the
             | tech interviews. Cram two medium-to-high difficulty
             | questions in the span of 45 minutes and require the
             | candidates to solve them both on the spot. In other words,
             | you have at most 20 minutes to work out a complete solution
             | to any given problem.
             | 
             | In practice that means that you need to come up with the
             | correct base solution in the first 2-3 minutes, because
             | there is no time to actually work _through_ the problem.
             | 
             | I call these types of interviews Epiphany Lottery.
        
               | rejectedandsad wrote:
               | They're IQ tests, it's that simple.
        
               | devnull3 wrote:
               | > correct base solution in the first 2-3 minutes
               | 
               | Not only correct solution but also generate alternatives
               | to showcase what other things you know to get strong-
               | hire.
               | 
               | Example:
               | 
               | This problem was asked in Google:
               | https://leetcode.com/problems/cat-and-mouse/
               | 
               | It is actually based on a paper [1]. Plus it seems it is
               | expected that one needs to know about 'alpha-beta'
               | pruning algos for such problems.
               | 
               | If you solve this using dfs ... its basically gtfo
               | 
               | [1] https://www.semanticscholar.org/paper/Undirected-Cat-
               | and-Mou...
        
               | rejectedandsad wrote:
               | I don't know how I'm ever going to be happy. I just
               | straight up don't have the intellect to be considered
               | competent in this field.
               | 
               | What's worse is how people downplay the difficulty of
               | this or say it's easily gameable if you just "grind
               | leetcode", as if the rest of us aren't trying already but
               | failing because of our genetic failings.
        
               | VonGallifrey wrote:
               | When people say "grind leetcode" they don't mean it as a
               | tool to get better at these kinds of problem solving.
               | What they basically mean is that if you "grind leetcode"
               | you have a better chance of being asked a question in
               | these interviews that you have solved before and simply
               | write down the solution during the interview.
        
               | loftyal wrote:
               | If they're IQ tests, then why does doing a whole bunch of
               | leetcode questions make me better at it? Isn't IQ
               | supposed to be relatively stable throughout one's
               | lifetime?
        
               | rejectedandsad wrote:
               | I've done hundreds and I have gotten better, but only to
               | a point. At some level it's not pattern recognition
               | anymore, just inspiration. And I'm not smart enough for
               | that.
               | 
               | This one, for instance is expected to be completed in 30
               | minutes. I spent 2 hours on it yesterday and failed most
               | test cases. I'm a failure.
               | 
               | https://leetcode.com/problems/exam-room/
        
               | grumple wrote:
               | They are memorization tests at best. At worst they test
               | which candidates have been unemployed most recently so
               | they can cram leetcode study.
        
               | jasonladuke0311 wrote:
               | > At worst they test which candidates have been
               | unemployed most recently so they can cram leetcode study.
               | 
               | Or which ones are young and single with no
               | responsibilities outside of work. Which is likely a
               | feature, not a bug.
        
               | rejectedandsad wrote:
               | I mean that describes me. But if you don't have the
               | mental acuity and length of short term memory required to
               | solve these problems...
        
         | bryanrasmussen wrote:
         | https://www.kalibrr.com/sites/default/files/featured_images/...
         | 
         | Every year, Google receives over one million resumes and
         | applications. Only 4,000-6000 applicants will actually be hired
         | -- that's less than a 1% hiring rate.
         | 
         | Given those odds it's not worth it.
        
           | axaxs wrote:
           | Sure but I never applied...they reached out to me. Hence why
           | I didn't read their materials to interview. I've been happily
           | employed the entire time.
        
           | dilyevsky wrote:
           | These numbers are misleading af. Most of those applications
           | are just spam, not really relevant and never get read by any
           | human. I've done ~150 interviews for backend roles at google
           | and based on my experience 4 years ago if you make it to
           | onsite you have 5-10% of getting an offer
        
             | mbit8 wrote:
             | if you get onsite at most companies for an experienced
             | position the chance is rather 50% to get hired. if i would
             | know the chance is only 5 % i would decline the onsite
             | interview at google.
        
               | dilyevsky wrote:
               | From my experience 50% couldn't write code at all. So
               | yeah if you only look for "can code" checkbox then you'd
               | probably extend offers to half. Google chose to place the
               | bar higher and that's their right to do that
        
             | gowld wrote:
             | > if you make it to onsite
             | 
             | So those numbers are accurate and not misleading.
        
             | edoceo wrote:
             | You've been interviewed 150 times to get in? Or are in and
             | have interviewed 150 candidates?
        
               | dilyevsky wrote:
               | Yes
        
             | speedgoose wrote:
             | That confirms that we shouldn't bother if we value our time
             | and energy.
        
               | burntoutfire wrote:
               | Many people apply to all the FANGS, since the
               | interviewing skillset needed is similar. Moreover, you
               | can reapply every six months. In result, this gives you
               | perhaps 5-10 lottery tickets every year, which means it's
               | very feasible to get in within a year or two (or three).
        
               | bryanrasmussen wrote:
               | >Moreover, you can reapply every six months. In result,
               | this gives you perhaps 5-10 lottery tickets every year,
               | 
               | you are aware of the saying that the lottery is a tax on
               | stupidity?
               | 
               | I guess that is perhaps a little harsh, but only a
               | little.
               | 
               | First off, I don't think I would want to work at any
               | place where getting in there is represented as winning a
               | lottery ticket. Think of the poor oompa-loompas enslaved
               | in Willy Wonka's factory.
               | 
               | Second off, perhaps it's just my vantage as a consultant
               | in Denmark but everything I've read about working in
               | Google has made me think it doesn't seem very enticing.
               | 
               | Third off, even when I was not married with kids I would
               | not have wanted to spend so much time twice a year! How
               | many unpaid hours a year are people willing to work for a
               | lottery ticket that essentially pays out a top-paying
               | job?
        
               | gowld wrote:
               | Do you understand the difference between spending money
               | on a negative expected value lottery, and spending time
               | developing your knowledge skills?
               | 
               | Almost everything in life is "lottery ticket" with some
               | odds.
        
               | maccard wrote:
               | Going through 5 companies hoops for 2-3 years sounds like
               | a full time job. There's no way I would have time to do
               | that on top of work right now.
        
               | dagw wrote:
               | What if doing so could double or triple your salary?
               | Would that change the calculus?
        
               | maccard wrote:
               | It doesn't change the number of hours in my day, so
               | unlikely.
        
               | dilyevsky wrote:
               | I think i may have given the impression that it's 10% by
               | pure chance which it most def isn't. There's certainly
               | some randomness in the system but if someone is in the
               | bottom 50% by skill they can probably apply like 100
               | times and still fail every single one.
        
               | janoc wrote:
               | In other words - don't bother to apply if you actually
               | _need_ a job. And if you have a job already, why would
               | you bother to apply there? It used to be attractive but
               | is it still? With all the scandals and upheaval in the
               | recent years?
        
               | dudeman13 wrote:
               | >And if you have a job already, why would you bother to
               | apply there? It used to be attractive but is it still?
               | With all the scandals and upheaval in the recent years?
               | 
               | $$$
        
               | killtimeatwork wrote:
               | The reason is that it doubles or triples regular SWE
               | salary.
        
               | xyzzy_plugh wrote:
               | Eh, I've had two offers from Google that were far below
               | the "market rate" I was receiving at some of the largest
               | pre-IPO unicorns of the last decade, and their interview
               | processes were substantially better.
        
               | gowld wrote:
               | "pre-IPO unicorn" is the same rarified air. We're
               | comparing to average paying jobs most people have.
        
             | bryanrasmussen wrote:
             | So the top range is 10% chance of getting an offer? And how
             | many hours do you have to spend chasing 10%?
        
               | dilyevsky wrote:
               | Somewhere between 0 and infinity? I asked extremely
               | simple questions algorithmically (not anything posted
               | online) and didn't discount candidates on not knowing the
               | algorithm but about half of the people couldn't write ~20
               | lines of code after we'd already talked through it.
               | Another 30% could but the code was total mess. I passed
               | roughly 20% personally of which about half passed the
               | hiring committee.
        
             | rejectedandsad wrote:
             | It's true, and the end result is you probably consider
             | 90-95% of the people you interview to be morons right?
        
         | atoav wrote:
         | Weird. When I was casting for actors instead of trying to
         | "trick them into doing something bad" and throwing them out, I
         | tried my best to get it to work with them, even if it meant _I_
         | had to do something different.
         | 
         | A casting is always stressful, they don't need me as an enemy
         | as well. If they are not good enough with a ton of help, they
         | won't be good enough period. If they are _really_ good with a
         | little of help, they can still be better than someone who needs
         | no help at all. In the end I care about the final result, not
         | about whether they grade well on some invisible scale that only
         | I can see.
        
           | raffraffraff wrote:
           | This. Help the person you're interviewing. You'll both get
           | more out of it, you'll both enjoy it. If you're in a company
           | that is expanding, you'll be interviewing a lot, so it's
           | really important that it doesn't depress the shit out of you.
        
             | konschubert wrote:
             | There is a risk that you accidentally do the thinking for
             | them and give the answers for them without noticing.
             | 
             | Doing a collaborative interview requires careful attention
             | by the interviewer, but I agree it's worth it.
        
               | gspr wrote:
               | I mean, sure. Nobody said interviewing should be easy. Be
               | attentive and focused as an interviewer too!
        
               | atoav wrote:
               | That is the hard part of the job. You need to be able to
               | take yourself out of the equation. If you can't do that,
               | you are simply the wrong person for the job.
               | 
               | Usually it is not hard to notice whether you'd _like_
               | someone to succeed and then factor that in.
        
               | balls187 wrote:
               | > Usually it is not hard to notice whether you'd like
               | someone to succeed and then factor that in.
               | 
               | What about the opposite, that you don't like someone, or
               | worse, you are indifferent to their success?
        
               | atoav wrote:
               | Same thing. One of our main actors was once a guy I
               | didn't like at all. But he was fantastic for the role and
               | it turned out to be a good decision afterwards (despite
               | him being complicated to handle, which we also factored
               | in).
               | 
               | Maybe the hard part is to get a HR person that cares
               | about the outcome instead of their authority.
        
               | ryanbrunner wrote:
               | So factor that into your judgement. If you needed to help
               | them constantly, you still know they're a bad candidate.
               | Nothing is gained by stonewalling them other than
               | potentially getting someone who's going to badmouth you
               | to everyone.
               | 
               | I've definitely had interviews with solid candidates who
               | just faced an early roadblock, but were brilliant after I
               | gave them an early push. Sometimes that's more of a sign
               | of communicating a question poorly or nerves than genuine
               | lack of knowledge on the candidates part.
        
               | embik wrote:
               | This, so much. Interviews are very stressful for
               | candidates, everyone should remember what it's like
               | sitting on the other side.
               | 
               | I've been doing a bit of technical interviewing and I
               | usually try to help people along so they reach the "end"
               | of the interview, especially if they're not doing too
               | well. So many candidates sound defeated when they're
               | struggling with a task and it's a form of respect for me.
               | They've put themselves out there, after all.
               | 
               | Treating candidates - which you know you are going to
               | reject at some point of the interview - with dignity is
               | the right thing to do and can go a long way when it comes
               | to your company's reputation.
        
           | balls187 wrote:
           | I agree with the spirit of what you are saying, and in light
           | of the role unconscious biases plays in hiring, I'm
           | challenging my own beliefs on how to run an interview.
           | 
           | How does an interviewer ensure all candidates are offered
           | help fairly and equally?
           | 
           | What is the purpose of asking a question, that if a solution
           | is found after "hints" are offered, would be acceptable for
           | hiring?
        
         | wjamesg wrote:
         | But you were correct
        
         | snissn wrote:
         | i can't imagine a real world scenario where knowing that helps
         | you.. especially when you.. can.. just.. google it
        
           | nosianu wrote:
           | Maybe these firms prepare for the apocalypse when all
           | technology fails and has to be recreated from scratch, with
           | only a few half-burned books around. Of course, if that were
           | true there should be some blacksmithing and basic herbology
           | questions in the interviews.
        
             | z77dj3kl wrote:
             | Or the case where you work google which goes down and then
             | you can't possibly duckduckgo it, that'd be too
             | humiliating.
        
         | bschwindHN wrote:
         | But think of how smart he felt after telling you the answer!
         | That confidence boost alone was probably worth their time to
         | interview you, mission accomplished.
        
           | atoav wrote:
           | IMO asking gotcha questions like that to make yourself feel
           | smart is just cringeworthy and silly.
           | 
           | Your goal when interviewing people should be to find things
           | out about _them_ -- with gotcha questions you don 't find out
           | _anything_ about them, but they find out something negative
           | about _you_.
        
           | lrem wrote:
           | I don't think a (non-technical, mind you) sourcer gets that
           | much confidence by reading out loud the answer key.
        
           | axaxs wrote:
           | LOL. He was obviously way smarter than me. He probably told
           | his colleagues about how some dummy was talking about
           | dinosaurs in an inode.
           | 
           | I feel the smartass part of my brain eternally dooms me...
        
             | yarky wrote:
             | This makes me thing of the time I was interviewed by three
             | bankers. I'd probably be rich and miserable had I answered
             | non sarcastically :/
        
               | badbetty wrote:
               | You have to say what happened
        
               | gffrd wrote:
               | The suspense is killing me. What was the question, and
               | how did you answer?
        
               | yarky wrote:
               | Oh don't worry it wasn't just one question but the whole
               | interview. One I remember was how would I explain [
               | _insert random algorithm_ ] to a board of decision
               | makers, I made it sound like I was explaining a 100 year
               | old how to turn on a computer.
               | 
               | I had no interest in ever "explaining" stuff to non-
               | technical people at that time, all I cared about was the
               | code. So I also trolled one of the guys interviewing me
               | since I happened to be stuck with his legacy "code",
               | which made me judge him and take him with absolutely no
               | seriousness: he was one of those "cfa" people who learnt
               | how to "code" a line of VBA and think they're Linus.
               | 
               | I also remember the face of the HR person who was like
               | wtf the whole time and politely told me they had "chosen"
               | another person for the job, I laughed inside and politely
               | answered that I understood.
               | 
               | I recommend against this behaviour to past me anyways ;)
        
               | gffrd wrote:
               | > I recommend against this behaviour to past me
               | 
               | We all have to feel our oats at some point ... and then
               | realize later how childish it was / how poorly we treated
               | others ... so we can be forgiving of those who come after
               | us ...
        
         | vidarh wrote:
         | My experience with Google (in the UK) was an interviewer who
         | asked a very similar question, among a number where he was
         | clearly unprepared to deal with answers that weren't 100% as
         | expected, and asked questions that had basically no relevance
         | to the role.
         | 
         | The experience was so bad that afterward I sent a lengthy email
         | to the recruiter thanking her but pointing out I expected to
         | fail the interview because the interviewer insisted on things
         | that were wrong or irrelevant and set out why as a courtesy so
         | they could address it for the future.
         | 
         | I was rung up and was told the recruiter had gotten the
         | interview set aside, and offered to just have me bypass the
         | technical interview and wanted to move on to an interview with
         | the hiring manager.
         | 
         | In the end I declined, as the first interviewer would have been
         | one of the people I'd have managed, and I just did not want to
         | deal with a team with a person like that, and the whole process
         | was just excruciatingly slow to the point I had offers on the
         | table before they could line up an interview.
         | 
         | It seemed to be a process optimised for people who either
         | desperately want to work specifically at Google, or doesn't
         | have alternatives.
         | 
         | I kept getting calls from Google recruiters for years after
         | that and kept recounting my past experience and asking if they
         | could provide a better experience this time around.
         | 
         | I have had worse interview experiences than Google, including
         | one where I halted a phone interview halfway through and told
         | them they'd shown me I didn't want to work there, but Google is
         | pretty high on my list of places I'm not particularly
         | interested in interviewing.
        
           | tchalla wrote:
           | > In the end I declined, as the first interviewer would have
           | been one of the people I'd have managed, and I just did not
           | want to deal with a team with a person like that,
           | 
           | Oh, I can totally empathise with you because I've been there.
           | I applied for a position which was the head of a team and a
           | future direct asked me esoteric statistical questions from
           | his PhD thesis. I did quite well to answer most of them but
           | he wasn't impressed.
        
             | thweroi23434 wrote:
             | I was once asked to prove that K-means is _not_ NP-hard in
             | 1-d ?!
        
             | pram wrote:
             | I love when you can tell an interview question is someones
             | very personal pet issue that no one on earth could
             | reasonably care about.
        
         | powerapple wrote:
         | it is not optimal, but there is no alternative. The interviews
         | should show 1) you want the job, i.e. you put some effort; 2)
         | you can learn, i.e. those ridiculous questions; 3) team fit,
         | i.e. you like them, and they like you. Programmer interviews
         | are the only thing people can do in a reasonable timeframe.
         | 
         | As programmers we always learn, we learn what we need to learn
         | to do the job, there is no reason to reject someone because he
         | does not know the answer to a technical question, but if you
         | are not making the effort to know the answer in order to get
         | the job, maybe you don't want the job.
        
           | sneak wrote:
           | There are alternatives.
           | 
           | They don't prescreen for candidates that will put up with a
           | large amount of big corporate bullshit without fucking off
           | unexpectedly, however.
        
           | janoc wrote:
           | Sorry that's utter BS.
           | 
           | I have just passed an interview for my new job and it was
           | none of the above. Yet very technical, still very involved -
           | but with competent people on the other side that were showing
           | they are as interested in getting someone hired as I was in
           | getting the job.
           | 
           | There were 2 interview calls in all (normally the second one
           | would have been on-site but Covid ...).
           | 
           | No need for BS scripted questions, no need to ask trivia,
           | there was coding test but on a computer (not paper) and
           | nothing crazy you would need to read books or study for.
           | 
           | Is it perfect? Of course not. But that's why there is a 3
           | months trial period in the contract during which they can
           | terminate the employee "overnight" if not performing
           | satisfactorily.
           | 
           | That's a much better solution than trying to evaluate
           | everything and the kitchen sink in an interview by asking
           | trivia questions and wasting the candidate's time with reams
           | of books to study. Which, in the end, evaluate only whether
           | the candidate is able to cram for interviews and not whether
           | or not they are actually competent at doing their job.
        
             | powerapple wrote:
             | Software engineers can learn everything and can take on
             | whatever tasks. Small teams may look for specific skillsets
             | they need, big companies can afford to hire people then
             | find something they can work on later. Also, they are more
             | candidates so they are basically doing a filtering rather
             | than looking for the right candidates.
             | 
             | Yes, there are 3 months trial period, but Google will have
             | thousands of candidates every week, they need to quickly
             | filter them rather than evaluating them equally. Many
             | people interviewing don't even know the job they are
             | interviewing for, that's the problem of big organization.
        
           | vsareto wrote:
           | >2) you can learn, i.e. those ridiculous questions;
           | 
           | So why do I have to re-prove this at every new job? It's not
           | obvious enough I can learn if I've learned a programming
           | language or framework in the past? Do companies have some
           | brilliant insight into neuroscience where they know people
           | become incapable of learning at some point?
           | 
           | Any 2/4-year degree should also answer that question as well.
           | Lots of things can answer that question. Ridiculous questions
           | are about the laziest way to test someone for it.
        
         | catgary wrote:
         | The hiring process is like, 80% about marketing hype, right?
         | Like you have to manufacture consent for the public to just
         | accept that a private institution has a monopoly on search and
         | browsers.
         | 
         | It's pretty clever, I'm surprised Microsoft didn't try it (or
         | maybe I was just too young to remember).
        
           | thrwyoilarticle wrote:
           | I believe Microsoft were the first to do it.
        
         | helsinkiandrew wrote:
         | This sounds dreadful, on the positive side I had very enjoyable
         | interview rounds in places like Goldman Sachs and Lehman
         | Brothers (obviously this was a few years ago), 3 or 4
         | interviews hour long plus depending on if they were before or
         | after work. These tested what I new, how I would approach
         | things, and giving me a very good view of the people that
         | worked there from more junior devs, architects and management
         | in the teams I would be working in and those around it.
         | 
         | The best interviews aren't scripted but are created from around
         | the interviewers expertise but based on the skills and
         | qualities needed for the role.
        
           | hef19898 wrote:
           | Quite honestly, I am torn. The best jobs I had so far
           | involved multiple interviews (Amazon with a total of 6 one
           | hour interviews and my current employer with 7, the jury is
           | still out on my current job one month in), the worst involved
           | either one or two interviews or multiple, but very easy and
           | yet unpleasant ones. Scripted questions suck, Amazon in my
           | case was good, as there was only on scripted logical question
           | and the rest was STAR-style leadership principles centered
           | questions.
           | 
           | Multiple rounds give you more opportunities to ask questions
           | to multiple people and get a better idea of the company. They
           | can also be a pain in the ass.
        
           | sdoering wrote:
           | Exactly that. I often interview people as part of the team.
           | We have normally one HR person, the team lead and one of the
           | team present.
           | 
           | More often than not I give my spot to a more junior team
           | member if they are available. So that they learn something
           | from watching the interview as well as "just" see if the
           | person interviewed would be a cultural fit. If they could
           | imagine working with them.
        
         | jcolella wrote:
         | I went through the exact same thing with Google. The interview
         | was very impersonal, never going into if I'd be a great culture
         | fit and it was simply on the basis of if I knew how to do this
         | algorithms problem that doesn't show if I'm a good engineer or
         | not. Ended up in a much better company culturally, and I've
         | never looked back
        
         | nvarsj wrote:
         | For all the complaints, people will continue to jump through
         | the hoops given an engineer with 3-5 years experience can make
         | close to 400k in TC/year. That is not happening anywhere else
         | outside of FAANG and certain finance companies. Google can be
         | as picky as they want.
        
         | mongol wrote:
         | The inode question is tricky. It is certainly not something an
         | employer should take for granted you have memorized. But the
         | answer can be reached by reasoning, at least if you know
         | something about filesystems and the concept of hard links.
         | Which you probably do if you have read the "ln" man page.
         | 
         | It is still a pretty poor question, I remember getting a
         | similar kind of question when I passed through the (at the
         | time, in Sweden) mandatory conscription testing, where you are
         | tested for which role you best fit as a military conscript.
         | 
         | One question on the intelligence test was: "What is heaviest,
         | gasoline or water?". I did not know how to approach the
         | question, I had not memorized the density of gasoline and I
         | didn't think an intelligence test could have assumed that
         | either. I was stumped. How could that be an intelligence test
         | question? Only afterwards did I realize that the test creators
         | probably assumed that knowing that gasoline floats on water as
         | common knowledge, and if you were intelligent enough you should
         | be able to derive the answer from that. I think the inode
         | question is similar.
        
           | fredgrott wrote:
           | mote not a good example as oil which is also hydrocarbon
           | based does in fact float for awhile but not due to density
        
           | david-gpu wrote:
           | _> "What is heaviest, gasoline or water?"_
           | 
           | It depends on the amount. Two pounds of gasoline are heavier
           | than one pound of water.
           | 
           | Yes, I get that they are asking about density, not mass. My
           | point is that tests need to be carefully written. I remember
           | once during an early online screening at a multinational they
           | asked something like
           | 
           |  _Alice went shopping in the morning and bought apples. What
           | did she buy?
           | 
           | A) Apples. B) Oranges. C) All of the above. D) None of the
           | above._
           | 
           | With the information provided, the only answer we can reject
           | is D, because we know that she did in fact but apples.
           | However, it is possible that she _also_ bought oranges (and
           | /or something else), in which case answers B and C would also
           | be correct. We don't have enough information.
           | 
           | Bear in mind this was a test for recently graduated software
           | engineers, who are supposed to be trained in logic, so I
           | spent a few seconds puzzled wondering why the question was
           | worded so strangely.
           | 
           | I did answer A and moved on.
        
             | jaredsohn wrote:
             | If looking for the best answer, you can rule out B but A vs
             | C is still ambiguous.
        
           | marcosdumay wrote:
           | Almost everybody with some Linux experience knows that the
           | file name is not stored on the inode. It's not this part that
           | makes the question bad.
           | 
           | What makes the question bad is that nobody can guess what
           | answer he wants, and anything else, as correct as it may be,
           | will be understood as a mistake (what is evident by the OP's
           | answers that were perfectly correct).
           | 
           | "What number am I thinking right now" may be a really strict
           | question that fails your expected number of people, but it's
           | not a good interview question.
        
             | kevstev wrote:
             | My first linux install was Redhat 5.2 bought at a bookstore
             | in ~1997. I have not always been a primary linux user, but
             | I have been using it in some capacity for over 20 years
             | now- though as a means to an end primarily- in the bad old
             | days I mucked around with drivers and X configs and have
             | even recompiled a custom kernel on occasion. Never once has
             | it come up that the filename is not stored in the inode.
             | 
             | I am actually just curious as to why this would ever even
             | be a thing you come across unless dealing with filesystems
             | directly?
        
               | arp242 wrote:
               | Probably the most common case where this comes up is in
               | the context of hard links: two (or more) files with
               | different names that point to the same inode. I guess
               | actual usage of hard links is rare enough that it doesn't
               | come up all _that_ often, but I 'm actually surprised you
               | didn't know this - not judging you, just something I
               | thought most more experienced Linux/Unix users knew, but
               | it seems not.
               | 
               | Hard links can be a somewhat notorious footgun due to
               | this by the way; with a soft link you _know_ you 're only
               | deleting a link, but with "rm hard-link" this is a bit
               | trickier: if you think there's another link but actually,
               | it turns out you made an error and there's not then
               | you've lost that file. A "hard link" isn't really a thing
               | on its own: it's just another reference to an inode. This
               | is why symbolic links are used in most cases, but you can
               | hard links are still used from time to time in e.g. /bin
               | and some other places.
        
               | pram wrote:
               | You'd never need to know anything about it as a user. I
               | don't know how anyone could seriously make the argument
               | otherwise.
               | 
               | In fact the only reason I know anything about inode and
               | dentry specifics is because they are 'very clever'
               | interviewer favorites! I've been a professional UNIX
               | admin for 15 years and I've dealt with inode issues
               | literally once in my life lol
        
               | kevstev wrote:
               | Thanks. Its comments like the GPs that makes me wonder
               | how I have avoided learning some very commonplace issue
               | and its these types of comments that foment imposter
               | syndrome.
               | 
               | I have even read books on linux architecture and remember
               | discussions about filesystems and inodes and remember the
               | general structure and form, but a detail around what is
               | and what is not stored in the actual inode... seems like
               | an absurd detail to memorize.
               | 
               | The only way I could see this being commonplace is if I
               | somehow missed out on a widespread bug that somehow
               | caused inodes to be corrupted and requiring manual
               | intervention/surgery to prevent data loss.
        
               | pram wrote:
               | It's easy to remember that inode = the stuff that shows
               | up in 'ls -l'
        
           | jozvolskyef wrote:
           | If you ever carried a canister of gasoline, you'd notice it
           | to be uncannily light. It may have been a practical
           | experience question.
        
             | wly_cdgr wrote:
             | > canister....uncannily light...
             | 
             | I see what you did there
        
           | Joker_vD wrote:
           | Well, maybe it'd be better called "aptitude test": if you
           | don't know that gasoline lighter than water that means you've
           | never handled it manually, so better not put you into an
           | automechanic position.
        
             | mongol wrote:
             | It was 2 days of various tests, resulting in a number of
             | scores, physical, intelligence, psycological etc. All
             | together an aptitude test. I don't know why this was called
             | intelligence test, it was a mix of questions, not all of
             | these kind. I remember many were something like "circle the
             | fourth word of the second sentence except if..."
        
         | [deleted]
        
         | AlexAltea wrote:
         | Years ago, while applying to some security engineer position at
         | Google, they were testing low-level skills focusing on
         | vulnerability research, C/C++ and x86. At that point having
         | spent 10+ intense years on that arch: having written binary
         | translators for it, reversing/exploiting software and writing a
         | micro-kernel. After rejection, they recommended me to read a
         | "x86 assembly 101" book which was truly infuriating at that
         | point.
         | 
         | Granted, it was an automated email, but an automated "No" would
         | have been more appropriate. Is it so hard to offer different
         | standard responses? Why does the company consistently fail at
         | human interaction, be it candidates or customers?
         | 
         | From my circles, most share the feeling that FAANG/MSFT are
         | insulting for candidates (I can only speak for
         | Google/Microsoft).
        
           | arthurcolle wrote:
           | Yeah I was asked to complete a pretty challenging question in
           | 25 minutes (eventually solved it after the interview ended in
           | 2 hours) and after it was clear the interview wasn't going
           | anywhere, asked for tips. They said "study data structures
           | and algorithms"
           | 
           | Like... yeah thanks I guess this degree and 5+ years
           | experience isn't worth much. Such a broken process
        
           | im_down_w_otp wrote:
           | Because they have a money printing machine called AdWords
           | which affords them the opportunity to be terrible at anything
           | and everything else without any impetus to recognize it or
           | need to care.
        
           | iovrthoughtthis wrote:
           | feedback is the hardest part of any assessment, not just in
           | interviewing
        
       | napolux wrote:
       | I once had a 3 hours live coding session (without any previous
       | warning it was a live coding session) on a problem described by
       | some examples, while the 3 interviewers were clearly watching me
       | and commenting my code or what I said in their chat.
       | 
       | The expectation was that I made the example exercise + tests.
       | 
       | Fu*k them.
        
       | nmstoker wrote:
       | This is a major red flag that the firm isn't sufficiently serious
       | about hiring and I would always walk away from a firm without a
       | clear idea of their needs and the number of rounds.
       | 
       | My experience with a firm that started with three, then paused,
       | had an "open evening" for interviews and then wanted more (which
       | I politely declined and privately blacklisted them) reminds me of
       | the lucky escape I had: the firm went through this mess only to
       | uncover (a little later) an operational error that left them
       | refunding several billion to clients, trundling on as a zombie
       | firm!
        
       | user3939382 wrote:
       | Recently hired for director level at big startup. 11 interviews.
        
       | napolux wrote:
       | Klarna, is that you? ;)
        
       | StriverGuy wrote:
       | We are looking to solve this over at Chatkick
       | (https://chatkick.com) if anyone is interested in working on this
       | problem.
        
       | suchislife wrote:
       | So much time and money is spent interviewing it seems like it
       | would be cheaper to just subcontract the candidate to do a real
       | task as a trial run. That would give a much more meaningful
       | signal. People say it's a risk mitigation strategy to do so much
       | interviewing; but, is it? Are we sure it isn't just making us
       | feel like we are mitigating our risk? Do we have any data that
       | hire quality goes up with each incremental interview?
        
       | Ensorceled wrote:
       | I think a big part of the problem is how much software engineers
       | are being paid now. 4, 5 or more rounds is not unheard of for a
       | VP/CTO role. Companies are acting like that Intermediate
       | Developer is a critical role because the _pay_ is making it seem
       | like a critical role, they are making what would have been a
       | Director salary within institutional memory.
       | 
       | I just had candidate that was already getting paid what would
       | have been an insane amount a few years ago, get a counter offer
       | that included a 20% raise and significant equity.
        
         | ChrisMarshallNY wrote:
         | Reminds me of this MonkeyUser (love that comic):
         | https://www.monkeyuser.com/2020/new-hire/
        
       | discmonkey wrote:
       | Having recently won the google hiring lottery, I wanted to add my
       | experience
       | 
       | total length of time ~ 7 months emails sent/received ~ 50 phone
       | calls ~ 20 technical interviews: 7 (1 with screen with recruiter,
       | 6 with engineers)
       | 
       | team match interviews: 3 (for me at least these were real
       | interviews, in that I "flunked" the first 2, and decided to take
       | the 3rd one very seriously before getting an offer)
       | 
       | Before getting hiring approval, I honestly felt that I would get
       | rejected, and I can honestly say that being more "personable" and
       | very "communicative" probably had a lot to do with why I made it
       | through.
       | 
       | My honest advice would be to stop thinking of these long
       | interview processes in terms of a a binary outcome that you have
       | complete control over. Instead, think of it as trying to maximize
       | some hidden parameter of a binomial distribution, where every
       | interaction slightly increases your odds in the final coin flip.
        
         | clint wrote:
         | sounds like a literal nightmare, and your prize is... working
         | at Google? No thanks!
        
           | discmonkey wrote:
           | For what's its worth, I really didn't think the technical
           | interviews were nightmares. It was mostly talking with very
           | intelligent people who were volunteering their time to screen
           | candidates. Though how much one enjoys brain teasers over
           | productive work is of course a matter of personal perference.
           | Everything else (emails, phonecalls, etc) were definitely
           | tedious.
           | 
           | As for working at Google, I think it really depends on the
           | person. For me it was a good gamble in terms of both
           | immediate learning and future opportunities; for others it
           | won't be. I do find the opportunity to have my code (or
           | what's left of it after reviews anyways) reach billions of
           | people a thrill like no other though.
        
         | moistoreos wrote:
         | I agree w/ the sentiment of your last statement.
         | 
         | However, I wholeheartedly could not disagree more w/ "having
         | won the <insert_x_silicon_valley_company_here> hiring lottery".
         | 80+ hours of interviewing? No offense, that doesn't sound like
         | winning the lottery. That sounds like you don't value your
         | time. Unless you're getting paid for that many hours of
         | interviewing or receive a signing bonus to make up for it, any
         | company that does 10+ hours of interviewing can take a rusted
         | iron rod and shove it up their own arse.
         | 
         | In a market where software engineers are in super high demand,
         | if a company cannot refine the technical interview(s) down to a
         | max of 3 hours for any specific role, then why waste your time?
         | I understand wanting to gauge a candidate's technical
         | abilities. But there's a balance between understanding the
         | candidate's technical abilities, the technical knowledge
         | required for the job, and (the most important bit) what can be
         | learned on the job for the role.
        
           | discmonkey wrote:
           | Agreed that the hour invested may not be worth it for a large
           | percentage of people (again I got lucky, I would feel so
           | differently if I was rejected after 7 interviews).
           | 
           | Google's point is just that they prefer to avoid false
           | positives at the cost of (potentially) a lot of false
           | negatives. The current interview process is probably some
           | local optimum;
           | 
           | I haven't worked at a company yet that is _actually_ good at
           | interviewing. Where good is optimized over high recall and
           | accuracy and a small time investment.
           | 
           | I know that Google does have one big advantage, in that a
           | good percentage of people that get the offer end up
           | accepting. That (unfortunately) gives Google a lot more
           | leeway and possibly less incentive to further optimize the
           | interview process. Software engineers are in high demand, but
           | also Google is in high demand among software engineers.
           | 
           | At my previous job, trying to find a candidate for a role
           | essentially involved lowering the bar until somebody was no
           | longer in demand, since we weren't "in demand".
        
       | deedubaya wrote:
       | In-house recruiting have few incentives to provide a fast and
       | efficient hiring pipeline.
       | 
       | Slow pipelines mean low conversion rates (survival of the most
       | pain tolerant), generating more internal demand. Natural reaction
       | to to widen the pipe (more recruiters) not speed it up.
        
       | blueyes wrote:
       | The hiring process is fundamentally broken, but not always in the
       | ways that job-seekers think.
       | 
       | It's hard to establish during the interview process that someone
       | will be able to do the job you need them to do. Hiring them is a
       | huge risk, both legal and cultural. It's not easy to fire people,
       | and lawsuits/arbitration are common.
       | 
       | The endless interview process, which costs companies many good
       | candidates, is there because they fear the bad ones they can't
       | recognize.
        
       | lmilcin wrote:
       | Aside from being tech lead for my project I am also technical
       | interviewer and I regularly interview candidates.
       | 
       | Recently I have asked my HR if they could set up longer meetings
       | with candidates because, honestly, 1.5h is in my opinion not
       | enough to evaluate candidate. I would like to ask some technical
       | questions, I would like to see the candidate write some code, I
       | would like to have a discussion on general tech topics just to
       | get the feel of the candidate. And also have time to respond to
       | questions that the candidate may have.
       | 
       | Usually it is the coderpad part that overflows and takes more
       | time but it is also hugely helpful in understanding how candidate
       | works and deals with problems.
       | 
       | So the response from HR was that they "don't want to scare the
       | candidate". And if I need, maybe they will set up follow up with
       | the candidate "just don't tell the candidate upfront to not scare
       | them".
       | 
       | So that's that.
        
       | mouzogu wrote:
       | I think the post-covid wfh job market has clouded something a bit
       | which is that the tech industry in particular is becoming
       | increasing oversaturated.
       | 
       | There is so many people applying for positions now that companies
       | are resorting to these more and more annoying filtering
       | processes.
       | 
       | My first job in this field 14 years ago was one interview and I
       | got the job the next day. That would be almost impossible today.
       | 
       | I blame it on two things, oversaturation of the "learn to code"
       | meme and the rise and growth of recruitment agencies and their
       | influence on HR practices. They have to justify their own jobs
       | after all - just 10 years ago there wasn't really much of a
       | concept of an HR or IT recruiter as far as I recall - or it was
       | just emerging.
       | 
       | I've said this before but I believe this field is becoming
       | increasingly commodified. Soon you will be either a "white-
       | collar" fang or a blue-collar "independent contractor".
        
         | nextlevelwizard wrote:
         | As someone who is stuck with a "junior developer" who hasn't
         | produced a single line of working code during past 1.5years in
         | my team the "one interview and done" isn't working these days.
        
           | theonething wrote:
           | how is this person not fired?
        
             | nextlevelwizard wrote:
             | We have too good employee laws. As long as you are trying
             | your best it is really hard to fire anyone. There needs to
             | be evidence that they aren't capable and even then they
             | need to be given multiple chances over multiple months to
             | correct this problem.
             | 
             | Only way to fire someone on the spot is if they are
             | breaking law or refusing to do the work
        
               | supersereneblue wrote:
               | Which part of the world is this happening in?
        
               | valdiorn wrote:
               | this is 100% your companys fault.
               | 
               | If this person is literally not producing anything
               | useful, then set them a basic piece of work and tell them
               | to complete it. If they can't give them a warning, tell
               | them to upskill. Repeat after a month. And again a month
               | after that. If they still can't do it then you have
               | plenty of evidence to justify firing them, anywhere in
               | the world.
        
               | nextlevelwizard wrote:
               | Not that easy with our labor laws
        
       | simonbarker87 wrote:
       | I actively tell career switchers to avoid coming with more then 3
       | rounds unless they really really want to work for that company.
       | 
       | I did 5 rounds over 7 hours with a top tier company recently only
       | to loose out for my solution to one of the 3 coding tests not
       | being as elegant as the interviewer would have liked.
       | 
       | I've been told to speak to them again in 6 months, we'll see.
        
       | buro9 wrote:
       | Ah Amazon... 14 interviews, an additional 5 hour technical test,
       | spanning a total of 3+ months. Only to be informed at the end
       | that I was too technical for the role they had in mind but they
       | were offering me a Senior Principal SDE role instead.
       | 
       | By the time we got to the end of the process I'd already
       | concluded that the hiring process was a reflection of their
       | internal decision making and that this was not a company (or
       | department) I wanted to work for.
       | 
       | Then I was hired elsewhere and I saw something similar happen to
       | a candidate and realised that this was truly an indication of the
       | indecision. We had lots of roles, just none shaped in a way that
       | fitted the person, and what we should've done is reject the
       | person but on that occasion we hired and it was a terrible
       | decision. They were a good person and very capable, but not a fit
       | for the role finally offered. I had the sense that if I had
       | accepted the Amazon role that would've been true for me too.
       | 
       | An interview process of more than 3-4 defined steps that takes
       | longer than a month to schedule, is a bad sign.
       | 
       | Top tip for candidates: Ask what the process is, if they cannot
       | conclusively tell you then double down on interviewing at a
       | company that can.
        
         | TheHypnotist wrote:
         | As i mentioned in another post, don't forget to work in those
         | LP's otherwise you get 0 Bezos points and your experience is
         | worthless.
         | 
         | Edit: Meant LP's. Leadership Principles.
        
           | quietbritishjim wrote:
           | What's GP? Gaussian process? General practitioner? Or, most
           | commonly on HN, grandparent [post]? Or maybe the whole point
           | of using that abbreviation is to exclude those outside
           | Amazon?
        
             | fridif wrote:
             | I think he means LPs, Leadership Principles
        
               | TheHypnotist wrote:
               | Right - I meant LP's, for some reason they are "Guiding
               | Principles" in my head this morning.
        
               | quietbritishjim wrote:
               | If you had said LPs instead, I still wouldn't have known
               | what you meant.
        
             | bombadilo wrote:
             | This is one thing that really pisses me off about hacker
             | news. The excessive use of abbreviations only hinders
             | communication, it doesn't improve it.
        
             | [deleted]
        
         | d0gsg0w00f wrote:
         | I honestly think this is a product of large corporations being
         | essentially incapable of firing bad resources. Companies are
         | terrified of litigation and bad PR so the only control
         | mechanism is the interview process.
        
           | buro9 wrote:
           | I do not disagree.
           | 
           | The more people who interview, the more average the candidate
           | has to be to succeed.
           | 
           | For all the talk of "hire fast, fire fast" the reality is
           | that most companies do not know how to evaluate someone
           | within the probation time period in which they could let go
           | of someone with ease (usually under 60 days) and after that
           | they then fear doing so even when it's miserable for both the
           | person (candidate) and team involved.
           | 
           | I hire a lot, and some of my thoughts on the process:
           | 
           | 1. The interview process should be short and sweet. 3 steps
           | is enough, if you can't make a decision in 3 steps then the
           | decision is to decline.
           | 
           | 2. The hiring manager should be the first to interview. We
           | have a good idea of what we're looking for in a team and what
           | other roles other managers have open, we can speak of most
           | teams and can spare both the candidate and ICs from
           | interviews that cannot realistically result in a hire.
           | Likewise, we can increase the chance of a successful hire by
           | having the people from the team the candidate would be
           | joining conduct the interview.
           | 
           | 3. Some of the best candidates get love/hate feedback, a
           | candidate who consistently gets "hire" feedback is seldom as
           | good as those who get "strong hire" mixed with "no hire"
           | feedback. The consistent "hire" usually typifies an "on the
           | fence but don't want to take responsibility for declining so
           | will wave through"... opinions should be stronger,
           | interviewers should be excited for people - challenge whether
           | a consistent stream of "hire" feedback actually means "hire".
           | All that said, always listen to "strong no hire" when it
           | turns up.
           | 
           | 4. To increase diversity you only need to interview people
           | who aren't already over-represented in your org... you will
           | hire those people at exactly the same rate as you hire
           | everyone else. If you don't have these people in your
           | pipeline you have a sourcing or branding/reputation problem
           | so focus on those things. If you do have those people and
           | aren't hiring at the same rate, you have a bias problem and
           | should root it out with urgency.
           | 
           | 5. Degrees are not a signal, so absence of a degree is not a
           | signal.
           | 
           | 6. Don't hire based on what someone has done as it only
           | reflects what their employers asked them to do, instead hire
           | on what they can potentially do - if it lines up with what
           | you want to achieve it's a win-win.
           | 
           | Most of the above can be summed up as: Have an opinion and
           | care about what you're doing.
        
             | 6gvONxR4sf7o wrote:
             | > the probation time period in which they could let go of
             | someone with ease (usually under 60 days)
             | 
             | Is this a thing? I would certainly judge a company doing
             | this, and likely leave a manager who hired someone with an
             | expectation that the beginning is just a probationary
             | period, if I'm understanding you correctly (I hope i'm
             | not).
             | 
             | Leaving a safe job for a probationary period puts too much
             | risk on the employee that the employer doesn't really
             | share.
        
               | thrwyoilarticle wrote:
               | IME most UK jobs have probationary periods. There's also
               | a statutory probationary period of 2 years where you can
               | be fired for any[1] reason.
               | 
               | [1] strictly not any reason, you can't be discriminated
               | against, but enough reasons that they could invent one.
        
               | buro9 wrote:
               | Some companies do "hire fast, fire fast"... so yes.
               | 
               | But I choose not to work for those companies, instead I
               | prefer a strongly opinionated hiring process that won't
               | play with anyone's life like that.
               | 
               | That said, treating probation as probation is definitely
               | a thing. Especially in legal domains such as France and
               | Germany. In the USA it's far less of a thing as employers
               | can mostly let go of people at almost any time if they
               | wish to and it's not a pattern of discrimination (though
               | this is the fear of course, that a pattern could be
               | formed).
        
               | 6gvONxR4sf7o wrote:
               | I see. I could imagine accepting something like that if I
               | got legal protections afterwards like some of those
               | countries have.
        
           | abeppu wrote:
           | Why are companies afraid of litigation? My understanding has
           | been that, excluding discrimination on the basis of a few
           | protected categories, sexual harassment retaliation, and
           | whistle-blower protections, in the US private employers can
           | fire non-union employees at any time without cause. (IANAL)
           | 
           | Are large companies really afraid of PR in firing
           | individuals? If a company with many thousands of employees
           | fires one person, outside of the C-level officers is that a
           | news story? Even if disgruntled former employee tries to say
           | anything disparaging, doesn't that immediately make them less
           | credible as a source?
        
           | dimmke wrote:
           | This is not the case at Amazon. They are known for PIPing
           | engineers. They're not shy about it.
           | 
           | Also all of these big tech companies can just not refresh
           | your stock if they don't want to bother with firing you,
           | which effectively halves your compensation.
        
         | amznbyebyebye wrote:
         | Sr principal is like L8 so you're easily taking close to
         | 1M/year salary.. 14 interviews is still a bit much, but you're
         | basically one step away from distinguished engineer which is
         | pretty much end of the road for the engineering track at amazon
        
           | majani wrote:
           | If he has the skills to get such offers, then he's in a power
           | position with employers, which explains his demeanor towards
           | them
        
             | amznbyebyebye wrote:
             | Definitely, if you're being recruited for L8, thats a level
             | of distinction all on its own..
        
               | buro9 wrote:
               | Hard to know what to make of these comments.
               | 
               | I've known a lot of far better engineers than I am. We've
               | all been in this game a long time. Titles, companies and
               | package aren't the most important thing to any of them.
               | I'm sure most will look back and even though our titles
               | and roles appear to have changed it feels like we still
               | do much the same as we always did, just at a different
               | scope and what's important is whether the work is
               | engaging, there's as little politics as possible, and
               | you're setup for success.
        
           | buro9 wrote:
           | I can't say on the money front I didn't kick myself after I
           | had declined, and the interviewing was at a very high level.
           | At the time I was focused on finding a role that had my
           | requirements for high job satisfaction and money wasn't an
           | important part of that (I'm not rich, but money wasn't
           | important then and isn't now, we only have one life to live).
        
       | duxup wrote:
       | I call it the 'hiring people industrial complex'.
       | 
       | It's endless, every little bit of concern about personality or
       | "We did this at X." place and "Need this guys input." are added
       | and has zero proven value, but it is added.
       | 
       | At one company I worked at it wasn't uncommon for a department to
       | decide to hire someone and HR or the recruiters somehow were able
       | to hold things up for months.
       | 
       | My most recent job was at a smaller (not a start up) company and
       | as an applicant I was talking to people I would work with and was
       | asked legitimate questions and etc.
        
       | austincheney wrote:
       | I remember the one time I worked at a design agency. 6 separate
       | interviews in one day. The account managers were thrilled with me
       | and absolutely did not want anybody else. The technical people
       | were far less confident because nobody in their right mind could
       | possibly hate jQuery. That meant some more interviews.
       | 
       | What's maddening about that is that this was for a consulting
       | position not a developer position. It didn't matter though
       | because the contract written one way, the management at the
       | client refused to accept the terms of the signed contract, and
       | the developers I was there to help thought I was their
       | subordinate to dictate.
        
       | diogenescynic wrote:
       | A lot of jobs will put you through multiple interviews then ghost
       | you. I interviewed at several tech companies last year and it was
       | crazy how few would email a simple letter saying they had moved
       | on in their search. It's like they want the option to put you on
       | the back burner for weeks and then reach out again if things fall
       | through with others. Really gross and selfish.
        
       | itsbits wrote:
       | Here most of them seems to be pointing at number of interviews
       | that's being conducted for a candidate by the companies and how
       | emotionally torment it can be.
       | 
       | I can tell you it's not an easy job to take interviews as well. I
       | have been interviewing candidates for my company for past 4-5
       | years. It drains your brain a lot than giving interviews IMO.
       | Sometimes I get exhausted and frustrated for the day after taking
       | 4-5 interviews. start to feel, brain stops functionating. And
       | frustrating thing is you have to provide feedback for audit
       | purposes in more than 100 words. Especially rounds like System
       | Design, Hands On coding, Knowledge of Technologies, Resume
       | drilling.
       | 
       | Also interviews been happening continuously at least for past 2
       | years due to attrition issues linked of pandemic. So never ending
       | process now a days to take interviews in the company.
        
       | runbathtime wrote:
       | Do diversity hires have never-ending job interviews? Or are they
       | just streamlined in?
       | 
       | It would be considered oppression if black candidate where given
       | as many interviews as white candidates.
       | 
       | Actually it is a serious question. When diversity is apparent
       | what is the difference in the number of interviews required?
       | 
       | Are white and asian males more scrutinized to make up for the
       | logical shortfall of affirmative action hires that just get to
       | mess stuff up while the asians clean up their mess?
        
       | phibz wrote:
       | I interviewed with a company out of SV that did this. They
       | started with 3, added another 3, one hour interviews and finally
       | another 3. 9 interviews over the course of almost a month.
       | 
       | I was being interviewed for a principal engineer. I was very
       | clear and kept saying I wanted a management track position. They
       | kept saying we love your background we can work with you on this.
       | Ninth interview was with the CTO. He said the same. Them ghosted.
       | Wouldn't answer my emails or calls. 9 hours, plus prep time
       | wasted.
       | 
       | The company I ended up getting hired by also did a large number
       | of interviews, 8. And they took even longer. Just over three
       | months from initial contact. They're fantastic to work for, but I
       | do think there comes a point where if you keep digging you're
       | going to find something you don't like.
        
         | wittyusername wrote:
         | I think it's time to name and shame not sure why you are being
         | coy when they jerked you around so much.
        
           | gedy wrote:
           | Yeah it really bugs me when companies reach out to
           | experienced people, put you through multiple rounds, only to
           | ghost and ignore you after. I'm looking at you Glassdoor.
        
           | phibz wrote:
           | Fandom.
        
           | jay_kyburz wrote:
           | I'm too shy to name and shame, but my former company would
           | ask us to advertise and interview for jobs, but only after
           | countless hours of interviews decide they didn't want to
           | increase headcount. I lost about 1 day week for months doing
           | our best to find great people. We would fly them in from all
           | over the place. This happened multiple times. I think I left
           | to make indie games after the third time.
        
       | imroot wrote:
       | Redhat: This one was for you. From the moment I applied through a
       | recruiter until I got an offer letter was about 13 months.
       | 
       | In that time, I had already started my new job -- I didn't
       | actually take the role at RedHat, but, I was able to use their
       | offer letter as leverage to increase my salary.
       | 
       | I've worked for YC companies, I've worked for large companies.
       | The larger companies seem to be a little bit easier to get into:
       | my only interview at Luxottica was literally someone asking me
       | about some retail experience I had about 20 years ago and some
       | very basic Linux questions (retail technical architect position),
       | but, I've had YC companies have a multi-month long interview
       | process where I've been told after 10 or 11 interviews that they
       | thought I was "Too senior for the role," which, just kinda blew
       | my mind.
       | 
       | The whole process is broken, but, there's not really a good
       | solution to fix it.
        
       | chadcmulligan wrote:
       | Don't they have a 3 month probation period where they can just
       | say nah, it's not working?
        
       | bryanrasmussen wrote:
       | I had a round at accenture about 8 months ago, multiple
       | interviews over a month and a half maybe; and it went first
       | interview with a manager wanted me to go forward, second
       | interview someone who okayed me for tech interview and what
       | position I should be looking at, third interview tech interview
       | said fine now you need to talk to HR head and she will make final
       | determination, HR head said send you info later in day some days
       | later still nothing, about a week later message from HR needed to
       | have another interview with someone, consulting offer came in I
       | figured well this isn't going anywhere took consulting offer.
       | 
       | 1 week later the managerial guy called up and said ok everything
       | went through now we can talk about the job I said "sorry, I took
       | a job". He wished me good luck but I'm not sure from his voice if
       | he really meant it.
        
       | known wrote:
       | Interviews are an "activity" for HR/Managers to fill in their
       | time sheets;
        
       | ab_testing wrote:
       | I know BBC is writing this from the perspective of a new
       | interviewer. However anybody who is preparing for FAANG or even
       | hangs out on Blind knows that getting into any of these big
       | companies, now includes multiple leetcode style programming tests
       | and system design interviews . Just as a point of reference, CTCI
       | is now on its 6th edition and it is still playing catch up to the
       | ever changing interview processes at these companies.
       | 
       | In fact if you spend time on leetcode , you would get a fair idea
       | of what companies ask LC medium/hard, which ones ask Dynamic
       | Programming and which one will specifically ask questions that
       | are not on LC
        
       | plondon514 wrote:
       | I've applied to and been rejected by Codecademy 3 times. After
       | the 3rd time I decided to build my own just to prove to myself
       | that I could and that the interview process is broken:
       | 
       | https://codeamigo.dev
        
       | kook_throwaway wrote:
       | A family member went through five interviews for blockchain.com
       | at 4-5am (they were in England). For the last one they
       | (blockchain) were asked to do 6-7pm their time but couldn't be
       | assed to have a call after hours and suggested another 4:30am (to
       | us) interview, yet they had no problem asking people who didn't
       | work there to be up at ridiculous hours week after week. The
       | cherry on top was being offered the job at _half_ of what the
       | position should have paid and at a $20k pay cut from what they
       | were told my family member was already making.
        
       | mlengineerio wrote:
       | I have a lot of friends got FB offers and most of them spend
       | between 3 months to 6 months to prepare for the interview. With
       | that level of preparation, some of them have to sacrifice their
       | responsibilities on their day job. It's tough. (you can read some
       | stories from my blog).
        
       | FinanceAnon wrote:
       | All you complaining about the length of FAANG interviews... One
       | of my family members was recently applying for a job to stack
       | shelves in a supermarket. They had to do a tricky 3-hours long
       | multiple choice questions test. After that, they got an email
       | asking to record a video about themselves. No idea what would
       | come after that, but they gave up at this point. All this is also
       | very difficult to go through if you are older and not
       | technologically well-versed.
        
       | gumby wrote:
       | I talked to a company for three weeks -- I went over and would
       | talk to a couple of people, a couple of times a week -- and then
       | decided they wouldn't get their act together.
       | 
       | I didn't mind the way it unfolded -- people were busy, I wasn't
       | working, and it was only a couple of minutes away from me, so
       | really it was only perhaps 8 hours. But after three weeks _I_
       | felt I wasn't getting the answers I needed and they didn't seem
       | to be making progress on the hire. So I said no thanks.
       | 
       | This was a company with 50 or so people -- I have no idea how
       | they managed to hire them.
        
       | lysecret wrote:
       | So, I have been hiring a lot for 2 startups i was involved one
       | was a kind of bootcamp which involved basically a never ending
       | hiring process.
       | 
       | I learned a lot about hiring there and how incredibly stupid and
       | broken the standard hiring process is of big comps.
       | 
       | If anyone tells me to invert a binary tree now i just get up an
       | leave haha.
       | 
       | But my main takeaway there was that this is actually a huuuge
       | competitive edge Startups have. They dont have to adhere to the
       | BS standard process and can snatch up a lot of good talent which
       | falls out of the standard metrics.
        
       | vegetablepotpie wrote:
       | What's happening is that companies want to completely remove risk
       | from the hiring process.
       | 
       | In the real world, you cannot remove risk. You can manage it, but
       | you cannot remove it. Asking candidates to go through 6
       | interviews before making a decision and not telling them when a
       | decision will be made signals a risk adverse culture that cannot
       | make decisions.
        
         | DSingularity wrote:
         | The reason they want to remove the risk is because it takes
         | years to prune bad talent.
        
           | chunkyks wrote:
           | And they're also in the situation where good talent isn't
           | going to tolerate that rubbish.
        
             | Swizec wrote:
             | The worst performer you tolerate on your team sets the tone
             | for the whole team.
             | 
             | The best teams embrace and level up their low performers
             | and make the whole team better.
             | 
             | The delta can't be too big.
        
           | zhte415 wrote:
           | Do you have probation period where you work? i.e. if an
           | employee doesn't live up to expectation, release with short
           | notice? Where I am, a 3 year contract typically carries a 3
           | month probation period, and a 1 year contract carries a 1
           | month probation period.
           | 
           | The problem is management are often too busy or overwhelmed
           | with other stuff to observe and provide feedback until
           | someone's passed the probation period then releasing them
           | becomes a bureaucratic nightmare - and when the new hire's
           | not getting feedback, you can be sure not a lot of the rest
           | of the team are.
        
             | sgerenser wrote:
             | Probation periods in the US are rare, especially for white
             | collar positions like software engineers. Of course, that's
             | mostly because of at will employment where either side can
             | choose to part ways at any time.
        
               | ClumsyPilot wrote:
               | That sounds like infinite probation period to me
        
           | hnzix wrote:
           | They'll miss most of the good talent if they're doing 6
           | interviews for a standard role. The candidates with skills
           | and options will go elsewhere and you'll be left with the
           | desperate dregs.
        
           | CogitoCogito wrote:
           | > The reason they want to remove the risk is because it takes
           | years to prune bad talent.
           | 
           | I've never understood this given that the hiring is so often
           | at will.
        
           | madengr wrote:
           | How? I have seen people with 25 years service (electrical
           | engineer) walked out with zero notice. Unless you are
           | unionized, you can be fired on the spot.
        
             | dahart wrote:
             | Increasing risk of liability for firing is real, as is
             | increasing oversight of discrimination law. You can be
             | fired on the spot for breaking company policy, or doing
             | something illegal. Without more info, that's what I might
             | assume you saw. But getting fired for mildly low
             | performance without notice is not normal, at least not
             | among engineers in large companies, and assuming it's not
             | because a division or the company is being shuttered.
             | Companies have to give people feedback and give them time
             | to respond. Failure to do that can and sometimes does
             | result in legal action compelling the company to prove the
             | employee was failing and that the company did not unfairly
             | discriminate even unknowingly, which is costly, difficult,
             | and risky. Plus, most companies aren't capricious with
             | firing engineers, and are also aware that hiring is
             | expensive and employee ROI can take time.
        
               | learc83 wrote:
               | > result in legal action compelling the company to prove
               | the employee was failing
               | 
               | The company doesn't have to prove that the employee was
               | failing. It's perfectly legal for a company to fire an
               | employee because they the employee likes the wrong
               | football team.
               | 
               | The employee or people pursuing legal action on behalf of
               | multiple employees has to prove that the company fires
               | the employee(s) _because_ they were a member of a
               | protected class.
               | 
               | Assuming there are no incriminating emails stating that
               | that was the reason, the only realistic way to do that is
               | to show a pattern.
               | 
               | If an employee decides to sue, whether you had them on a
               | documented performance improvement plan for 6 months or 6
               | days isn't going to be the deciding factor.
        
               | dahart wrote:
               | > The company doesn't have to prove that the employee was
               | failing.
               | 
               | They do if the employee sues claiming age discrimination,
               | for example. At least, they have to defend the accusation
               | to show it's not discrimination. When someone has been at
               | the company for 25 years like in the parent's example,
               | and they get fired abruptly without notice for liking the
               | wrong football team, it's likely the stated reason is
               | untrue and inviting a challenge.
               | 
               | > If an employee decides to sue, whether you had them on
               | a documented performance improvement plan for 6 months or
               | 6 days isn't going to be the deciding factor.
               | 
               | It certainly helps show that the company isn't
               | discriminating arbitrarily, and gave the employee notice
               | and a chance to improve the situation.
               | 
               | BTW actual legal action isn't necessary for firing to be
               | getting harder. The fear of legal action is all you need,
               | and that is in fact going up.
        
           | throwawaylinux wrote:
           | Taking years to prune bad talent is another sign of a problem
           | in the organization.
        
           | 2001lodyssee wrote:
           | In my long and storied career, well long at least, every
           | single truly heinous, project-killin', crazy person actually
           | interviewed pretty well.
           | 
           | Honestly, I don't have a good solution to the problem.
        
             | akamia wrote:
             | I have experienced the exact same thing. In fact, the worst
             | person I have ever worked with consistently aced interviews
             | wherever he went.
        
             | Rapzid wrote:
             | Fire fast. Use that 90 day try out period. Contract-to-
             | hire.
             | 
             | In the past I would never have been interested in a
             | contract-to-hire. These days though if the company and role
             | is right, and this an option to short-cut a ridiculous
             | interview process, I might spring for it.
        
               | duped wrote:
               | Just personally I would never accept an offer that was
               | contract for hire and think it's downright insulting a
               | suggestion. My family needs health insurance and the
               | market has never been so cold that I'd be desperate
               | enough to take such a garbage offer.
        
               | Rapzid wrote:
               | Nothing about contracting precludes having health
               | insurance though? For the roles and situations I'm
               | talking about this would all just be factored into the
               | rates.
        
               | tfehring wrote:
               | Even if they can just pay for health insurance out of
               | pocket, they'd be switching plans twice, and each time
               | they'd reset their deductible and possibly need to find a
               | new doctor.
               | 
               | When I was an actuary we used to do "intern to hire" for
               | unemployed recent grads, but I can't imagine leaving a
               | full time position for a contract-to-hire position. I
               | think for me personally the opportunity would have to be
               | really interesting _and_ the comp upon converting to FTE
               | would need to be at least double my previous comp
               | (meaning the contracted rate would probably be something
               | like 4x my implied hourly).
        
               | duped wrote:
               | I've only ever seen it done in legally dubious ways to
               | skirt paying benefits for 3-6 months for new hires in
               | entry level positions.
        
               | 2001lodyssee wrote:
               | > Fire fast. Use that 90 day try out period. Contract-to-
               | hire.
               | 
               | I've see that work before, but it was some time ago. The
               | company also had a very large test department with
               | separate management and kept to a strongly enforced
               | waterfall-esque design routine.
               | 
               | Of course, it used to be a lot harder to ship out version
               | 1.01 of the software.
               | 
               | I just assume it was a different world as this was in the
               | days of US manufacturing, very limited set of software
               | tools, high importance placed on domain knowledge as
               | opposed to toolset, longer average stays at employer,
               | lower wages for programmers. Probably not applicable to
               | modern times.
        
             | Salgat wrote:
             | The solution is to accept that shitty candidates can't
             | always be filtered out and to have a probation period to
             | remove them before they do too much damage to your
             | codebase/morale.
        
             | MattGaiser wrote:
             | I suspect the reasons they killed the project were all over
             | the map too, so you are basically searching for a big
             | unknown problem.
        
               | 2001lodyssee wrote:
               | I would also suspect that any filtering mechanism that
               | cuts out the truly destructive people might well be
               | either unacceptable or illegal at this point.
        
             | dredmorbius wrote:
             | It's a bit like the good-books/bad-movies phenomenon.
             | 
             | There's a quality-distribution of both books and films.
             | 
             | There are only so many good books. And a percentage of
             | films end up poorly made.
             | 
             | Sufficiently low-quality books tend not to get made into
             | films. The ones that succeed are notable --- there's
             | nothing but upside.
             | 
             | A good book can be made into either a good or a bad film.
             | If it's a good film, then yay, but if it's a _bad_ film,
             | people are _aware_ of it (through the book 's quality and
             | popularity). This is a _perception illusion_ called Berkson
             | 's Paradox. It's an illusion because what awareness fails
             | to account for are all the bad films made from bad books.
             | 
             | Hannah Fry of Numberphile does a much better job than I of
             | explaining this: https://youtube.com/watch?v=FUD8h9JpEVQ
             | 
             | In the interviewing / performance case, you have good vs.
             | bad interviewees, and good vs. bad performers.
             | 
             | Someonehone who interviews poorly but performs well is a
             | positive exception. Someon who interviews well _and_
             | performs well meets expectations. It 's the good
             | interviewer/bad performer who stands out. But it's the
             | poor-interviewer/poor-performer who is missed by this
             | assessment.
        
             | danjac wrote:
             | There's probably not a single one-size-fits-all solution -
             | what works for FAANG and their millions of applicants is
             | lunacy when you're a three-person startup, much like
             | adopting Kubernetes to run an internal web app with half a
             | dozen users. It probably starts with proper training in
             | conducting interviews, a respect for candidates' time, a
             | realistic appraisal of your needs and budget, and constant
             | feedback-driven refinement of your process.
        
           | technofiend wrote:
           | Isn't that one of the things Netflix is famous for getting
           | right? Generous severance but quick to exit you if you're not
           | a good fit.
        
           | caoilte wrote:
           | I don't think it's that at all. It's very easy to fire people
           | in US. I think they are trying to hire cultists. The harder
           | it is to get in the more people think they're special once
           | they do and the less likely they are to leave.
        
             | finolex1 wrote:
             | The difficulty isn't with regards to the process/legality.
             | It's more behavioral/organizational
        
         | twelve40 wrote:
         | I don't know if you've been through the firing process on
         | either side, but after you go through a couple of dozen of
         | these, and the hit to the morale/performance they entail, not
         | to mention emotions involved, you tend to at least try to vet
         | better to avoid such huge distractions in the future (a lose-
         | lose for everyone involved!)
        
           | analyst74 wrote:
           | I'm not sure if people prefer Amazon's PIP culture. That's
           | what it'll lead to if companies hire more loosely and have to
           | fire people more frequently.
        
           | bb88 wrote:
           | One Fortune 500 company I worked for was honest enough to
           | admit that the number one reason employees left was because
           | they didn't like their boss.
           | 
           | It's a huge risk on the other side as well. Not to mention
           | that management usually gets to control the narrative and not
           | the employees.
        
         | alephnan wrote:
         | I left a hedgefund interview loop for this reason.
         | 
         | I finished the 7th on-site interview. After I left NYC and flew
         | back home, they wanted a 8th ( phone screen ) interview because
         | one the interviewers lost the results.
         | 
         | On the one hand, this space's modus operandi is more data is
         | always better.
         | 
         | On the other hand, they have to trade and make decisions in a
         | fast paced environment with imperfect information.
        
           | thrwaway122 wrote:
           | funny same experience here. I interviewed for four months at
           | a very select and under the radar fund. Once a week I would
           | go in from 730 am to 9 am and speak with a member of the
           | fund. I got all the way to the end, and in a bout of
           | emotional torment, I turned the offer down. In hindsight, its
           | one of the biggest regrets I have. Would have retired long
           | ago
        
             | kortilla wrote:
             | Why did you turn it down if I may ask? I've made the
             | decision several times to go with lower paying offers
             | because I ended up deciding there was more to life than
             | just a paycheck.
        
           | marto1 wrote:
           | > because one the interviewers lost the results.
           | 
           | yeah, no. You dodged a bullet with that one.
        
         | sp332 wrote:
         | Companies don't want to do job training anymore. Instead of a
         | general background and attitude check, they need to know if the
         | candidate has all of the individual skills that will be used on
         | the job.
        
           | danbmil99 wrote:
           | If that's true, then the interview process would focus more
           | on skills. From what I hear, faang companies are all about
           | the leetcode on the Whiteboard oh, and they don't seem to ask
           | specific questions about domain knowledge. In fact, you often
           | don't know which department or project you're going to be put
           | on when you get hired by one of those companies. And
           | apparently the interviewers don't know either.
           | 
           | At least a few years ago, Google made it a point that the
           | interview process was generic, not specific to any position
           | or team. More like an undergraduate admissions process.
        
           | kinkrtyavimoodh wrote:
           | Job training is not as much worth it for companies when
           | employees can switch jobs at the drop of a hat.
        
             | jimbob45 wrote:
             | You say that and I've seen several companies in practice
             | echo what you're saying. However, I fail to understand why
             | they don't simply make better use of contracts and
             | probationary periods to solve that specific problem.
        
               | kinkrtyavimoodh wrote:
               | Contacts in what sense?
               | 
               | Probationary periods could work but it's a coordination
               | problem. Such periods are the norm in Europe (coz it's
               | very hard to fire someone) but for an at-will place like
               | the US, given that the industry doesn't really do
               | probationary periods in general, any employer who starts
               | doing it would be at a disadvantage.
        
               | xcambar wrote:
               | I think GP meant "reference check"
        
               | jimbob45 wrote:
               | I meant "contract" but you've brought up another good
               | idea.
        
               | jimbob45 wrote:
               | *contracts
               | 
               | In the sense of offering signing bonuses for term lengths
               | that get repo'd if the contract length is broken.
        
               | danjac wrote:
               | The problem of a probationary period is that it pushes
               | all the risk to the employee.
               | 
               | While I agree interviewing has gotten ridiculous with all
               | the leetcoding and ten rounds of interviews and FAANG
               | cargo-culting and whatnot, one small advantage - assuming
               | I'm not desperate for a paycheck - is that it gives me,
               | as a prospective employee, time to consider and withdraw
               | my application if I see too many red flags or I just
               | prefer the devil I know.
               | 
               | A short interview process with a probation period on the
               | other hand is a big roll of the dice. Maybe I'm not able
               | to ramp up on time, or make a silly mistake due to
               | unfamiliarity with the codebase or underlying business
               | logic. Maybe I don't get on with the team or manager.
               | Maybe I'm going to be dumped into a doomed death march
               | project on day 1. I could find myself unemployed a month
               | later with an embarrassing gap in the resume. Perhaps on
               | the other hand a better interview process (not longer,
               | just have properly trained people and constantly improve
               | the process with feedback) would save us all that pain.
        
               | sokoloff wrote:
               | In a world where short, high-risk interviews dominated,
               | you could just go roll the dice again. It would be a
               | negative signal (why is @foo interviewing after only 60
               | days?), but nowhere near as bad as "why is @foo still
               | interviewing after 6 months in this job market?!".
        
             | godelski wrote:
             | Then give them a reason to stay (note: it's also not all
             | about money)
        
               | austhrow743 wrote:
               | Whatever you offer, including non-monetary, someone else
               | can offer and then also spend their training budget on
               | higher comp.
        
               | newsyyswen wrote:
               | Not necessarily. It's not easy to find a boss who you
               | genuinely trust to consider your best interests, for
               | example.
               | 
               | Out of curiosity, what sort of "non-monetary" benefits
               | were you thinking about? There's usually not a reliable
               | way to turn (small amounts of) money into the sorts of
               | things that really build loyalty.
        
               | epicureanideal wrote:
               | That works if this is a "one time game" (game theory) as
               | opposed to a repeated game.
               | 
               | If an employer does do training, it means they'll
               | probably continue to do more training over time, which
               | helps the employee become more valuable.
               | 
               | If the employer doesn't do training, yes they may be able
               | to allocate the training budget to salary, but they are
               | not going to spend anything training you or letting you
               | work on projects to increase your skills while you're
               | there, unless they absolutely must.
               | 
               | I think people also have some human perception of how
               | they're being treated, and prefer to work for people that
               | invest in them.
        
               | godelski wrote:
               | Is this supposed to be a rebuttal? I don't see a problem
               | here.
        
               | austhrow743 wrote:
               | Yes. Spending money and then not recouping is a losing
               | strategy.
        
               | brewdad wrote:
               | So the answer is to not spend the money at all? How much
               | are you costing your company by putting candidates
               | through 8 hours of interviews only to reject them. Rinse.
               | Repeat.
               | 
               | All the while, productivity suffers as the remaining team
               | falls further behind due to short-staffing and being
               | pulled away from their real jobs to interview.
        
               | ABCLAW wrote:
               | Professions mandate training minimums per year in order
               | to maintain credentialled status. They're low, sure, but
               | they at least create a need for ongoing professional
               | education.
        
               | godelski wrote:
               | I literally said it isn't all about money. Most people
               | leave because managers[0]
               | 
               | > In general, people leave their jobs because they don't
               | like their boss, don't see opportunities for promotion or
               | growth, or are offered a better gig (and often higher
               | pay); these reasons have held steady for years.
               | 
               | And if it is about money, then this is called paying
               | competitively.
               | 
               | But lastly, recognize that if everyone is training
               | employees you're still not really losing out unless
               | you're only hiring entry level employees. Sure, you might
               | be training someone that leaves, but so does your
               | competitor. But if you're only hiring junior engineers
               | then you're probably doing something wrong that's much
               | bigger.
               | 
               | [0] https://hbr.org/2016/09/why-people-quit-their-jobs
        
               | wyldfire wrote:
               | Every process has pros and cons, you have to weigh the
               | net benefits.
        
               | ClumsyPilot wrote:
               | Working at a company that doesnt pay for my training
               | while my skills fall behond is a loosing strategy.
        
             | ashtonkem wrote:
             | People change jobs at the drop of a hat for reasons that
             | are well within companies' control. It's not like people
             | _want_ all that stress and hassle, they do it because they
             | 're incentivized to do so.
        
               | jcims wrote:
               | Sometimes. Other times they are just sampling what's out
               | there to see what suits them the best, or playing the
               | comp boost game until even their best face forward isn't
               | able to garner a higher offer.
        
               | ashtonkem wrote:
               | The former happens, I'm not convinced that it's a common
               | occurrence. Changing jobs is genuinely stressful, I don't
               | think people do it lightly. The latter is usually
               | something the company could fix, but won't.
               | 
               | Even still, it's obvious that comp alone isn't enough to
               | retain employees. Even FAANG companies, which pay
               | extremely well, have pretty low retention numbers.
               | Facebook does best here, at an average job length of only
               | 2.02 years. If comp was enough, people would stay there
               | longer. This implies that people are changing jobs for
               | reasons aside from "this other company will pay more".
        
               | 6gvONxR4sf7o wrote:
               | It's not just about absolute comp. If google will pay you
               | more, then maybe you leave facebook. That's not because
               | google pays more than facebook, just that it's easier to
               | get a "promotion" by taking a hire role elsewhere than it
               | is to get an actual promotion. It doesn't mean you don't
               | pay market wages, but it does mean you don't pay that
               | person their market wage.
        
               | ashtonkem wrote:
               | That's exactly something companies have under their
               | control. If people are leaving because it is seen as the
               | sure route to a promotion, then perhaps providing clear
               | advancement opportunities internal would reduce this
               | phenomenon and help keep your high performing talent.
        
               | jcims wrote:
               | The present employer and prospective employer have a
               | different perspective on the individual. It's entirely
               | possible, and indeed somewhat common, that individuals
               | are hired to levels to new employers beyond what they
               | would be able to justify promotion at their existing
               | employer. The only way to eliminate this is prolonged and
               | comprehensive interview process, which is what TFA is
               | railing against.
        
               | ashtonkem wrote:
               | I disagree that this is the only way to eliminate this
               | problem. Companies could loosen promotion criteria to be
               | more in line with what external candidates bring.
               | Ultimately the cost of lost knowledge and backfilling is
               | quite high, and could easily justify faster promotion
               | cycles on a monetary basis alone.
               | 
               | Even if some of them genuinely get promoted before
               | they're ready and wash out, you're not really that much
               | worse off than if you'd lost them before. Besides,
               | there's always the risk that your new hire is unprepared
               | too, which is a much harder thing to quantify.
        
             | MisterBastahrd wrote:
             | That works when you're employing a bunch of Wordpress
             | monkeys who do nothing all day but mess with CSS and
             | install plugins. Not so much when you've got a mature SAAS
             | product, parts of the system are tricky to work with, and
             | stakeholders are breathing down your neck to implement new
             | features so you don't have time to cross-train your teams.
             | 
             | Losing people who are experts within the domain of the
             | software they're maintaining because you refuse to invest
             | in them is going to cost you thousands of dollars... the
             | only question is whether that's tens or hundreds times that
             | amount... and in some cases it can cause you to lose your
             | entire business.
        
               | gentleman11 wrote:
               | I'm friends with a few "Wordpress monkeys," as well as
               | some people who "do nothing but mess with css all day."
               | That was extremely condescending and dismissive
        
             | anchpop wrote:
             | Yep. Apprenticeships solved this problem in the past (and
             | of course created many others). Actually it's almost a fun
             | little exercise in economics.
             | 
             | Basically there's two types of efficiency, investment
             | efficiency and allocative efficiency. (There may also be
             | other types I don't know about.)
             | 
             | Investment efficiency means people are incentivized to make
             | positive-expected-value investments. Think about how people
             | are incentivized to invest in their house, e.g.
             | preventative maintenance, because if the expected value is
             | positive then they will recoup that value when they sell
             | the house. If you're renting you don't have this with
             | respect to where you live - water damage or no, not really
             | the renter's problem. Investment efficiency is maximized by
             | private property, where you know that no one will take your
             | property without your consent.
             | 
             | Allocative efficiency means things go to whoever is
             | willing/able to pay the most for them. Renting does have
             | this property - if both of us want to rent a house, and I'm
             | willing to pay more, in most cases I'll end up getting the
             | house. This is why gentrification can cause displacement -
             | when wealthier people come into a city and are able to
             | outbid the current renters, they win and the current
             | renters lose. Allocative efficiency is maximized by
             | auctions and things like them, where the good goes to
             | whoever is willing to pay the most.
             | 
             | Bringing it back to your comment, job training isn't worth
             | it because our careers as programmers are dominated by
             | allocative efficiency, not investment efficiency. If you
             | can train a programmer create $50,000/year more value in
             | general (i.e. it's not training that would only be useful
             | to your company), they can now get paid about that much
             | more from any of your competitors, and you will have to pay
             | them about that much more to stop them from leaving. So you
             | gain nothing from giving them general-skills training.
             | 
             | Another way of solving this problem is with sectoral
             | bargaining. If you have a sector-wide union, they can make
             | all companies start training simultaneously, or assume some
             | of the costs themselves. It's a win-win for the industry
             | and for the programmers, but it doesn't happen nearly as
             | much as it could because of that coordination problem.
        
               | ladyattis wrote:
               | >Yep. Apprenticeships solved this problem in the past
               | (and of course created many others). Actually it's almost
               | a fun little exercise in economics.
               | 
               | But it makes Reginald the investor angry that his ROI
               | isn't exactly 20% each quarter, so they jettison
               | apprenticeships and start cooking the books to make that
               | possible.
        
               | sokoloff wrote:
               | So, in this hypothetical, the sector-wide union is
               | preventing individuals who learn to create an additional
               | $50K/yr in value from realizing the increase in pay which
               | would otherwise accrue to them?
        
               | ptx wrote:
               | In return for wasting training on employees that will
               | leave for other companies, the company is getting its
               | employees trained for free by other companies in the same
               | way. In aggregate everyone wins because employees now get
               | training.
               | 
               | The union is ensuring that no company can ruin it for
               | everyone.
        
               | anchpop wrote:
               | Yeah, or at least they aren't able to capture the entire
               | $50k/year in value. It kind of sounds bad but it's a
               | trade and there has to be something in it for both sides
               | for it to happen.
        
             | coffeefirst wrote:
             | I have no idea why people think this. I've trained all
             | sorts of people on all sorts of new things and it was
             | always worth it.
             | 
             | Sometimes they leave. By that time they've used what
             | they've learned and passed some of it on to the next
             | person.
        
               | planet-and-halo wrote:
               | Incredible that you're the first person I've seen mention
               | a second-order effect in this conversation.
               | 
               | I don't know what it is but I feel like people have
               | forgotten just like basic truths about how humans work.
               | Maybe it's because managerialism has infected everything.
        
           | LAC-Tech wrote:
           | This a hundred times over. I still remember in 2020 multiple
           | places asking me "I see you've used .NET core, what *version*
           | have you used?".
           | 
           | I had a kind of career crisis/breakdown, where I realised no
           | one gave a shit about anything except my utility as a walking
           | set of tech keywords. Accepting that it wasn't working for me
           | was one of the best things I've done for my career.
        
             | amitport wrote:
             | The fact that they ask this question does show some bias
             | but it may not be as much as you think. I can interview a
             | person and be interested in finding out how much he/she
             | fits like a glove for the tech stack _and still_ put more
             | focus on other qualities. Moreover, I expect a capable dev
             | to not be too judgmental /unconfident and just answer
             | something along the lines:
             | 
             | "No, I'm not familiar with this, but I have done [market
             | themselves, mention relevant experience, ask relevant
             | questions] and I'm confident I can get the job done"
        
             | stadium wrote:
             | > Accepting that it wasn't working for me was one of the
             | best things I've done for my career.
             | 
             | How did you pivot after this?
        
             | purplecats wrote:
             | did you expect others to have empathy for you?
        
               | vmception wrote:
               | I think the bigger issue here is that this process has
               | made it too random and dilutive of the candidate pool.
               | 
               | Many software engineers have accepted that they have to
               | continually learn and will do so.
               | 
               | This process though, makes it impossible to know what to
               | learn with an impossible random and unknown credential
               | set. It's not the same as something like elevator
               | attendants having an obsoleted skillset. It's a
               | combination of not having time in a lifetime to even try
               | to specialize in the random employer chosen skillset.
               | When instead, employers should expect a good engineer to
               | adapt quickly and employers should also commit to
               | training staff.
        
               | purplecats wrote:
               | > When instead, employers should expect a good engineer
               | to adapt quickly and employers should also commit to
               | training staff.
               | 
               | At the risk of suggesting you might be dating yourself, I
               | think this is an outdated model. It's simply no longer
               | realistic. I personally believe that having personal
               | expectations of what my adversaries or those outside of
               | my control "should" do will inevitably result in sadness
               | on my part.
               | 
               | Corporations will aim to do what they must to increase
               | profits (given, by definition). Any additional
               | assumptions from that are liable to be faulty. Perhaps
               | you are used to the times when they needed to train staff
               | but that's simply a symptom of the circumstances as
               | opposed to a duty.
        
               | vmception wrote:
               | I'm not used to that time, it would be more productive
               | than what is currently happening which does not increase
               | the profits of the corporations
        
               | LAC-Tech wrote:
               | It's not that I wanted them to love me for who I am as a
               | human or anything.
               | 
               | It's that I firmly believe that there's more to software
               | dev than just knowing a 'stack'. And even then, fair
               | enough if they were curious about my .NET skills. But
               | them asking about specific versions of .NET core really
               | woke me up into how much of a commodity labourer they
               | were trying to turn me into.
        
             | MattGaiser wrote:
             | > where I realised no one gave a shit about anything except
             | my utility as a walking set of tech keywords.
             | 
             | I am genuinely asking. Why is this objectionable?
             | 
             | Why do people find it so horrible that their labour is a
             | commodity? To me that just tells me I should treat my
             | labour like a merchant treats his goods. Always be checking
             | the market to ensure you have something worth selling and
             | while you might sign long term deals, periodically check
             | for the best price to ensure you are getting it.
             | 
             | Why is it important to you that your employer view you as a
             | person?
        
               | pabs3 wrote:
               | Because people have brains, can learn new things and
               | technologists don't need experience with particular
               | technology to be successful using or working on it.
        
               | LAC-Tech wrote:
               | > Why is it important to you that your employer view you
               | as a person?
               | 
               | It's not about being viewed as a person. It's about being
               | viewed as a professional.
        
               | MattGaiser wrote:
               | Ah. I understand this objection.
        
               | planet-and-halo wrote:
               | Great response. This is why I ended up not becoming a
               | teacher, despite everyone and their brother telling me
               | that that's my calling (I still hear this at work
               | constantly from people I train). I could have absolutely
               | dedicated my life to something with low pay. What I would
               | not do is accept an environment where I was not treated
               | as a professional. As far as I can tell, the modern
               | American education system treats its educators like crap
               | and hamstrings them every step of the way. No thanks.
        
               | dcolkitt wrote:
               | Because selecting candidates based on tech stack is
               | almost universally the sign of incompetent tech
               | management. Anybody who understands software, knows that
               | intelligence and master of fundamentals trumps tech stack
               | experience without exception. Linus Torvalds would
               | unquestionably become a better Ruby on Rails developer
               | within four weeks than 90% of people with 10 YoE in it.
               | 
               | Good organizations hire talented and bright people with
               | mastery of CS and SWE fundamentals. Bad organizations
               | think "oh we use Java, better hire Java programmers".
               | Really bad organizations think "oh we use JUnit, Spring
               | Boot and IntelliJ, better hire people with experience in
               | JUnit, Spring Boot and IntelliJ"
               | 
               | One of the strongest signals of how good an engineering
               | organization or a tech team is how few specific
               | technologies they list in their job ads.
        
               | gentleman11 wrote:
               | I got turned down once by somebody in hr because I didn't
               | write I had experience with .net but rather wrote c# on
               | the paper.
        
               | golemiprague wrote:
               | Usually a language is not only a language, it is tools,
               | paradigms, frameworks, libraries, conventions and many
               | other bits and pieces one needs to know. So while there
               | is some commonalities it usually takes time to get to a
               | certain level of productivity, which is sometimes
               | required sooner rather than later.
        
               | asp_net wrote:
               | This is so true.
        
               | gregsadetsky wrote:
               | I absolutely agree with your take.
               | 
               | Case in point: a Stripe job listing I picked at random
               | 
               | https://stripe.com/jobs/listing/backend-api-engineer-
               | core-mo...
               | 
               | No single language is named! And this specific sentence
               | is a really great sign (unsurprisingly)
               | 
               | "Languages can be learned: we care much more about your
               | general engineering skill than knowledge of a particular
               | language or framework."
        
               | rgallagher27 wrote:
               | On the other hand, it would be nice to know the core
               | languages in play. I have no interest in working in Java
               | anymore, I avoid job listings for companies that would
               | expect me to write Java. I don't want to have to go
               | through recruiter screens etc before I can ask someone
               | who will know what language I would be spending the next
               | year of my life working with
        
               | gregsadetsky wrote:
               | That's a fair point.
               | 
               | I think that in the specific case of Stripe, they
               | specifically mostly use Ruby (from answers I found
               | online). I may be wrong, but I assume that not mentioning
               | Ruby is a way to attract Python/Go/C/etc. developers that
               | might otherwise think that since they don't code in Ruby,
               | they shouldn't apply.
               | 
               | Your main point (re: Java) remains of course.
        
               | whoooooo123 wrote:
               | Not to pick on Stripe, but why not say this explicitly?
               | 
               | "We mainly use [language X], but you don't need
               | experience in [language X] for us to consider your
               | application" - this is a totally normal thing I've seen
               | in many job postings.
        
               | gregsadetsky wrote:
               | I agree.
               | 
               | Stripe is sometimes more explicit about it:
               | 
               | https://stripe.com/jobs/listing/infrastructure-engineer-
               | ruby...
               | 
               | "Our most popular language in the company today is Ruby,
               | and we are building a new Ruby services practice in
               | support of this."
               | 
               | ... but that job is also an openly Ruby-centric job.
        
               | 59nadir wrote:
               | Our solution to this is that we are clear that we're
               | looking for Haskell programmers (as in that is what they
               | should expect to do) but we have very modest requirements
               | in terms of prior knowledge. I made sure to relay to HR
               | that almost nothing is _required_ in terms of prior
               | knowledge (language-wise) and that we should expect to
               | teach Haskell to people instead.
        
               | 908B64B197 wrote:
               | They are massively profitable too. I'm not implying a
               | correlation here but.....
        
               | 908B64B197 wrote:
               | > Good organizations hire talented and bright people with
               | mastery of CS and SWE fundamentals. Bad organizations
               | think "oh we use Java, better hire Java programmers".
               | Really bad organizations think "oh we use JUnit, Spring
               | Boot and IntelliJ, better hire people with experience in
               | JUnit, Spring Boot and IntelliJ"
               | 
               | You can't just go around telling people that: you are
               | going to make hiring harder once everyone figures it out!
               | 
               | When you get a referral for a 10x and you're meeting at
               | Blue Bottle you need an ice breaker; clueless community-
               | college tier HR asking for versions of frameworks makes
               | for an excellent one!
        
               | arp242 wrote:
               | I've been hired as both a Ruby on Rails and Go developer
               | without prior experience, and managed just fine in both
               | case. Of course there's a bit of ramp-up time, but it's
               | not that bad.
               | 
               | I'm not even an exceptionally talented programmer: just a
               | competent one. Of course there are real differences
               | between languages that matter, but at the end of the day
               | ifs are ifs, ints are ints, functions are functions, etc.
               | 
               | Relevant old joke: https://www.reddit.com/r/ProgrammerHum
               | or/comments/4k994j/if_...
               | 
               | That said: there are some reasonable scenarios when you
               | want to hire someone with prior experience; for example
               | as a first or second hire it's probably a good idea in
               | most cases, or if you really need someone who can hit the
               | ground running.
        
               | tcmart14 wrote:
               | This makes a lot of sense. If a person has good
               | fundamentals and understanding of engineering and CS,
               | then they should be able to master any tech stack. I
               | think in software development, we are in a weird
               | position. In other engineering fields, it is expected to
               | have a base line knowledge and the ability to learn into
               | new processes. Most software companies seem to not want
               | hire engineers who can do that.
        
               | anchpop wrote:
               | I guess this is how I think of it. I enjoy the fruits of
               | modern society, the airplanes and fast food and nice
               | phones. But to make that happen, you need specialization,
               | you need people know get really good at flying planes
               | then just do that, and people who get good at making fast
               | food and iphones and everything else. And inside that,
               | you need people who specialize at every part of the
               | supply chain, and what you end up with is people who have
               | spent basically their whole lives fixing bugs in
               | webservers used to sell analytics software to businesses
               | etc. etc. and it becomes so abstract and you're so
               | disconnected from the feeling that you're actually
               | helping anyone or worth anything to society that it
               | doesn't really matter that intellectually you know the
               | whole system would collapse if you don't have people
               | doing jobs like yours. And you should have friends
               | outside of work, but many of us don't really, at least
               | not to the extent that way like, and even then work is
               | literally most of your waking day most days of the week,
               | and the knowledge that not even your coworkers or
               | superiors or anyone else really cares about _you_ in this
               | grand societal project called modern civilization that
               | you're basically dedicating your life to maintaining, I
               | can see how that would get to someone.
        
               | planet-and-halo wrote:
               | Dear god, that was beautiful but also depressing to read.
               | I think this is it, exactly. I also think that it
               | explains a large part of why so much software is bad.
               | Specialization is a powerful thing, but without a
               | unifying concept of the end goal, it's easy to become
               | trapped by local maxima.
        
               | yarky wrote:
               | > Why is it important to you that your employer view you
               | as a person?
               | 
               | Because we, generally speaking, are people and not robots
               | ;)
               | 
               | That being said, I agree with your point : people would
               | have less issues if they just felt happy about whatever
               | makes logical sense. That's just way too hard to live by
               | for most people.
        
               | phdelightful wrote:
               | The answer to a charitable interpretation of your
               | question: most tech workers don't mind exchanging their
               | labor for money, of course.
               | 
               | The answer to the question as written is...of course
               | people want the entity that has outsize influence on 40
               | hours of their week to view them as a person instead of a
               | mindless cog in a machine. People get treated better than
               | cogs. Workers want their working hours to be as pleasant
               | as possible, which is much more likely if your employer
               | sees you as a person.
               | 
               | Is that really surprising to you?
        
               | MattGaiser wrote:
               | Not a mindless cog, but more as a merchant or even a
               | labour supplying Lambda function. Just simply acknowledge
               | that my employer and I are trading, the arrangement may
               | end at any point for business reasons, and likely will
               | end in a few years as our needs diverge.
               | 
               | Needs can include a nice workplace and you can negotiate
               | specific details about what that means to you. I did not
               | mean to say that it needs to be money.
        
               | playing_colours wrote:
               | There can be vast difference in the work of two engineers
               | with the same "Java - very good" in their CVs.
        
               | OJFord wrote:
               | But not all of us want to trade at that level of
               | granularity. 'Do you have any mechanical engineering
               | jobs' not 'Do you have any ceramic ball bearing housing
               | design jobs'.
        
               | Krisjohn wrote:
               | A screwed hiring system is something most companies
               | appear to be able to afford, given how many have one.
               | When that same experience is flipped around to the
               | employee, they can't afford it and it's a disaster. Few
               | employees want zero job security and an expectation to be
               | wading through the job hire swamp every couple of years.
               | 
               | You're not describing an employee, you're describing a
               | consultant. Not everyone wants to be a consultant,
               | particularly since most people don't get any training in
               | it before they have responsibilities. If proper
               | entrepreneurship was a subject at school, then maybe
               | people would be willing to be their own business, but
               | that's not what the system creates (or wants).
        
               | MattGaiser wrote:
               | > Few employees want zero job security
               | 
               | Fair, I can see why this might bother people. I don't
               | think job security is a thing (career security perhaps),
               | but I can get why its absence would be disturbing.
               | 
               | > expectation to be wading through the job hire swamp
               | every couple of years.
               | 
               | The high level of turnover in this industry indicates
               | that people at least tolerate it. The only people I know
               | who make it 24 months in a role are chained by stock
               | options.
        
               | shiftpgdn wrote:
               | It's not about humanism but mutual investment. I am
               | investing my (very limited) time into your company to
               | make you profit, you can invest in training me or helping
               | me get up to speed on your specific needs.
        
               | MattGaiser wrote:
               | But that is just trade and you can negotiate for those
               | things. The employer benefits from getting you up to
               | speed in the same way that someone might offer to send a
               | truck to a store to get something delivered faster.
        
               | mettamage wrote:
               | IMO, because the different .NET Core versions the
               | commenter talks about aren't that different and one can
               | easily learn another version if they are already well-
               | versed in one if them.
               | 
               | Learnability is totally ignored.
        
               | andi999 wrote:
               | Also I am wondering: if management eventually decides
               | (advised by external consultants of course) to switch to
               | a newer version, then what do they plan to do? Hiring a
               | new team?
        
               | ookdatnog wrote:
               | In short, employers have some degree of power over you,
               | and if you perceive people who wield power over you as
               | wielding that power arbitrarily, that is nearly
               | universally experienced as frustrating.
               | 
               | In GP's case, the arbitrariness originates from their
               | potential employer not taking the effort to really
               | evaluate GP's relevant skills in software engineering,
               | but instead resorting to lazily ticking boxes on a
               | checklist. And what's on the checklist isn't even
               | particularly relevant.
               | 
               | What I imagine this does to GP's view of the world (based
               | on what it would do to mine) is: "I believe I am
               | competent because I've built up a set of subtle skills in
               | software engineering over many years, and this is what I
               | take pride in. But from an employment point of view, this
               | is wasted time: I should instead have focused on
               | optimizing the checklist (and I only found this out after
               | years in the industry)."
        
               | XorNot wrote:
               | Because the buzzwords are never even coherent. "Puppet or
               | Ansible" - well no, those are not even slightly the same
               | thing, _which_ one are you using? GCP or AWS or Azure -
               | same thing. Which one are you using, not what are you
               | imagining?
               | 
               | This would all be fine, but no one writes ads saying what
               | they actually need or what they're trying to do.
        
               | MattGaiser wrote:
               | I want to know what HR people ask Santa for in their
               | letters. It would be so confusing.
        
               | x0 wrote:
               | Minimum four slice toaster with proven experience to
               | deliver results and work autonomously in a fast-paced
               | family kitchen. Ability to cook eggs a plus. Must comply
               | with government product safety laws.
        
               | MattGaiser wrote:
               | I wonder if they realize they asked for a large frying
               | pan in an oven with a timer?
        
               | [deleted]
        
               | ratww wrote:
               | Because a Company expecting a _" walking set of tech
               | keywords"_ is a terrible deal for everyone but
               | charlatans.
               | 
               | It is terrible for inexperienced developers eager to
               | learn on the job as is common in other industries or was
               | in ours in the past.
               | 
               | It's terrible you're an experienced developer that is
               | able to pick technologies quickly, or just wants a proper
               | work-life balance.
               | 
               | It is terrible for developers who are deeply familiar
               | with the technology but expect to work with a team of
               | professionals, rather than with _" walking set of tech
               | keywords"_.
        
               | wwweston wrote:
               | > Why is this objectionable? [to reduce an employee to
               | "utility as a walking set of tech keywords"] > Why is it
               | important to you that your employer view you as a person?
               | 
               | If what you mean is that it can be rewarding
               | (intrinsically and extrinsically) to think about skill,
               | craftsmanship, and other ways to make your labor a great
               | value add, sure. Most of us benefit by thinking about
               | that.
               | 
               | If you're really asking about why keywordification is a
               | problem, well... keywordification of job roles indicates
               | a way in which companies are quite possibly struggling to
               | _actually model the roles_ they 're hiring for and
               | identify what makes make an individual productive within
               | them.
               | 
               | This happens on at least two levels:
               | 
               | 1) Technological. Engineering decisions are _sometimes_
               | "we have a specific problem, specific tech is _the_
               | solution to our problem, therefore we need expertise in
               | specific tech. " In that case, the keywords regarding
               | that tech are meaningful. But for non-trivial use cases,
               | engineering problems are very, very rarely _just_ that,
               | they 're commonly the aggregation of off-the-shelf +
               | consideration of how to mix them with what tradeoffs +
               | in-house custom solutions embedded in an organization
               | attempting to understand and model its domain problems
               | and fit/reshape all those solutions to those models. This
               | is not exactly a keyword-driven process. Keywords
               | represent the shallow end of the pool.
               | 
               | 2) Human. While labor clearly _is_ something bought and
               | sold on the market, even from a point of view of a value
               | system which is OK thinking of humans primarily as
               | industrial inputs, it turns out that 's a significantly
               | leaky abstraction and most of us have all kinds of
               | "compiler flags" or other inputs of our own that make us
               | more or less productive. Some might consider this to be
               | too warm and fuzzy; they might find it comforting that it
               | can be approached from as a-humane and manipulative point
               | of view as one might approach tweaking a database to get
               | it to perform better:
               | https://www.youtube.com/watch?v=HkFztAgK-8U
               | 
               | As for whether it's _OK_ to think of humans primarily as
               | inputs to any process on a moral level... like Terry
               | Pratchett 's character Granny Weatherwax said "Sin, young
               | man, is when you treat people like things. Including
               | yourself. That's what sin is." What are the consequences
               | when social institutions consideration human beings
               | primarily as inputs to institutional purposes? Generally,
               | individual life, liberty, and pursuit of happiness become
               | valued less, and individual suffering is more freely
               | disregarded. Not super desirable under my value system.
               | YMMV.
        
               | fsloth wrote:
               | "I am genuinely asking. Why is this objectionable?"
               | 
               | Software engineering is at a schizophrenic point where it
               | is very hard to categorize in either of traditional "blue
               | collar" vocational job (given people seem to be employed
               | close to very little formal schooling) or as a "white
               | collar" professional job (given some roles need a CS
               | degree level understanding of the fundamentals).
               | 
               | Some roles are more the other than the other.
               | 
               | I'd say listing a very specific tech stack signals the
               | employer is looking for "blue collar" "commoditized"
               | labour.
               | 
               | White collar "professional" types probably feel treating
               | their contribution as "commoditized labour" is a category
               | error.
        
             | garren wrote:
             | Could you elaborate on how accepting it improved your
             | career? Did it change the way you interview or the kinds of
             | jobs you accept?
        
               | LAC-Tech wrote:
               | It made me realise my normal process of:
               | 
               | - going on $JOB_BOARD
               | 
               | - sending out CV & Cover letter
               | 
               | - talking to recruiter
               | 
               | - going to 3 interviews
               | 
               | - rinse and repeat
               | 
               | Wasn't working. I was not in demand. I had to constantly
               | reach out to people, just to get interviews at places I
               | didn't really want to work for. And even then they'd
               | usually reject me.
               | 
               | It was a wake up call that I was on the fast track to
               | nowhere, and something had to change.
               | 
               | Ended up specialising in an industry and doing contract
               | work. I'm not super successful yet, but there's a lot
               | more interest in me. My work days are much less
               | frustrating and I'm earning more.
        
               | vlttnv wrote:
               | Looks like I am on a similar path to you but you are a
               | couple of steps ahead of me. Is there a place I can
               | contact you with a few questions. I'd really appreciate
               | it.
        
               | LAC-Tech wrote:
               | Sure, email in profile, happy to chat.
        
             | moistoreos wrote:
             | I think this is a problem for the greater .NET community in
             | general. I've participated in dozens of interviews where
             | the "technical" interview is them asking obscure .NET or C#
             | related questions like your some kind of technical
             | glossary. What's worse is these questions are likely
             | related to the one or two instances it's ever used in their
             | entire codebase(s).
        
             | jshmrsn wrote:
             | Is it possible the interviewer was asking this question
             | because they wanted to get a sense of if you were aware of
             | which version was being used? And as follow on, were you
             | part of the decision to update or not update, and your
             | thoughts on the trade offs in that kind of scenario? Just a
             | possibility. Certainly if the _recruiter_ is asking you
             | that, that's a bad sign (although recruiters are often very
             | detached from the thinking of the teams they're hiring
             | for).
        
             | smcl wrote:
             | Yeah it could be a lazy way for an interviewer to check a
             | requirements box that says ".NET Core 3.1 experience". But
             | there is a chance that this is a way to determine whether
             | any upcoming questions are relevant - like if you haven't
             | used .NET Core 3.x, it's probably pointless to ask a
             | question relating to some feature introduced in C# 8.0.
             | 
             | It's a contrived example of course (particularly if the end
             | goal was just to check the "knows feature X from C# 8"
             | box!) and I wasn't at those interviews so I've no way to
             | know what their intent was. I'm occasionally on the other
             | side of the interviewing table though so I'm just trying to
             | reason through why this might come up. FWIW I hate the
             | "what _isn 't_ in a linux inode" type questions, or
             | situations designed to fuck with the interviewees.
        
             | machinevision wrote:
             | What did you do differently once you accepted it?
        
           | andix wrote:
           | In reality nobody knows what skills will be needed for the
           | position. Quite often not even the people who do the job. You
           | can let them write down what skills are needed for the job,
           | hire somebody who checks all boxes, and it could still be a
           | catastrophic failure.
        
           | dredmorbius wrote:
           | John Ousterhout: A little bit of slope makes up for a lot of
           | y-intercept.
           | 
           | https://clairehu.com/2014/02/18/a-little-bit-of-slope-
           | makes-...
        
         | wyager wrote:
         | The risk is artificially inflated by how hard it is to fire
         | people.
        
           | jt2190 wrote:
           | This is actually true. A bad hire, once in the door, can be
           | very expensive and time consuming for an employer to rectify.
           | This is what leads to all sorts of weirdness like "contract
           | to hire".
        
         | dan-robertson wrote:
         | I find attitudes towards risk in hiring very strange. Many
         | companies seem to treat it like an opportunity for massive
         | downside without much thought to the potential upside. I think
         | the downside potential is mostly less than companies seem to
         | worry (an argument against me is that a 'bad' employee
         | negatively affects their teammates too). I also think the
         | normal interview processes aren't even very good at filtering
         | out those feared candidates.
         | 
         | Instead I think companies, especially large companies where
         | small numbers of employees aren't a massive proportion of
         | spending, should try to see the potential for upside more.
         | Especially in a world where everyone does a similar
         | interviewing process, a candidate who performs poorly at those
         | interviews could be cheap and an excellent hire who is
         | undervalued by the market because of their poor interviewing
         | skills.
        
         | hiyer wrote:
         | Almost every single tech company I've interviewed at (ranging
         | from medium-sized startups to FAANG), I've given at least 5
         | interviews, going up to 7. The only exceptions were very small
         | startups and a couple of large Chinese organizations, where
         | they stopped at 3.
        
           | worker767424 wrote:
           | Interviews or rounds? Phone screen and 4-5 on-site is pretty
           | reasonable, but that's only two rounds.
        
             | hiyer wrote:
             | I'm not sure where the distinction lies - both seem same to
             | me :-)
        
               | sokoloff wrote:
               | To me, rounds imply a decision point (and delay) in
               | between.
               | 
               | If I talk to HR on Monday, take a phone screen with an
               | engineer on Wednesday, and come on-site (or Zoom now)
               | with 4 engineers next Monday, that's 2 rounds and 5
               | interviews (or 3 and 6 if you count HR)
        
               | [deleted]
        
               | hiyer wrote:
               | > To me, rounds imply a decision point (and delay) in
               | between.
               | 
               | My experience has been that if you clear the engineering
               | phone screen the company asks you to go through all the
               | rest of the (4-6) interviews, even if your performance in
               | one or more of them has been sub-par. And at least here
               | in India the post-screen interviews are spread out over
               | several days to 2-3 weeks - there is no "onsite" as such,
               | even over Zoom.
        
           | hogFeast wrote:
           | I remember interviewing for some grad roles. No hackerrank,
           | no bullshit, very straightforward companies with "easy
           | processes". Both had one "interview day", and five/six
           | interviews total.
           | 
           | I read your comment and I was thinking in my head...wow, five
           | seems like a lot, and then I realised that even these places
           | I liked went pretty hard...I think they call this
           | conditioning.
           | 
           | I didn't get either job btw, the work was trivial but I get
           | terrible interview nerves so tanked both of them...in both
           | cases, I also had a 6-hour take home...the results of which
           | were largely ignored. Neither company is ever fully
           | staffed...ofc.
        
         | hogFeast wrote:
         | I was going to say that there are tons of parallels with how
         | some fund managers approach investment. I have met lots of
         | people who have this trait for over-analysis, not one has ever
         | made consistently profitable investments. Over-analysis is a
         | failure to understand what information is important.
         | 
         | This is going to become more and more common though. In fund
         | management, there has been a huge move towards
         | "professionalisation"...which, ofc, means doing lots of
         | pointless exams that select for the wrong thing. MBAs are the
         | same. It is very hard to solve because the system selects for
         | people who will play into this self-image (in my experience,
         | this isn't solvable...you can either handle the risk of being
         | wrong or you can't).
         | 
         | This also overlaps with a lot of the issues that a lot of
         | companies are having with hiring. A company which frames hiring
         | as a risk rather than opportunity and has these very long,
         | negative process of hiring (be real, the point is to uncover
         | "weakness", not learn more about someone) is going to fail to
         | hire people of different backgrounds. The amazing thing about
         | the "candidate shortage" is that it isn't more severe.
         | Companies are so bad at hiring, it is surprising they end up
         | making any decisions at all.
        
           | Tabular-Iceberg wrote:
           | Does any fund manager make consistently profitable
           | investments? Most don't even seem to make sporadic profitable
           | investments.
        
         | marto1 wrote:
         | Reading this it just seems to me we're in for a really bad time
         | with the new managerial class.
        
         | andrewflnr wrote:
         | I think this is a problem our whole society will have to learn.
         | Reducing risk is probably good, but we have to reach the point
         | where trying to eliminate is universally seen as a pathology.
         | It's already kind of a meme in consumer products ("warning
         | labels these days, right?"), but it crops up in hiring, movie
         | production, etc.
        
         | slickrick216 wrote:
         | Salesforce have ever green roles which they casually do
         | interviews for but never actually act on. The roles can be
         | easily spotted as they'll be posted and reposted on job boards
         | like LinkedIn every 4 days.
        
       | 100-xyz wrote:
       | I have recently been through this.
       | 
       | Google took 3 months. 1 month was from the virtual onsite final
       | interviews to the Hiring Committee decision. It was a miserable
       | month and even my wife hated Google by the end.
       | 
       | Second was for a Director of Engg position at a mid sized
       | company. It took 2 months and finally I had to force them to
       | answer. It was a company with weak leadership and it showed in
       | their inability to make a decision.
        
         | adventurer wrote:
         | It's odd. I'm tending to think going through recruiters is the
         | answer. The recruiter can be the bad guy and actually get a yes
         | or no by putting pressure on otherwise I'm emailing multiple
         | times and lucky to even get a response. If you weren't sure
         | what the next steps were then why are you even hiring?
        
       | wdb wrote:
       | Yeah, two phone interviews, day of interviews, get job offer and
       | then they rescind your job offer.
        
       | nextlevelwizard wrote:
       | I think there should be initial round with HR just to see that
       | you aren't out right lying on your application and/or CV. Then
       | you should have at home coding exam (still time limited to an
       | hour or two) and if your code looks good then there should be the
       | final interview with the team/manager where you are going to
       | work.
       | 
       | EDIT: now that I think about it there probably needs to be one
       | more where you can negotiate the sallary and benefits and
       | actually sign the contract.
        
       | runbathtime wrote:
       | Do diverse candidates have the same amount of interviews as non
       | affirmative action hires?
        
       ___________________________________________________________________
       (page generated 2021-08-02 23:02 UTC)