Live data from Hacker News

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

jarednelsen.dev

311–320 of 538 posts

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

#311

Earlier quoted context omitted.

Then perhaps it's not just interviewing that's broken, but the industry as a whole. At least, software engineering education and training.

Everything is broken. To crib from George Carlin, think about how incredibly stupid the average person is, and then realize that people run _everything_. Almost every industry/system/institution/company of a non-trivial size is staffed primarily by deeply stupid people. Practically the whole challenge of an economy is figuring out how to organize these people towards productive ends. "Dumb people work in software eng…

But that’s defeatism, and doesn’t get into how software engineers aren’t getting adequately trained compared to every other type of engineer.

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

#312

Earlier quoted context omitted.

When you are early in your career, it’s quite easy that within two or three years your market rate can easily go up 20-30%, but your HR policies don’t allow more than a 5% raise. Why wouldn’t a developer leave for more money and more learning opportunities?

1. Not saying they should or shouldn’t and as I noted if you can’t match salary and all other things are equal you may as well take the raise. 2. If that’s HR policy and you request for an exception and it’s denied, that may be a sign to start asking more questions. 3. You’re assuming that’s HR policy. Again, example dictates you have one option without actually thinking through how an organization could position the…

You’re probably speaking as someone who is not early in their career. But we are talking about junior developers.

I’m nowhere near west coast salaries but just big city America salary for context. At my age now in my mid 40s, married, making about the average salary of a top IC in my market, with the big house in the burbs (again not bragging, any developer with 5-10 years of experience could easily afford it), with the white picket fence and 2.1 kids, yeah 20K more wouldn’t make a difference in my lifestyle.

But, when I was just starting out in 1996 making $33K a year, $20K meant a lot.

But salary compression and inversion are real phenomena where HR policies don’t allow for raises to keep up with the market.

I was working during both 1999-2001 and 2008-2011. In 2000, it was very much just a dot com thing. If you worked in corporate America as a standard Enterprise Developer you weren’t really affected.

2008 was rough, but still there was no such thing as job stability. Companies were laying off left and right. I survived three rounds of layoffs - barely. But even then you could find contract gigs if you were the perfect fit.

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

#313
post #217

Earlier quoted context omitted.

You can test skills relevant to the job. If you're mostly doing js /css do that, not algorithms questions.

The idea that JS developers don't do anything that needs algorithm knowledge is funny to me.

Frontend isn't going to require you to use union find and when it does you can look it up.

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

#314

Earlier quoted context omitted.

Another perspective to consider as well: while you are spending the time investing into and training people who needs the training and investment, your competitors are throwing money luring away the ones you have already trained, and leaving you in the dust in terms of velocity. Turtles all the way down. Once a game shifts into zero-sum, it's not gonna stop getting played until it collapses. Normally, I would say to…

Not every business needs to be aiming for hyper-growth. Perhaps some tech startups can take a breather and reconsider whether they need to be engaged in the same zero-sum game as everyone else. Because grow at all costs doesn’t just harm untrained juniors- it also leads to corner cutting and short-term thinking that could bite the business in the back later on.

By definition if you are a VC backend startup, you are expected to concentrate on “hyper growth”.

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

#315
post #66

What is tragic here is the amount of effort that is now expended by young computer scientists into the game of algorithms. Whereas a young programmer in the past may have spent their extra days writing games in Basic or static web pages, hackers these days seem to do Leetcode until the wheels come off. We are failing to bring certain softwares into existence by effectively requiring programmers to their effort into t…

> What is tragic here is the amount of effort that is now expended by young computer scientists into the game of algorithms. This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and Cracking The Coding Interview , it was common for developers to complain that software developers were losing touch with algorithmic knowledge. HN-type websites were full of discussions about clueless software engineers…

A decade ago everyone was absolutely doing data structures and algorithms in interviews, and had been doing so for long enough that Cracking the Coding Interview had already been out for two years (along with Steve Yegge's post on prepping for interviews: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...). I'm not sure what time period you meant to reference?

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

#316
post #279

I will never forget the time I was given a coding "challenge" and sent home with the instruction to send it back whenever I felt it was complete. This sent my OCD into overdrive, of course. For the better part of two days straight I coded my heart out and came up with this (what I thought perfect) robust system with all the bells and whistles. Heard nothing back. At all. My calls into the recruiter went unreturned an…

Some companies also use the interview as free consulting. Remember that you are a professional. Don't work for free.

How do you detect when they are trying this?

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

#317
post #161

Earlier quoted context omitted.

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.

”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?” Well, first...you were replying directly to a post that was talking about whitebord/algorithm questions and how they’re out of control. On an article about same. So my answer is: ”because I bothered to read the post to w…

I’ve changed jobs frequently and haven’t had a unicorn career. You’d be amazed that the interview process for your bog standard enterprise developer/architect roles or your standard software as a service CRUD developers don’t have algorithm style interviews. It’s mostly soft skill and explaining your previous projects.

Not everyone’s career has been the r/cscareerquestions “learn leetCode and work for a FAANG”.

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

#318
post #187

Earlier quoted context omitted.

I worked at a company where the interview process was basically "ask them about their experience, successes, and failures, and do whatever technical screen you feel works." Other than asking about failures (not everyone does) it was just "eh, wing it, tell us what you think." The hiring manager had to then weigh the responses and convince his/her manager if it was a go (we once rejected someone on ethical grounds aft…

> I worked at a company where the interview process was basically "ask them about their experience, successes, and failures, and do whatever technical screen you feel works." I'm part of another online community that has a strong emphasize on social justice issues. These "just wing it" hiring practices are one of their biggest complaints about tech companies. There's a perception that the less well-defined and struct…

> There is a strong push for standardized and repeatable interviewing processes, complete with sufficient documentation to support hiring decisions.

Standardized processes don't mean unbiased processes. The SAT for example is pretty racist.

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

#319

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…

I suspect companies have trouble hiring because they really don't want or actually need to hire. I mean, yeah, hiring managers can complain that they really, really need to hire someone for some open position, but I don't believe them if they've had a req open for years as you suggest (or even six months). If they really had a pressing business need to hire someone then they'd try to make it work. They wouldn't reject someone because they didn't happen to have 1 out of a dozen technologies/buzzwords that were asked for in the job description. They'd realize that an experienced engineer who knows several programming languages can pick up a language in a few weeks and the surrounding libraries and ecosystem in a couple of months. But no, they seek perfection. And in seeking the perfect they end up passing on a lot of perfectly good candidates who could have been getting up to speed and working on their problem in the time it's taken to try to find that perfect candidate.

Companies that really want to hire are flexible. Maybe they need someone to do Python but they've found a good candidate who has all of the other requirements except for Python - but they happen to be really experienced with Ruby. Well, OK, if they're really experienced with Ruby they'll be able to pick up Python in a month or so. Sure, they may not produce the most pythonic code for the first six months, but that's what code reviews are for.

I've been in this game since the 80s. Back then companies weren't nearly so picky it seems (at least not in my memory). The second job interview I had out of college in 1986 at a startup in the valley went like this (it was an embedded/hardware job):

Interviewer: We just got this new CAD system. I'm going to have you sit down and play with it for several minutes. When I come back I'd be really interested in hearing your opinion of it. What are the good and bad parts?

And so I play with the CAD system for a while and when he comes back I give him my opinion. And he agrees with my assessment.

Interviewer: I've got this schematic here and a breadboard, some parts, power supply and test equipment. Do you think you could hook the circuit up while I attend to some other business? I'll come back occasionally to see how you're doing.

I wire up the circuit, get it going, look at the output on a logic analyzer. Interviewer comes back and seems happy. After this he asks when I can start.

This took all of maybe 2.5 hours. In the 34 years since then I've only had a couple of other interviews that seemed that... I dunno how to put it, maybe "natural"? And both of those were in startups. They wanted to hire someone. They needed to hire someone.

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

#320
Potential alternative to white boarding algorithms: have the candidate do a code review.

I think that would show the candidate’s communication style and attention to detail, in addition to their technical knowledge, and probably give a better sense of seniority too. Most code reviews are done in well under an hour anyway, vs actual dev work on a ticket that takes hours or days, so you’re doing more realistic swe work.

Post reply on HN