Profile photo
Sunny WuUofT Computer Engineering

Intelligence: The Derivative of Knowledge

Definition

Aug 8, 2026

People confuse intelligence with knowing facts. Given you're not a child anymore, I'll take it that you no longer believe this. Nor is intelligence demonstrated by solving existing problems quickly or being high on the social ladder, although intelligence is associated with success. I strive to be better and I'm guessing you do to, and by systemizing intelligence, which I aim to do in this essay (even if you think objectifying the word is arbitrary), you are taking a step toward being more intelligent and likely more successful. So why might one think they know enough to stop reading here, and how does it stop them from progressing? If you keep to what you know and only what you know, you you stay static in a world that's speeds ahead and not stopping for you. From the outside perspective, you're not just stagnating, you're being left behind.

Knowledge (x) is as easy as ever to obtain, degrading the importance of your repository of raw facts. True intelligence is then better represented as higher-order derivatives: the velocity at which you make new connections with novel environments (x') and acceleration representing your rate of optimizing the connection creation process (x''). It is increasingly true that problems cannot be addressed simply by stating a fact. It is only by combining known items that you build new abstractions, where you must be intelligent to solve future problems consistently.

The first realization is that having the skill from running the process is more valuable than owning the result. YouTubers and businesspeople alike get rich from the skills they acquire in the time they spend growing successful processes, not successful products.

YouTuber Ken uploaded a video "I made a secret YouTube channel to prove it's not luck" critiquing Ludwig's video by the same name. Ludwig creates a video on a fresh channel by following a blueprint of creating a unique video idea, writing the script, producing the video, and marketing it to get thousands of views. It demonstrates Ludwig's impressive YouTube skill. However, Ken argues that one good video doesn't mean much, or in his words, "you don't just make it." Ken also grew a secret channel, with many videos unlike just the one on Ludwig's secret channel. Ken says: "What you want is not the quick blow up" in the context of getting better at making videos and continuous growth (x' > 0) through both the occasional viral hit and videos that aren't so hot.

You must be prepared to build off of lucky hits. That's in contrast to a one-time pass/fail test. If you gave a random person a big channel with all its resources, they would they would run it to the ground no doubt since they have no momentum. When you navigate the YouTube scene, you simultaneously align yourself with a blueprint (x) and choose which direction to continue experimenting (x'). The latter ultimately determines your intelligence, not your subscriber count nor strategy at any instance (dx).

While the case may appear the same with entrepreneurs, it actually raises a new question in a slightly different way. The key difference being money is a lot more tangible than subscribers, where the stakes for resetting are greater than for a YouTuber creating channels on the side. Entrepreneurs take risks even if it puts them into debt - yet they gain from their losses because the wealth isn't in the money, it's in the first-hand experience of creation.

A wonderful example of this is Walt Disney. Walt Disney Studios is far from his only attempt at success. By age 20, he had worked several jobs and started several studios, including Laugh-O-Grams Studio which succeeded by cartoonizing classic fairy tales. He hired animators to produce cartoon shorts but hit bankruptcy in 1923. In 1926, he founded the official Walt Disney Studio. Transitioning from cartoon shorts to full-length cartoon, Disney went for an ambitious 4-year production of Snow White using unheard of methods: sending his animators to top art institutes, hiring animals and actors to ensure natural movement, and developing the multiplane camera for realistic camera depth. Evidently, Walt cared more about the vision than the cost, spending 3x the budget but earning a return of over 4x the cost. On the balance sheet, he repeatedly gets in a position lower than a blank slate, reflecting his x, but his velocity x' remains positive and increasing. This rollercoaster of ups and downs is very defining of Disney, as the company soon dived into deep debt through Pinocchio and Fantasia, and continued accumulating debt during WWII. Trust from the bank and future successes like Cinderella kept Disney on track and now they're the largest film studio in Hollywood.

On the other hand, lottery winners demonstrate that result without the process often ends in bankruptcy. Such is the case of Michael Carroll who received over $10 million from a lottery while not even having a bank account. Bad decision after bad decision led to him becoming broke just 4 years later. You build momentum (x') through the approach, but mathematically can't differentiate the sudden influx of money (jump discontinuity): x' and x'' both do not exist. The serial entrepreneur may have a balance sheet (x) in the gutters but x' remains positive and increasing along with a positive meta-strategy x'' as they continue to innovate. The lottery winner gets an insane upward spike in x, but x' not only remains non-increasing, but actually becomes negative (x' < 0). Position x decays through spending and other money mechanisms without the skill gained through work (buying lottery tickets isn't meaningful work). Moreover, a lack of a learning system to slow down the decline means x'' = 0 at all times.

In the cases of the YouTuber and the entrepreneur, intelligence lies not in the result, but the insight gained by constantly adapting when growing their business. Patterns get more easily identified, and when those patterns change, so do the most intelligent people's understandings. Those who make it to the top are those who farm knowledge, make useful realizations, and reflect and take action on how they assess their information. So when it comes time to solve a previously unseen problem, they've amassed enough tidbits of information to construct a new structure to support the problem which they entered blind.

The process beats the outcome in student exams as it does in working professionals because test preparation is a test of optimization over subject knowledge. On the surface, your high school biology test asks you to recite countless facts and Canada's #1 engineering school UofT gives you an exam that contains a couple of physics problems barely different from your textbook practice problems. Harder exams do better than be solved by rote, aiming for you to apply what you know about evolution and moment arms to answer a hypothetical about imaginary species and calculate force applied in a complex rigid body system. However, the problem bank is finite. Once there are no unseen questions to be posed to the aspiring engineer and all that can be done is to change the numbers in the question, it's a no-brainer - all you have to do is memorize the steps.

Yet getting a degree is anything but rote.

Once you know the test problems and the approach to solve them, the next differentiator is understanding the approach of how to learn to solve them. While the problems are set, the question of how to study for them faster is like your first derivative, or your velocity. You can spam flashcards and all the practice questions you can find, or more intelligently, focus on the fundamentals and use select questions to test your problem-solving skills. If you find later on that the course heavily reuses questions, studying based on the questions from recent years' papers will yield even better results. Such a realization is an acceleration of your knowledge, meaning you approached the problem-solving process itself as the problem to solve, and further looked to improve that process.

The exact same system is applied to software technical interviews. They ask you to put your knowledge of data structures and algorithms toward various problems that require distinct computer-based thinking, that might be relevant to the job. Admittedly, it's becoming clearer and clearer that those problems are not going to appear in your everyday routine on the job and certainly not in your natural learning of the subject through creating projects (not counting university DSA courses because they seem to be designed for the interview). Though it might help to know what a linked list is and how to use pointers, you probably won't need to reverse a linked list. In essence, if the test must be deliberately prepared for, it neither tests the basics of someone who would naturally fit into the role nor their problem solving ability using those basics to a reasonable extent. That's Goodhart's Law:

When a measure becomes a target, it ceases to be a good measure.

(See my other blog on the pragmatic defense of proxy-gaming, where I discuss that optimizing strictly for the proxy is the only rational move, not a failure of intelligence)

The practice shows up in the form of Leetcode. At the time of writing, there are 4009 questions on the website. Memorizing all the solutions would likely get you through an interview, but would take a while - an unintelligent thing to do.

With only so many questions, there are only so many patterns, which can be found by googling "15 leetcode patterns" showing headlines like "LeetCode was HARD until I Learned these 15 Patterns." You are then studying something distinct from programming core and irrelevant for the job. Brainteasers asked by Google like "How many golf balls can fit into a 747?" but have been called "entirely useless" by Laszlo Bock, then-Senior VP of People Operations at Google, after finding zero correlation between response and job performance. Google has the data and the motivation to change, so why do they still do Leetcode-style interviews?

At least, they measure very basic knowledge like if you know what a binary tree is and how to write code in a programming language. If that was all they cared about though, interviews would be much easier. You also wouldn't pass without being able to follow the problem's instructions or knowing how to type which are implicitly tested - completing the task means that you can do these things, but are rudimentary.

Leetcode prevails because it demands a higher standard. Intelligence in solving the problem is not as important as the intelligence of solving a problem, solving another, and doing it over and over again. Find success in memorizing everything or understanding the core patterns until you are ready for the interview, of which the topic is somewhat arbitrary. You know the questions, you know the process (grind leetcode), but implicitly, you make it to the job based on how you study (x') and how you adapt your study methods to a changing landscape (x''). When you are confidently learning and preparing, you are intelligent.

When you prioritize the process, knowing feels useless. It's like we wasted our entire childhoods learning what teachers already knew when the key is to learn how to learn rather than only learning what there is to learn. Many engineering students, myself included, feel as if we know nothing and everything at the same time. Our minds have thrown away the specific mechanics of the the problems we solved, using them as fuel for the problem-solving engine. This is precisely the transition required for succeeding in an information-rich world. Studying distinctive mental models about intelligence itself contributes to cognitive velocity x', but the true test of x'' is how you turn your next novel obstacle into a piece of your adaptability machine.

>>  For the curious