Hacker News new | ask | show | jobs
by marginalia_nu 1318 days ago
You're "expected" to study for job interview questions. It's more a measure of willingness to jump through hoops than your competence. Developer interview questions in general has little to do with what you'll do as a developer, and what you're expected to know as a developer.
2 comments

This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping? It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

When I was a Junior dev one of the first lessons my boss taught me was to always always speak up if something looked off to me. Maybe I’d get an explanation and be enlightened or maybe I’d actually sniffed out a mistake or code smell. It always seemed like a win win.

But if the entire job is based on “here swallow this bullshit pill before you’re let in the door”, isn’t it going to be hard to get the devs who are allergic to bullshit?

> isn’t it going to be hard to get the devs who are allergic to bullshit

Maybe that’s what they want, namely a self selection of devs who will be happy and okay inside an org that is filled with bullshit.

> This is so weird. Aren’t you just selecting for obedience and unnecessary hoop jumping?

Mostly it selects for people who can turn this on when needed, which honestly is a critical skill. Sometimes life is just bullshit, either you're a person who makes that easier for everyone or you're a person who makes that harder for everyone. But an inability to get past it is a red flag.

Example: I work in medical devices, a regulated space. My job is 50% normal software engineering, and 50% dealing with BS regulations. It's part of the job. You can get annoyed at it, but it won't go away, and the job can be very fulfilling if you can get past the BS part.
How many devices do you see or design have implicit state in the software controlling them?

(if it is not explcitly defined, and there is state based behaviour, it is by definition then implicit)

At the moment I'm trying to overcome the inertia on this issue in the general process/industry sector with child standards from IEC 61508 - 61511 and 62061.

I am guesssing you apply the medical standards IEC 60601?

Or at design of devices at component level then IEC 61508?

Interested to know how it fits in to the overall Functional Safety approach.

I work on software as a medical device, so I have no idea about hardware safety controls. I have to deal with change control boards and approval matrices for every new build we push, though.
> It seems like this would also select the kind of engineers who aren’t willing to say “no, that’s a dumb approach, we shouldn’t do that, here’s an alternative”?

This is exactly the reason why any big enough company is eventually going to s*hit

And why founding team doesn’t stay long in a successful startup.

> And why founding team doesn’t stay long in a successful startup.

Doesn't the founding team get to determine the hiring practices?

It's not that they have much choice once company grow in complexity beyond something that a small group of people can possibly handle.
There's only 24 hours in a day.
Well sure, but one would expect the founding team to do the early interviews, and then setup the process that's followed by later hires, no? Also, I would have thought that hiring would pretty much top priority. The employees make or break a company.
Business processes and traditions are not a source code. It always changes and evolves with people and millions other factors.

One of the factors — it’s too risky for a big company not to hire based on obedience.

Tech interviews are optimised for big tech. Those devs won't care so much when you slap 3x total compensation on their ass.
> Aren’t you just selecting for obedience and unnecessary hoop jumping?

Let's be real, that's exactly what most mid+ companies are looking for.

> obedience and unnecessary hoop jumping

This is what makes you successful in some large organizations, unfortunately.

> It's more a measure of willingness to jump through hoops than your competence.

I'd say it's more a measure of how well you can learn an arbitrary skill. They could change it to solving Sudoku puzzles, grading SAT essays, or wood carving and most of the same people who do well in leetcode interviews would pick up those skills and ace the interviews.

But you don't need arbitrary skills, you need solid development skills to do the job. So they're always going to miss out on people who aren't good at learning arbitrary skills but already have solid development skills. But many big companies seem alright with that tradeoff.

You're also biasing towards the type of person who is ok with either burning themselves out or skiving off work (or both) to get good at these types of interviews.
> I'd say it's more a measure of how well you can learn an arbitrary skill.

Time is finite. You can learn to write better programs, or grind Leetcode. Leetcode interviews favor the one who can put enough time on the latter.

A better explaination is it's a chain reaction. People who know only to Leetcode enter the industry, and ask only Leetcode questions.