I am leading hiring efforts for my small engineering team. We're looking for our third senior engineer (maybe five years of experience shipping code, and a little bit of time leading some technical or pastoral efforts).
Our technical interview process runs some one-to-two hours and starts with a problem. Something invented but plausible for a small, operations-software hybrid company. We introduce the problem in fuzzy human-friendly words, and then spend the rest of the interview turning it into well-defined terms. We codify it. And then we code (some of) it.
I'm looking to see if a candidate has built quality software, collaboratively. Have they made sure they understood the messy meatspace malaise, and can they can devise some precise presentable platonic solution. Did they use good people- and then computer-words to describe it.
Because we give such a tangible problem, we really encourage our candidates towards using classes. Classes also happen to be really good at organising code together, so we also encourage them everyday in the engineering team.
This is Object Oriented Programming (OOP), and it's an old term. You're going to come across OOP in theory, if not practice.
Yet having candidates arrive at "this could be a class", and not "this would be good as a set of pure isolated functions procedurally chained together in this file" has been hard. Bewilderingly hard.
Experience writing and managing software can give you a good box of tools, if you're actively looking around you. I'm interviewing experienced software engineers and asking them to model some entities and their behaviour, and they're not reaching for classes.
"Yeah, I guess we can try to use a class" feels weirdly unsatisfying.
In my darker moments I despair - why is no one doing OO?
Why have a quasi-random group of web software professionals repeatedly resisted one of the oldest, most common enterprise application patterns? I don't know. But I could make some cynical guess at notions of:
- "my code should be able to handle any data, its the users job to do the sensible thing"
- "I don't want to couple my code too closely to the real world"
- "React uses functional programming"
- "OO is old and no one writes 'enterprise software' anymore"
- "it doesn't matter what I call things in my code or where I put them"
- "it's not cool enough?"
Frameworks (Rails, Spring Boot), architecture patterns (MVC, MVVM), Books (Domain Driven Design, Clean Code/Architecture) all put Objects/entities/ models right there, obvious and near the centre.
They're there because they add value. Not to fill pages or as homage to bygone software practices. Software engineering and computer science are a competitive ecosystem, and evolution would select against them if there wasn't something there.
How is the industry producing young, competent, practicing professionals who struggle to model real world problems? Why is no one doing OO?
See other articles