Live data from Hacker News

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

jarednelsen.dev

201–210 of 538 posts

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

#201
post #117

Earlier quoted context omitted.

> 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... Strange postscript that suggests you hold some problematic opinions that indicate you can't play nicely with others? Did you fail to get the job because you didn't have the tech chops or is it because you said something wildly inappropriate on the behavioural questions? Wha…

Sour grapes, more like. If simply asking how they'd work with people from diverse backgrounds was triggering enough for this person, the process worked perfectly in rejecting them.

That wasn't the question... It was, if I was an HR director, what would I do in different situations.

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

#202
post #57

Earlier quoted context omitted.

” I know everyone has to start somewhere but from the company’s perspective, hiring a junior developer doesn’t make sense.” When did “not able to solve leetcode-nuclear puzzles while singing and tapdancing backwards” , become “junior developer” ? The OP is talking about “sky-high” levels of (interview) competency, and you immediately jumped to the conclusion that anything less must be juniors who need training to wip…

Seeing that in over 20 years and very successful track record of getting jobs quickly that I’ve never done leetCode or had an algorithm interview - how did you get that out of anything that I said? I’ve met “junior developers” who couldn’t translate simple business requirements into code. The stereotypical “developer” who couldn’t do FizzBuzz.

I don't think that's a phenomenon exclusive to 'junior developers'

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

#203

Earlier quoted context omitted.

How do you design your coding challenges? Can you give examples?

Sure. We start by noting in our job description that there will be a coding challenge -- on a laptop, not a whiteboard. Most of our work is on web applications, primarily Rails. So, for that role, the challenge is to fix an issue in an implementation of Fizzbuzz on our sandbox Rails app. We give the candidate about an hour to work on it. It's not as trivial as the common Fizzbuzz exercise but it's a pretty representa…

I like the milestones/check-in idea - will have to use that next time around.

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

#204
post #108
post #92

Earlier quoted context omitted.

The thing is we want to be surrounded by people who see development as a calling, and not just a safe career. That cycle has been going on for years. Now, there are so many companies that are essentially writing variants on the same software over and over again that demand is dictating the shape of the field. The shape of the industry. “We” are all industrial designers in a world that just isn’t that enthused. If we…

I think that the idea that people who see development as safe career are the most incapable is just wrong. Someone stable that does what needs to be done even when it is not fun sounds good to me. Large parts of projects are not fun nor challenging - they are work that needs to be done with good quality. People who see their jobs as safe careers are routinely good at those jobs. And conversely, I have met people who…

I don't think we are necessarily in disagreement. What we want and what we need are often at odds, perhaps nowhere more clearly than in the way we select new team members.

I speculated on why our interviews are so insane, and just kept pulling that thread. What I omitted from GP was this thought: I don't know if we are right to want this, or if the world could have ever let us have it anyway.

There are other measures of 'contributor' that we weed out with our interview processes. Some of those are qualities that working programmers are more likely to have.

For instance, work-a-day developers tend to be less susceptible to hubris. Sometimes when you have a problem to solve, you want the no-bullshit person to do it. It's way easier for me to talk someone out of Imposter Syndrome or at least convince their boss to ignore it than it is for me to dial in the degree of Kruger-Dunning my faster-talking coworkers are covering up.

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

#205
post #191

Earlier quoted context omitted.

bad metrics ? maybe according to you but I doubt it according to the person who do the hiring. The people who do the hiring get to the decide what the metrics is and what they considered good/qualified.

Not according to me, according to many in this thread, in dozens of articles posted on this site, and many more across the industry. There are all sorts of management principles and truisms people take for granted, and this is one of them that’s being called into question.

>Not according to me, according to many in this thread, in dozens of articles posted on this site, and many more across the industry.

Yes, that what said, but I doubt according to the people who do the hiring.

It doesn't matter if you think you are right candidate according to you or other people. Ultimately its the people who going to hire you who is going to judge you according to his/her subjective criteria.

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

#206

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…

How old was the interviewer? This seems like a very immature question. I work for money, first and foremost.

Is the amount of youth in tech part of the problem?

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

#207

Earlier quoted context omitted.

The problem is twofold: 1. False positives: you get folks who do really well at DS&A yet who are really bad developers. I mean really bad. I wouldn't have believed it if I had not seen their interviews and then subsequent performance. I'd wildly guess that it's about 20-30%. 2. False negatives: you get folks who are really good developers, and yet for whatever reason, perform badly on DS&A algorithms despite practici…

Is it really true though? FAANG seem to be doing just fine and innovating new products year after year. Obviously the developers are performing amazingly.

"If you're a FAANG company, you can afford to play these odds"

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

#208
post #175

There is no other sane and effective way to filter the insane amount of FAANG applicants, only DS&A. Other non FAANG/Unicorns that don’t pay as well as FAANG can drop the practice of asking DS&A questions. But for those companies that pay really really well, there will be insane amount of people that are willing to get a job there, and DS&A is a “May the strongest win” filter (although luck play a very strong role as…

> There is no other sane and effective way to filter the insane amount of FAANG applicants, only DS&A. Then why do they also apply this to candidates they reach out to? I've never applied to FAANG, only interviewed after (in-house) recruiters or internal referrals. It always seems to be the same bullshit.

Because of their recruiters. It is arguably better to hire through referrals as well.

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

#209

Earlier quoted context omitted.

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.

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…

Well-tested code doesn't necessarily lead to code quality. Leaky abstractions will eventually show their hand, in an environment that's not as sanitized as a unit test.

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

#210

There is no other sane and effective way to filter the insane amount of FAANG applicants, only DS&A. Other non FAANG/Unicorns that don’t pay as well as FAANG can drop the practice of asking DS&A questions. But for those companies that pay really really well, there will be insane amount of people that are willing to get a job there, and DS&A is a “May the strongest win” filter (although luck play a very strong role as…

This, yes exactly this is the reason I am preparing. I hate it but whats the alternative?

No alternative, or AFAIK, no better alternative (yes I've experienced other style of interview like take home test, project, trial work, etc, all bullcrap). Keep doing it. I'm at my 300th Leetcode questions now, I just need 700 more (half joking).

Jokes aside, my point is, you can only get better, and when you get better, a non FAANG interview is actually a piece of cake, and you can just job hop every year until you maxed out your salary band, rinse and repeat.

Repeat after me: It can only get better, and one day you will actually conquer FAANG.

Post reply on HN