I don't like it, but it's just the way it is now.
I imagine we operate in very different geographic regions of the USA.
For myself at least: absolutely yes. That's actually some of the first stuff they taught us. Would I want to be interviewed on whether I can implement a linked list from the top of my head in an arbitrary language and 100% correctly in a high stress interview situation? Absolutely not. (and a linked list in the end is something really really easy if you ask me)
Does that in any way relate to what I'm doing right now? A little! This will differ depending on who exactly you work for and in what role. It certainly helps to have learned this stuff. I can honestly say that it was fun seeing how regular expressions actually work, how you implement a parser for it etc. But then you learn as well (right there in university) that you better use a parser generator after just having defined the grammar instead of writing it yourself. How many jobs are out there that require you to write a grammar for something? To create a new language? Very very few. There's a market for "boring business software X" software developers.
Is it the most important thing I consider when hiring? Absolutely not. We also don't pay FAANG salaries where I work. Do I want capable software developers? Smart guys for sure. People that are curious, willing and able to learn, writing maintainable code. Guys that if I tell them that there's a hidden n^3 algorithm in what they just wrote and it _does_ matter for the (relatively small but large enough) volumes of data this will run on can look up/ask for what that means.
EDIT: interesting down votes. I hope someone will reply to explain. I certainly don't see why we can't have a civil discussion especially given that we seem to agree on it having been good to get a solid university education. FWIW I have a Master's in Computer Science. From a country that values non university education (Germany - where you can do vocational training to become a programmer. Just like you can become a master carpenter through that system).
It’s also really downplaying how much one can learn when they need it for an application - yes it’s true you have to know about something to go after learning it, but there’s nothing stopping someone picking up a book when they get stuck to learn about what they don’t yet know.
Much of a CS course is nice to have knowledge for many programmers, and can be plenty beneficial. But a CS degree is there to show you theory not teach you how to program - the amount of people with degrees that are very poor at even basic programming is not as low as you’d think.
I work on a very large system, but spend far more time chasing down poor performance due to emergent behavior than I do worrying about Big O on some small piece.
It predicts how much time they spent solving leetcode, and biases towards recent graduates. If you’re hiring senior talent it’s mostly a wash and a waste of time. But it’s deep in valley culture so we’ll likely waste our time with it for another decade or so before we wise up.
Many of the best programmers I've worked with haven't.
Would I be a good CS researcher? No, not even close.
Am I a good software engineer? Damn straight I am.
Would I work with you? Sounds like we wouldn't be a good "culture fit."
I think it also helps to remember that interviews are two-way. If you see a company with an insane interview process, do you really have confidence in the quality of a team you’d be on when you got to the other side of it?
These days I generally look for and focus on a few things when I interview with a company I’m interested in:
1. How do they make money?
2. Do they understand how they make money? Alternatively, do they understand their market, customers, and product value?
3. How mature is management? Good managers make or break your job satisfaction and dictate how good a company is at hiring & retaining talent, as well as dealing with adversity like professional adults.
4. How much of the work I’m doing is driven by planning as opposed to circumstance. E.g. am I working off a roadmap or expecting to spend the majority of my time handing incidents and fighting fires.
Your mileage may vary, but I suspect these good or bad interview practices will only exist as long as hiring managers allow them to.
Exactly this. As someone who works primarily on frontend, I immediately disqualify any company whose frontend interview process for seniors+ doesn't involve actually building a frontend app/page/component/etc.
If I was ok with the prospect of working on a team with senior frontend engineers whose only competency was cramming leetcode, I might as well work at one of the tech giants.
What question(s) do you ask the companies to get information for this?
1. What does your roadmap look like? Do you have a roadmap?
2. How reliable is the team about hitting deadlines? Why or why not?
3. Who handles incident response? How frequently does this responsibility rotate?
4. For a given week, how much work is planned vs interrupt driven (e.g. someone needs something by the end of this week and we only learned about it days prior).
5. How much firefighting does this team do? Is this driven by the team's own work or issues in other parts of the organization?
Your mileage may vary, there are a lot of ways to get a sense of how a team/org works and what may be important to me may or may not be as important for you. Cheers!
Software engineering is not investment banking or law.
Is this how Silicon Valley engineering careers work?