Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The rise of never-ending job interviews

bbc.com

Post reply on HN
Print view View original

591–600 of 1001 posts

Re: The rise of never-ending job interviews

#591

Post by ashtonkem »

jcims wrote: post #576
ashtonkem wrote: post #65

Earlier quoted context omitted.

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.

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.

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”.

Re: The rise of never-ending job interviews

#592

Post by simonbarker87 »

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.

Re: The rise of never-ending job interviews

#593

Post by buro9 »

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.

Re: The rise of never-ending job interviews

#594

Post by GistNoesis »

cedilla wrote: post #534
GistNoesis wrote: post #284

Earlier quoted context omitted.

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.

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.

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.

Re: The rise of never-ending job interviews

#595

Post by pcthrowaway »

andix wrote: post #393
Ntrails wrote: post #377

Earlier quoted context omitted.

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)

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.

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?

Re: The rise of never-ending job interviews

#596

Post by zealsham »

AJRF wrote: post #469
XorNot wrote: post #264

Earlier quoted context omitted.

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).

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.

I've always said that FAANG don't hire professional software engineers, they only hire professional leet coders

Re: The rise of never-ending job interviews

#597

Post by cainxinth »

lordnacho wrote: post #569
XorNot wrote: post #264

Earlier quoted context omitted.

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).

> 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 l…

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.

Re: The rise of never-ending job interviews

#598

Post by sltkr »

ladberg wrote: post #226
silisili wrote: post #119

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…

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 remembe…

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?

Re: The rise of never-ending job interviews

#599

Post by papito »

bb88 wrote: post #262
ladberg wrote: post #226

Earlier quoted context omitted.

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 remembe…

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.

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.

Re: The rise of never-ending job interviews

#600

Post by zealsham »

rwmj wrote: post #433
ladberg wrote: post #329

Earlier quoted context omitted.

Design mistakes maybe, but syntax errors are just not representative of any real debugging experience IMO.

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.

How did people like this even make it to the interview rounds
Post reply on HN