I’m pretty convinced something has gone badly wrong in how we teach Computer Science and Data Science.

When I studied CompSci, the discipline was framed very simply: Client has a real-world problem → you model reality → you implement the model.

You were trained to think in terms of:

Code was the last step. The degree was fundamentally about modeling.

This wasn’t arbitrary pedagogy. It reflected a deep truth: software engineering is applied problem-solving, not memorizing APIs. The hardest part of building systems isn’t writing the code – it’s understanding what to build in the first place.

The Magic Hat Mentality

What I see now, over and over, is a completely different mindset.

Code is treated like a magic hat. You throw buzzwords, libraries and architectures into the hat, chant “pipeline”, “LSTM”, “API”, “microservices” a few times… and you hope a solution appears.

If you pause the process and ask basic questions:

…you often get nothing. Just more soup: another acronym, another framework, another vague answer about “insights”.

Here’s a real example from our interviews: A candidate proposed building a recommendation system using collaborative filtering and neural networks. When asked what problem this solved for the business, they said “to provide personalized recommendations.” When pressed on why the business needed personalized recommendations, what metric would improve, and how we’d measure success, they had no answer.

They could describe the architecture in detail. They knew the libraries. They’d built similar systems in coursework. But they had never been forced to ask: Does this actually solve a problem worth solving?

What We Learned From 2,000 Hours of Interviews

In a current hiring round we had well over a thousand applicants and hundreds complete a fairly demanding quiz and interview process. That’s easily ~2,000 hours of candidate time.

Across all the transcripts and answers, the most striking pattern wasn’t missing syntax or tooling skills – it was missing thinking.

Smart, hardworking people who have:

Some specific patterns we saw repeatedly:

Pattern 1: Solution-first thinking. Candidates would jump immediately to implementation details without understanding the problem. “We’ll use a microservices architecture” – okay, but why? What problem does that solve? What are you trading off? Silence.

Pattern 2: Cargo cult complexity. Proposing elaborate solutions for simple problems because “that’s how it’s done at scale.” A candidate suggested Kafka, Redis, and a machine learning pipeline for what was essentially a daily batch report. When asked why, they said “for real-time processing.” The business requirement was next-day reporting.

Pattern 3: Inability to question assumptions. Given a problem statement, candidates would accept it at face value and start coding. Nobody asked: “Why does the client think they need this? What’s the actual underlying problem? Are we solving the right thing?”

Pattern 4: No economic reasoning. Asked how they’d prioritize features, candidates would list technical challenges or “what’s interesting” rather than thinking about user value, development cost, or business impact. The idea that software exists to create economic value seemed foreign.

Pattern 5: Metrics theater. When asked how to measure success, answers were always technical: “99.9% uptime”, “sub-100ms latency”, “90% accuracy”. Never: “reduces customer churn by X%”, “saves the operations team Y hours per week”, “increases conversion by Z%”. The disconnect between technical metrics and business outcomes was total.

I don’t think this is an individual failing. It looks systemic.

Why the System Produces This

The incentives in higher education have become misaligned with learning outcomes.

Universities Are Optimizing for the Wrong Metrics

Degrees are designed so almost everyone can “pass”. It’s much easier to teach tools than modeling. Universities are rewarded for enrollments and completions, not for whether grads can translate messy business problems into working systems.

Teaching tools is quantifiable. You can test whether someone knows pandas, TensorFlow, or React. You can measure completion rates and pass/fail statistics. You can scale it to hundreds of students with auto-graded assignments that check if the code runs and produces the expected output.

Teaching modeling is messy. It requires judgment calls, deep feedback, and the willingness to fail students who can’t demonstrate clear thinking – even if they memorized all the right frameworks. It doesn’t scale well. It’s subjective. It creates complaints. It hurts completion rates.

So the system drifts toward what’s measurable and scalable, not what’s valuable.

The Bootcamp Effect

The rise of coding bootcamps accelerated this trend. Bootcamps promise job-ready skills in 12 weeks. There’s no time for fundamentals, for teaching people to think. It’s all frameworks, tutorials, and portfolio projects that follow a template.

This creates a race to the bottom. If bootcamp grads can get jobs after 12 weeks, why should universities make students struggle through theory, algorithms, and systems thinking for four years? Better to teach practical skills, ship grads faster, and collect tuition.

The tragedy is that bootcamps were never supposed to replace CS degrees – they were meant to retrain people who already knew how to think, who had degrees in other analytical fields and just needed programming skills. But the model got applied to complete beginners, and universities started copying the approach.

The Tutorial Culture

Modern learning resources have made this worse. YouTube, Udemy, and Medium are full of tutorials that show you how to build something, but rarely why or when you should build it that way.

“Build a Todo App with React and Firebase”
“Machine Learning Project: Predict House Prices”
“REST API with Node.js in 30 Minutes”

These are tools for people who already understand when and why to use these technologies. For beginners, they become recipes to follow without understanding. You learn to copy-paste patterns without internalizing principles.

Students complete dozens of these tutorials, build impressive-looking portfolios, and graduate feeling competent. Then they encounter a real business problem – messy, ambiguous, with competing stakeholders and unclear requirements – and discover they have no idea how to approach it.

The “Insights” Trap in Data Science

Data Science has its own special failure mode. The field attracts people who like the idea of “uncovering insights” from data, which sounds intellectually exciting. But nobody teaches them to ask: What decisions will these insights inform? Who will act on them? What happens if they’re wrong?

So you get data scientists who:

I’ve seen data scientists spend months building a sophisticated churn prediction model, achieve 85% accuracy, present it proudly to the business team, and then watch it gather dust because nobody thought to ask: “What would we do differently based on this prediction? Do we have the resources to act on it? What’s the ROI of building this?”

The model was technically impressive. It was also economically worthless.

What Gets Lost: The Modeling Discipline

The old approach to computer science wasn’t perfect, but it got something crucial right: you cannot automate what you cannot understand.

Before you write code, you need to:

1. Understand the real-world domain. What are the entities? What are the rules? What are the edge cases? If you’re building a system for a restaurant, you need to understand how restaurants actually work – not your idealized notion, but the messy reality of inventory spoilage, no-shows, special requests, kitchen capacity constraints, and peak hours.

2. Build a model. Abstract away the irrelevant details. Identify the core relationships and constraints. Choose appropriate data structures and algorithms based on the problem properties, not because they’re trendy.

3. Validate the model. Before implementation, check: Does this model capture the essential behavior? What assumptions am I making? What breaks the model? Can I reason about edge cases?

4. Implement carefully. Write code that reflects your model clearly. Choose technologies that fit the problem, not because they’re on your resume or in fashion.

5. Measure against reality. Does the system solve the actual problem? How do you know? What would falsify your assumption that it works?

This process forces clear thinking. It makes bad assumptions visible early. It prevents you from building elaborate solutions to non-problems.

Modern CS education often skips steps 1-3 entirely and jumps straight to implementation. Or worse, it presents problems that are pre-modeled, with clear specifications and expected outputs, so students never develop the muscle to do the hard work of translating reality into code.

The Real-World Cost

This isn’t just an academic concern. It has serious economic consequences.

For Businesses

Companies are paying for graduates they then have to completely retrain. That junior developer you hired? They can write React components, but they can’t figure out why your checkout flow is broken or how to prioritize the backlog. You need senior developers to constantly translate business problems into technical specifications, which defeats the purpose of hiring additional developers.

The data scientist you hired can run regression models but can’t explain to the VP of Sales why their proposed dashboard is asking the wrong questions. So you pay them to build things that don’t matter while the real problems remain unsolved.

For Early-Career Developers

Graduates enter the workforce believing they’re competent, then get blindsided by the reality that they can’t function independently. They’re stuck in junior roles longer, underpaid, or worse – they bounce between jobs feeling frustrated and inadequate without understanding why.

The students who figure this out independently and teach themselves to think systematically about problems advance rapidly. The ones who don’t remain stuck, constantly learning new frameworks but never developing the underlying skills that make frameworks useful.

For Technology Quality

Systems built without proper modeling are brittle, unmaintainable, and expensive. They work for the happy path but break in unexpected ways. They’re over-engineered in some places and under-thought in others. They accumulate technical debt rapidly because nobody understood the problem well enough to design for change.

We end up with a codebase that’s a pile of solutions in search of problems, duct-taped together with integration code that nobody understands.

What Senior Developers Actually Do

Here’s what many students don’t realize: senior developers write less code, not more.

They spend their time:

The jump from junior to senior isn’t about knowing more libraries or writing faster code. It’s about developing judgment: knowing what to build, what not to build, and why.

You can’t develop judgment from tutorials. You develop it by being forced to think carefully about problems, making decisions with incomplete information, seeing the consequences, and learning from mistakes.

A Way Forward

If you’re a student or early-career developer, my unsolicited advice:

1. Treat CompSci/Data Science as a Modeling Discipline, Not a Tools Discipline

The frameworks will change every few years anyway. React was released in 2013; before that, everyone used jQuery and Backbone. In 2013, TensorFlow didn’t exist – everyone used Theano and Caffe. The entire machine learning landscape has been revolutionized three times in the last decade.

The ability to break down a problem, understand the underlying reality, and construct a valid model is permanent. Learn that, and picking up new tools becomes trivial.

Concrete practice: When you encounter a tutorial, don’t just follow along. Stop at the beginning and try to solve the problem yourself first. What data structures would you use? What algorithms? What are the edge cases? Only then look at the solution and compare your approach to theirs.

2. Learn to Ask Better Questions

Before you write code, force yourself to answer:

Concrete practice: Take any tutorial project and rewrite the problem statement in business terms. “Build a todo app” becomes “Help busy professionals track and prioritize their daily tasks to reduce cognitive load and increase productivity.” Now ask: Does the todo app actually solve this? How would you measure it? What alternatives might work better?

3. Study Systems, Not Just Code

The best developers I know aren’t necessarily the best coders. They’re the best systems thinkers. They understand:

Concrete practice: Read case studies of system failures (there are great compilations online). Study not just what went wrong technically, but why the organization built it that way, what incentives led to bad decisions, and what could have been done differently.

4. Learn Economics or Philosophy

Both disciplines have spent centuries refining frameworks for clear thinking about cause, effect and trade-offs.

Economics teaches you to think about incentives, trade-offs, opportunity cost, and how systems reach equilibrium. When you understand that people respond to incentives, you stop designing systems that assume perfect user behavior.

Philosophy (especially logic and epistemology) teaches you to identify hidden assumptions, construct valid arguments, and think carefully about what you can actually know versus what you’re guessing.

Concrete practice: Read “Thinking in Systems” by Donella Meadows, “The Most Important Thing” by Howard Marks, or any introduction to logic and critical thinking. Apply the frameworks to technical decisions you face.

5. Build Things Where Failure Costs You

Coursework is consequence-free. If your solution is bad, you get a lower grade and move on. This prevents you from developing judgment.

Build something where you’ll feel the pain of bad decisions:

When your bad architecture decision means your site goes down at 2am and you have to fix it, you learn. When your overcomplicated solution makes the codebase unmaintainable and you have to live with it, you learn. When you build something nobody wants because you didn’t validate the problem, you learn.

Concrete practice: Pick a problem you personally have and solve it. Not a problem from a tutorial, but something you genuinely experience. You’ll be forced to think through all the edge cases because you’re the user. You’ll learn whether your solution actually works because you’ll use it every day.

6. Always Answer: “Who Pays for This, and Why?”

This single question forces you to think about value, incentives, and whether your solution actually solves a real problem.

“Who pays” reveals the business model. Is this B2C, B2B, marketplace, advertising, freemium? Each has different constraints and success metrics.

“Why” reveals whether you’re solving a real pain point or a nice-to-have. People pay to make pain go away or to achieve important goals. They don’t pay for clever technology.

If you can’t answer this question, you’re probably building a solution in search of a problem.

Concrete practice: Look at successful products and reverse-engineer the answer. Why does Slack work? Because companies pay to make internal communication less painful and chaotic. Why does Stripe work? Because online businesses pay to accept payments reliably without building complex infrastructure. Now apply this lens to your own projects.

7. Deliberately Practice Modeling

Like any skill, modeling improves with practice. Here’s how to practice deliberately:

Start with toy problems: Take a real-world system (a library, a restaurant, a parking garage) and model it. What are the entities? What are their relationships? What are the constraints? What are the edge cases? What state needs to be tracked? What are the invariants?

Compare your model to reality: Go observe the actual system. What did you miss? What assumptions were wrong? Where does your model break down?

Iterate: Refine your model based on what you learned. What’s the simplest model that captures the essential behavior?

Only then implement: Write code that reflects your model. Does the code structure match your mental model? If someone else read your code, could they understand the system?

Concrete practice: Model your university’s course registration system, or your local coffee shop’s ordering process, or how your city’s public transit works. Don’t code it yet – just model it. Identify all the business rules, edge cases, and assumptions. Then observe the real system and see what you missed.

For Educators: What Would Better Look Like?

If you’re teaching CS or data science, here are some suggestions:

1. Fail students who can’t think, even if they can code. Yes, it hurts completion rates. Yes, students will complain. But you’re not doing them favors by passing them through if they can’t function in the workforce.

2. Assign messy, ambiguous problems. Real-world problems don’t come with clean specifications. Give students a business scenario and make them figure out what to build. Make them talk to “stakeholders” (other students or faculty playing roles) and extract requirements.

3. Require economic justification. For every project, students should answer: Who would pay for this? Why? What’s the ROI? How do you know it works? Make them present to “executives” (faculty from business or other departments) who ask hard questions about value.

4. Teach the history of failed systems. Study the Healthcare.gov launch disaster, the Knight Capital trading glitch, the Therac-25 radiation overdoses. What went wrong? What should have been done differently? What were the systemic causes?

5. Emphasize reading code over writing code. Students write thousands of lines in coursework but rarely read others’ code. Make them study well-designed systems, understand the architecture decisions, and explain why the code is structured that way.

6. Bring in practitioners. Not to give inspirational talks, but to review student work and ask the questions real clients would ask. Why did you build it this way? What’s the business justification? What happens when…?

7. Reduce the number of frameworks covered. You don’t need to teach the latest JavaScript framework. Teaching principles with one framework is more valuable than surveying ten frameworks shallowly.

The Bottom Line

Code is incredibly powerful. But it’s not a magic hat.

If we keep teaching it that way – as a collection of spells to memorize rather than a tool for implementing carefully-reasoned models – we’re failing a generation of students and the businesses that try to hire them.

The good news? This is fixable. It starts with recognizing that computer science is, first and foremost, about thinking clearly about systems. The code is just how we express that thinking.

We need to stop optimizing for completion rates and start optimizing for developing people who can think. We need to stop teaching tools and start teaching judgment. We need to stop treating software as magic and start treating it as engineering: the disciplined application of scientific principles to solve real problems under constraints.

The students are capable of this. The demand from industry is overwhelming. The only thing standing in the way is a system that’s optimized for the wrong outcomes.

It’s time to fix it.

What do you think? Have you seen these patterns in your own education or hiring? I’d love to hear your experiences – especially from educators trying to swim against this current.