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

Green Lumber Fallacy in Software Engineering

chrisbehan.ca

Post reply on HN
Print view View original

101–110 of 238 posts

Re: Green Lumber Fallacy in Software Engineering

#101

Post by gigel82 »

mrkentutbabi wrote: post #42

If I have money for every article that rail against DS&A algorithm.... I don't understand why people hate DS&A so much. Just do it. Get money, jump ship, get more money, it also makes you a better engineer. It gives you better compensation, it helps you, helps everyone, helps your team, your company. It helps avoid wasting time as well on both sides. There is no downside of studying DS&A and Leetcode, if there is, th…

> The point of DS&A interview is as fast as possible system to vet engineers that aren't time wasting on both sides

I have to disagree. Doing LeetCode problems is a huge waste of time for me; I'm not interested in a career as a "professional interviewee". Yes, I'm totally leaving money on the table because of it but I refuse to participate in their 5 monkey experiment.

Re: Green Lumber Fallacy in Software Engineering

#102

Post by [deleted] »

jcrites wrote: post #91
paxys wrote: post #60

Data structures and algorithms questions are a perfect proxy for (1) is the candidate smart and (2) can the candidate write moderately complex code (arrays, hash maps, pointers, nested loops). 90% of candidates will fail 2, and you will get a good idea of the rest with 1. Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have.

Why not ask the candidate to solve a problem of the type that they are likely to encounter while actually working at your company: the kind of task that you would ask them to perform on day one. Inverting a binary tree is not the kind of task that is a software engineer is likely to have to perform at most companies. I think companies can come up with better questions that still involve algorithms and data structures…

[deleted]

Re: Green Lumber Fallacy in Software Engineering

#103

Post by jcrites »

lhorie wrote: post #89
erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

Yeah, that is one of those claims that sound nice in theory but kinda come crashing down when rubber meets the road. Companies do in fact engage in a process of getting someone in and doing an actual job, they're called internships. The problem is that these arrangements typically involve someone dedicating some non-trivial amount of their time to "babysitting" (not necessarily in the literal sense, but in the sense…

> Literally setting up a paid one week period for a senior level candidate would cost, optimistically, a few hundred dollars for evaluating a single candidate.

It’s unworkable for anyone who is already employed. What am I going to do: use a week of vacation for this “interview”? (The fact that I’d be paid is immaterial: I lose vacation time. Plus, the more senior you are, the more of your compensation is in equity. Will I get a week’s worth of an FTE’s both salary and equity just for doing the interview? And at what job level? The highest for which I’m being considered?

This wouldn’t be viable for private companies because it would bloat the cap table with a massive number of insubstantial stockholders; and I believe that companies run into SEC compliance issues when they have more than a certain number (1000?) of stockholders.

Additionally, when I’m looking for a new position, I don’t just interview with one company. I typically aim to get between five and six offers (on a ~5 year cadence) to get an understanding of the spectrum of market rates for engineers, and to see what options are available. There’s no way I could spend weeks interviewing.

Maybe I would consider this if it was my “dream job”; but I’m not sure that the signal from such a trial would be better than typical interview.

Many companies have substantial technology stacks of proprietary infrastructure that you need to learn and become proficient with in order to be effective at your job. At recent employers, engineers have felt it takes 1-2 years to feel fully up to speed and effective using the company’s tech stack. With this kind of ramp up time, a one-week trial would only be useful with a make-work fake project.

My current employer spends six weeks full time just training all engineers who join the company - before they even begin to have actual responsibilities for doing work on their team.

Re: Green Lumber Fallacy in Software Engineering

#104

Post by lhorie »

caethan wrote: post #49

I've heard bitching about some of the interview questions our team asks before, but here's the thing: each of those questions is about a problem our team actually had to solve before, reformulated into an interview-style question. Yes, we've had to use Hamming distances, worry about the scaling (N log N vs N^2) of particular solutions, use error-correcting codes, interesting data structures and all of that. Is that m…

One needs to be especially careful with adapting experience to interview questions. Unlike the candidate, you probably were already immersed in the problem domain for months or years and have good context in what techniques exist and are relevant to the problem domain.

One mistake some interviewers make is implicitly assuming that candidates can somehow conjure the same level of context from first principles, or that a specific algorithm might be familiar or reusable outside of its original context. Another mistake is "looks-like-me" bias.

For example, I happen to have a lot of context on a very specific algorithm that underlies basically every modern web framework but if I wanted to evaluate a candidate on web performance, I'd look at performance optimization as a open ended problem domain rather than drilling them on the particulars of this specific algorithm. In fact, out in the world of web framework performance, the most novel advancements come not from revisiting the algorithms but from looking at the problem domain from entirely new angles that had not even been considered before.

Re: Green Lumber Fallacy in Software Engineering

#105

Post by grogers »

I recently went through two interview loops at big tech companies and the DSA questions are not very hard. The typical question starts super easy and then layers on more complexity as time and skill allows. If you are nervous about interviewing because of that, just try a few "easy" leetcode questions or the first ~5 days of advent of code, it really is about that level. Don't be intimidated, you do NOT have to be perfect to get an offer. If you know what a priority queue/heap is you will be fine. Yes practice, but don't slack on preparing for the 1-2 system design interviews and 1-2 behavioral interviews (for senior candidates). System design especially I personally think is way harder because it's (typically) candidate driven and there's no fixed finish line, just tradeoffs and more tradeoffs.

Re: Green Lumber Fallacy in Software Engineering

#106

Post by aeronaute »

paxys wrote: post #85
tharne wrote: post #69

Earlier quoted context omitted.

> Unless your company can afford a month-long interview process for every candidate which the author suggests, this is the best we have. If the current leetcode style of interviewing is the best that SV can come up with, despite having some of the best engineers and thinkers in the world and billions of dollars to spend, that's really sad.

Silicon valley seems to be doing just fine with this system in place. If there is a better process, let's formalize and test it. Here's a hint - large companies have spent millions/billions of dollars over the years doing just that, and this is what the results show.

I bet they have spent a lot of money on it. How about those folks at Google that, when they were unknowingly reviewing their own packets from when they originally interviewed, decided that they wouldn't even hire themselves?

Google also found that interview performance isn't a good predictor of on-the-job performance.

Sorry, but it's hard to take this style of interview seriously after hearing about these things.

Re: Green Lumber Fallacy in Software Engineering

#107

Post by 908B64B197 »

floober wrote: post #8

In the physical world there are folks who design bridges, dams, buildings, telescopes, furniture, and a million other things. All of those have unique requirements and skill sets. In software, we also make a huge number of categorically different systems each with its own skill set, but we call all of it 'software engineering.' There are folks who are great at their job (called "software engineering") and their work…

Another problem nobody wants to publicly acknowledge is that unlike in law, medicine or even classical engineering, everyone can call himself a Software Engineer!

So you end up with 6 month coding bootcamp "graduates" claiming to be "engineers" alongside folks who graduated from long and hard engineering programs (MIT MEng comes to mind) and who had to complete things like this [0] as assignments.

I recall someone from a bootcamp writing a cascade of nested if-else statement, 6 level deep in some places. Then someone with a real CS background told him that he was basically building a finite state machine, to which the other dev responded that “he didn’t need fancy thing, just for the function to work”.

That's the main reason companies use algorithmic questions when filtering out candidates (because it checks for an understanding of the fundamentals, something bootcamp grads will lack and that will take years to acquire) and why every job interview has questions like these (there's no certification process, anyone can claim the title, so the company must do the vetting every time).

[0] https://www.cs.cmu.edu/afs/cs/academic/class/15213-f10/www/l...

Re: Green Lumber Fallacy in Software Engineering

#108

Post by 908B64B197 »

rendall wrote: post #40
vajrabum wrote: post #34

Earlier quoted context omitted.

I've spent a lot of time fixing or working around messes caused by people who don't know algorithms and data structures. If you don't know about those problems then you're likely to solve one without recognizing it and do a poor job of it. Worse if you don't have data structures and algorithms training you're unlikey to be able to reason about time and space complexity. Unlike at startup or enterprise dev shops, at t…

> I've spent a lot of time fixing or working around messes caused by people who don't know algorithms and data structures. Rare these days, that kind of mess unless the entire department is off kilter. Contemporary practice is to team up, and be in constant communication about the code base, requirements, approaches. Someone in the team or adjacent will know the proper approach and be able to communicate it to the ot…

> Contemporary practice is to team up, and be in constant communication about the code base, requirements, approaches. Someone in the team or adjacent will know the proper approach and be able to communicate it to the others.

Or you hire a 10x like John Carmack and he codes the thing. No need to constantly have meeting and waste everyone's bandwidth.

That, of course, assumes the department understand what a 10x is and how to attract them.

Re: Green Lumber Fallacy in Software Engineering

#109

Post by 908B64B197 »

compiler-guy wrote: post #7

The test isn't so much about the ability to invert a binary tree (for example), but the ability to problem solve complicated problems where the obvious solution is probably not the best one. In interviewing, it is hard to produce real world problems that don't require a huge amount of context and details of some obscure software stack, so we go with abstract problems which are kind of irrelevant to real work, but the…

> which are kind of irrelevant to real work, but the problem solving approaches you need to take are very relevant

It's also a common vocabulary shared across engineers, no matter their seniority or where they graduated from. And knowledge of algo and data structures demonstrate someone could learn it in the first place.

Especially for junior hires, it's an excellent predictor of success.

Re: Green Lumber Fallacy in Software Engineering

#110

Post by HomeDeLaPot »

snarf21 wrote: post #100
erehweb wrote: post #55

Article says "There’s no better way to see how someone performs at the job than having them actually do the job." and argues for a trial work period. Well sure, except the first part of any job is coming up to speed on the domain, the codebase, who the key people are, etc. So if you want to see how someone really performs, you're going to have to wait a while past that initial period. And that means you're going to h…

If that is what they really want, then do a 1099 paying task that takes 40 hours over a months time with a weekly check-in meeting to ask questions not solvable via email. I don't love that idea but it is respectful of everyone's time at least.

But then you're not actually working there. That's just an incredibly arduous and expensive take-home.
Post reply on HN