[floober]

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 never invokes their knowledge of algorithms. There are also folks who spend day in and day out tuning and designing new systems and deep knowledge of algorithms is essential (we also call this "software engineering").

[0xbadcafebee]

I completely agree, we need better compartmentalization/specialization and a better way to target specific skillsets and experiences. Not knowing how to hire the right people is a source of so many problems in the industry.

20 years ago, all you had to do was get a "certification" in some technology and you'd immediately be hired to work on it. That led to a lot of really bad people getting hired because all they did was learn how to pass a test. Today, hiring in tech doesn't require any piece of paper at all. But that means that instead of relying on some standard format to prove your baseline body of knowledge, the interview process now has to do it ad-hoc, and it never seems to fit the role's actual requirements.

And nowhere in the industry have we ever required training on how to actually do a job. Does the candidate know what an SDLC is? Do they write ADRs? Have they juggled multiple changes in flight on a team with large codebases? Do they have a solid grasp of the strange subtle quirks of their tech? Have they learned to be judicious in their decisions and weigh the many long-term pros and cons? Have they ever developed any project with a team?

Trades typically require an industry board to certify them, and then often require years of apprenticeship under journeymen or masters. I think these two would go a long way towards leveling the incredible amounts of variation in candidates and eliminate these ridiculously ill-suited interviews.

[vajrabum]

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 the scale of FAANG, those sorts of problems (e.g. turning n into n*2 and the like) at a backend are very likely going to cause crashes or something essential to time out. If you haven't worked on a service with 5-10K or more servers you aren't likely to really get how quickly and how frequently things are going to go bad if you aren't very careful.

There aren't many if any engineers designing bridges who haven't had the entire curriculum. If you want to practice independently as an engineer then you have to get a license which involves taking a hard test which recaps your entire undergrad curriculum and maybe more. I peeked over my brother's shoulder when he was studying for the EIT. Not easy to pass. And like doctors and lawyers they have to keep up with their professions to renew their licenses. So, no.

[rendall]

> 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 others.

[908B64B197]

> 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.

[908B64B197]

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...