Live data from Hacker News

Follow-up to “The dystopian world of software engineering interviews”

jarednelsen.dev

131–140 of 538 posts

Re: Follow-up to “The dystopian world of software engineering interviews”

#131

I don't know, hiring seems inherently broken. Not just the algorithmic part, even the part leading up to it. You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy. Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected. Every company I've worked for had trouble hiring. I'm working for a company that also has troubl…

Total catch 22. I’ve told recruiters something I’m excited about with my current role before and they’ve said “seems like you really like your team are you even serious about switching jobs”.....

Re: Follow-up to “The dystopian world of software engineering interviews”

#132

I got to the last thread too late for a comment to make a difference, but I'm exactly the person most of you want to talk to or hate. I'm an interviewer at a FAANG company with >500 interviews in the last 5 years, I teach multiple internal courses on interviewing, and I think the system makes a lot of sense for companies at our scale. Ask Me Anything :) I currently have a toddler on my lap, but I'll edit this post la…

I’m a former interviewer for a FAANG competitor that had a successful IPO. I had to do over 1,000 interviews in 5 years. The VP of Eng told me I was “highly accurate.” We used leetcode-like programming questions. I don’t think the FAANG-style coding puzzles have anything new to add to the conversation here. The reason big companies do that is because the questions are prompts are simple to write explain (hence interv…

> FAANG-style coding puzzles

These are not "puzzles". That makes it seem like there is some trick or clever concept the candidate needs to grasp that show "lateral thinking".

There isn't.

These are (or supposed to be) fundamental problems of computer science that require good understanding of algorithms, data structures, code performance, and can be solved in Yes, these exist, and there are plenty of them. A pretty common and well known one is "HEAD to TAIL" - where you have a dictionary of 4 letter words, and given an input of 2 words find a connecting path between them changing one letter at a time. This isn't a puzzle. It's a problem to solve and approach from different angles and allowing for a large number of solutions of different performance characteristics

> Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes - I’ll let this one stand on its own.

Means absolutely nothing. Most of us are not interested in ruining the day of someone who is unhappy with the hiring process by revealing the truth that most likely it just means the person was not good enough. That seems cruel. I'm kind of going further here though because this is the second time this OP is coming up on the front page of hackernews

Re: Follow-up to “The dystopian world of software engineering interviews”

#133
post #87

Earlier quoted context omitted.

Ok, but why is that a bad thing for engineers that are interviewing? If the interview process is largely memorizing 200 or so commonly asked algorithm questions and that is the gateway to a $200k+ job then it's a good thing for applicants, not "dystopian" at all. Again, it would be much, much more painful and time consuming for the interviewee if they were asked to code up some fullstack project for every interview.…

I think you missed the entire point of these articles. The algorithms you're forced to memorize are, 99% of the time, useless. Instead of hiring someone by their track record, managers are choosing to hire those capable of memorizing trivia. Part 2, paying someone on trivia instead of capabilities is not sustainable. The company ends up suffering in the long term. Other engineers that are actually capable have to pic…

I think you missed the point of this interview style. This style of interview is scalable, predictable, efficient and effective. It is useful in that way.

Re: Follow-up to “The dystopian world of software engineering interviews”

#134

Earlier quoted context omitted.

Right, if you pay significantly less than top companies you probably don't want to filter using their metrics since then you will just get their leftovers. Instead you should try to find the good candidates they miss. However there is really no reason for top companies to change their interviews.

> Right, if you pay significantly less than top companies you probably don't want to filter using their metrics since then you will just get their leftovers. Not sure where you read "less pay" into my comment but fine, let's go with that and just ignore that quite a few companies immitate FAANG style hiring these days. > Instead you should try to find the good candidates they miss. However there is really no reason f…

> quite a few companies immitate FAANG style hiring these days.

My point was that they shouldn't unless their offer can compete with FAANG offers.

> When a large number of experienced participants in the fields you are hiring for are offering critique on your process it should be at least reason enough to talk about it

FAANG are spending billions a year to keep this process running, there are huge amounts of work put into trying to change or improve it. And some things do change, but the signals from doing algorithms is just too salient to throw away.

Re: Follow-up to “The dystopian world of software engineering interviews”

#135
post #7

Honestly, I think until FAANG start doing something else, the vast majority of tech/semi-tech companies will just copy them. A few smaller companies might branch out and try some other stuff, but most people hiring at mid and large size companies are just trying to minimize risk more than go grab that great diamond in the rough. If the big guys are doing X, the medium guys are gonna keep doing X also.

I'm actually rather unconvinced that these interviews are positively good at minimizing risk (false positives). This whole 'whiteboarding' thing has degenerated into 100% pointless trivia, with many elements of a popularity contest - I just don't see any reason why we should trust this to yield 'safe' candidates. Even sticking to the pure 'trivia' aspect, there's just so much of it that people are missing altogether.…

> I'm actually rather unconvinced that these interviews are positively good at minimizing risk (false positives).

I was talking about minimizing risk for the people hiring at sub-FAANG companies. If they make crap hires, they can just say "well we're doing it exactly like FAANG". But yes, I also agree there might be better ways to optimize for minimizing bad hires.

Re: Follow-up to “The dystopian world of software engineering interviews”

#136
post #23

The “hopeless list”, no. 3: “If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day, you’re the asshole.” This pretty much sums up my impression of these hiring managers that crank the bar sky-high: they are assholes through-and-through, and are full of shit to boot. If you crank the bar sky-high, all you will get are two kinds of people: those that interview/test well, b…

But while they are getting guidance and mentorship, they are not being a productive member of the team, taking time away from experienced developers and as soon as they level up they will change companies and the next company didn’t have to invest training time. I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.

Sure, you can't invest a ton in mentoring employees if people don't actually want to keep working there. But one of the best ways to ensure programmers stay is to make sure they keep learning.

And one of he best ways to make sure your senior people always have something new and interesting to tackle is having them mentor junior people to take over the things seniors are bored with.

Re: Follow-up to “The dystopian world of software engineering interviews”

#137
post #16

I think that "apparently very few people actually know how to program a computer" part is more about how many people have "fake it till you make it" attitude or how large ego they have. Or how much they dont bother how they look like during interview and keep trying until they get lucky scoring position. And that actually is how many get to start programming. As in, one of common advice is to be self-learner and abse…

I often look like I have no idea what I'm doing with computers when someone is watching. I also find it almost impossible to practice an instrument with someone watching. Performing is another matter. To do well at interview coding I'd having to drill relevant questions to the point that I was performing rather than practicing in the interview, and I'd probably still be freaked out and unable to do it unless I knew the questions I'd face in advance.

Luckily actually working in software development is a hell of a lot more like practicing than performing, and there's usually no-one watching you, so I'm fine at that part.

Re: Follow-up to “The dystopian world of software engineering interviews”

#138
post #90
post #16

I think that "apparently very few people actually know how to program a computer" part is more about how many people have "fake it till you make it" attitude or how large ego they have. Or how much they dont bother how they look like during interview and keep trying until they get lucky scoring position. And that actually is how many get to start programming. As in, one of common advice is to be self-learner and abse…

It doesn't seem to be all fakers. The situation as described by advocates of FizzBuzz and the like, is that large minority proportions of people who have already held down jobs in the software development field, actually can barely do things that we think of as basic programming, like implement a very straightforward function. The implication seems to be that there's just too many to all be actual liars; that they're…

>> it would be interesting to know if that actually was enough

If the 'people fail fizzbuzz' trope is actually true then you would probably clear that first bar easily and probably the next few as well.

Personally, I think most if not all software devs have some form of tunnel vision (aka limited experience). While they feel the bar they are setting is low, the manner in which they describe the bar may be completely unfathomable to a person not familiar with the same terminology.

Since all technology is just new terminology for old ideas then it's easy to fake competence if you know the new terminology or look like an idiot if you aren't a slave to fashion.

Re: Follow-up to “The dystopian world of software engineering interviews”

#139

Earlier quoted context omitted.

In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code. Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t see…

How would a junior no what to refactor and not make it worse? In my experience it’s harder to refactor existing code than to start with green field development.

A good way is for them to pair with senior people until they have grasped the direction and motivations of the refactoring work.

Re: Follow-up to “The dystopian world of software engineering interviews”

#140
post #49
post #14

When I interviewed at Google for a front end position they didn't ask me a single CSS question. It was all algorithms and easy JavaScript questions. It was just really weird, like at least ask me how to center something. They bothered to ask me how I'd deal with diversity issues if I was in HR, though. I probably didn't get the job because of my answers there...

Ironic, because I work at Google and just found a bug caused by using percent-based border-radius CSS rules on a non-square element - something anyone with even intermediate CSS experience wouldn't write.

Oh, why would you want a percent based border radius?
Post reply on HN