[snuxoll]

Really depends on the company and interviewer. I can't teach problem solving and critical thinking skills, but those are what I focus on during interviews and why I toss 98% of the applications that make it to my manager and myself after an interview. Given I am a hybrid SRE/SWE my role and team is a bit weird, but I can give somebody extra time on tasks while they're learning new tools or responsibilities, what I can't do is have somebody tell me "I don't know how to do that" and require I sit with them and walk them through the entire thing or create a detailed step-by-step design document that takes longer than doing the work itself. Being able to do the research, think about the problem, and design a solution is what separates the warm bodies that contracting firms provide from actual engineers - and I don't just need warm bodies.

Hell, if I had an open req right now I'd ask for your CV, because I think you're probably being a bit too hard on yourself and overthinking things. There's plenty of chill places who just need somebody to keep those couple critical pieces of software that are 15 years old running, and there's nothing wrong with work just being a means to an end.

EDIT: Actually, send it to me anyway. If nothing else I can at least give you some more specific advice or a mock interview and see if there's anyone in my network that you'd fit with. Email's in my profile.

[leeroihe]

I really appreciate your thoughts here - I'll send my cv your way.

I'd say my strong-suit is in vaguely defined zero to one work and scale out for more sharply scoped functionality. That said, if you ask me to write a react app from scratch, I'm likely just going to lean on cursor / claude to do the boilerplate and hop in when I need to make sure things are surgically correct.

[jmye]

> what I can't do is have somebody tell me "I don't know how to do that" and require I sit with them and walk them through the entire thing

Man is this underrated. My peers are so hyper-focused on whether or not new hires know SQL (of all things), and not whether they can adequately problem solve. And then they wonder why my hires, though they might start slower, end up being stars.

To your other point, I’m even fine spending a day explaining the business to someone new - it’s complicated. But I try to bring on people who only have to hear it once.

Anyways, I guess I just like to +1/amplify sensible hiring posts.

[snuxoll]

Explaining the business is part of onboarding, both for employment as well as introducing somebody into an existing project IMO. It took me years to fully grasp everything with the team that I started with, and that’s not a knock on anything, but the reality of processes that grew organically for the 10+ years before I started there.

I love sitting down with newer employees, especially junior engineers, and going over stuff like that, along with explaining why specific design choices were made, and concepts they may be unfamiliar with. One of the ones that paired with me on many of my projects from my original team is now the maintainer of those very same projects now, and hot damn does it bring a smile to my face that somebody can send me a message about something and I can just @mention him and pass the buck without worrying. We’d mostly been a .Net+MSSQL shop and these projects were a mix of Python, Kotlin, and PostgreSQL, but he ran with it after I helped get him setup and walked him through the code and gave him some time to pick up the tools.

That success is what solidified my views that critical thinking skills, along with a commitment to lifelong learning, are the best indicators of success for new hires with my org. I can’t teach people these qualities, but those that have them will seek the answers and know how to apply them once they’ve picked them up.