What are data structures and algorithms and do I really need them?

Both things are true: DSA is partly interview theatre, and it's also a real gap — just not in the way it's usually sold. You need enough to make good decisions and pass interviews; you don't need competitive-programming depth to be a good developer. What they actually are, briefly. Data structures are ways of organising data (arrays, hash maps/objects, sets, linked lists, stacks, queues, trees, graphs). Algorithms are procedures for doing something with that data (searching, sorting, traversing). The useful part isn't memorising them — it's knowing the cost of each choice, which is what Big-O notation describes. Where it genuinely matters day to day: 1. Choosing the right structure. Looking something up in an array means checking every item; in a hash map it's effectively instant. The difference is invisible at 100 records and catastrophic at 100,000. This single concept probably accounts for most real-world performance bugs juniors write. 2. Recognising accidental nested loops. A loop inside a loop over the same data is quadratic, and it's how a page that was fine in testing dies in production. 3. Reading other people's code and library docs without being lost. Where it's theatre: being asked to invert a binary tree on a whiteboard for a job maintaining a React dashboard. That's a filtering ritual more than a job-relevant test, and it's fair to be cynical about it — while still preparing for it, because it's the gate in front of a lot of good jobs. The pragmatic plan for a self-taught developer: 1. Learn the everyday four properly: arrays, hash maps, sets, and Big-O intuition (constant vs linear vs quadratic). This is maybe two weeks and it's where nearly all the practical value sits. 2. Add stacks, queues, recursion, sorting and binary search conceptually — you should know when they apply, not be able to implement quicksort from memory. 3. Trees and graphs when you're actually preparing for interviews, or when you hit a problem shaped like them. 4. Practice on real problems in short regular sessions rather than a panic month before interviewing. The reassurance: you are not secretly a fraud for having built working software without this. Plenty of extremely effective developers learned DSA late, and shipping real things teaches you a lot that DSA practice doesn't. Treat it as filling in one specific gap, not as proof that your path was wrong.