> Then we need a better test, but the gamification and badgering isn’t effective imo.
The educational field has been trying to do create tests that cannot be gamed for over a century. The problem is that "gamification" is just a form a studying. In general, folks want tests to have the following properties.
1. Consistency of measurement across test-takers for a defined set of skills
2. Relatively short time-bounds (few hours).
In job hiring, the approach that tries to sacrifice (2) is contract-to-hire, just let the person do the work for a month! Turns out that people with in-demand skills aren't super interested in this.
Companies with more than a handful of engineers don't want to sacrifice (1) both out of fear of lowering the hiring bar too and because it may open them to discrimination lawsuits.
Once you have both of these constraints the number of "test permutations" (along with their relevant evaluative criteria) become limited enough that people can study them and thus gamification begins.
> Now that I'm in the system, the other stark reality is that little of this system design matters. Most of the challenge is understanding the internal technologies and figuring out who to talk to to get stuff done (like pretty much every big company).
Having been on the "support" side of an engineering org (supporting teams building product features) the thing I've noticed is that if you don't maintain a certain "density" of people with these system design skills things start to go off the rails. People start showing up with designs resting on some very fundamental misunderstandings or designed with no eye towards simplicity and things turn dysfunctional quickly.
It's worth noting that there are also better and worse designed system design interviews. Good ones give space to demonstrate "taste" as well as technical chops.
Or just interview some place that doesn't give this kind of interview, like most companies. It's pretty trivial to get hired even if you can't talk about technical specifics along the lines of an architecture diagram.
Across all examples I can think of - some yes, some no.
It's not material to my point either way. I was only arguing that for some company's being very afraid of bad hires may be sensible and dismissing their concerns as hysteria does not seem obviously correct to me.
> but I feel this is a hyperbolized fear based off a laypersons interpretation of US hiring law
Making definitive statements about liability is not trivial. I can confirm that at some very large companies legal has banned this style of interview citing discrimination concerns. I'm not a lawyer, so I can't comment on whether they're call is more or less correct but it certainly doesn't seem settled.
It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal.
A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup.
This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
Not every day, but my experience is at least every month-quarter. And since you're not primed like in an interview context these ideas need to be inside your wheelhouse to spot them within a business context. I would not describe myself as particularly technical for my org and in the past year I've made use of the following at work:
-Depth first search
-Binary Search
-Topological Sort
-Dynamic programming in a graph context
-Union Find
-Merkle Trees
-Fenwick (binary indexed) trees
Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.
As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them.
Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell?
Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about.
Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...
At least in SV, not having the support staff to fully insulate engineers from these kinds of conversations is the norm, not the exception. If you are a run of the mill senior engineer at the highest paying companies in the the area you're expected to be able to have these conversations. My experience is that exceptions are only made for people who are true technical wizards.
As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes.
Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language.
If you haven't, I'd encourage you to read the paper "Some Were Meant For C"[0] on why C still doesn't have a real replacement (though it could in the future).
The educational field has been trying to do create tests that cannot be gamed for over a century. The problem is that "gamification" is just a form a studying. In general, folks want tests to have the following properties.
1. Consistency of measurement across test-takers for a defined set of skills
2. Relatively short time-bounds (few hours).
In job hiring, the approach that tries to sacrifice (2) is contract-to-hire, just let the person do the work for a month! Turns out that people with in-demand skills aren't super interested in this.
Companies with more than a handful of engineers don't want to sacrifice (1) both out of fear of lowering the hiring bar too and because it may open them to discrimination lawsuits.
Once you have both of these constraints the number of "test permutations" (along with their relevant evaluative criteria) become limited enough that people can study them and thus gamification begins.