From 2.67/25 to 72% in C Programming

Yesterday, I got 2.67/25 in an Algorithms topic-wise test.

Today, I gave another test.

Considering what happened the previous day, convincing myself to sit for another topic-wise test could have been difficult. A bad test has a strange ability to make you question whether attempting another one is a good idea or whether you should simply disappear into a cave and study formulas for six months.

Fortunately, today's subject was C Programming, which is one of my stronger subjects.

And this time, things went considerably better.

I scored:

18/25 — 72%

My first topic-wise test score above 70%. 🎉

The result was:

View my C Programming Topic Wise Test 2 result →

The difference between yesterday's Algorithms test and today's C Programming test was also a useful reminder: a score means nothing without analysing why it happened.

---

Completing Group Theory Lecture 2

Before the test, I continued my Discrete Mathematics preparation and completed Group Theory Lecture 2. ✅

The lecture itself is now complete, but the notes are still pending.

I probably won't get enough time to complete those notes today, so the plan is to finish them by Saturday.

I've learned from previous experience that pending notes can quietly become a backlog if I keep moving forward without dealing with them. So Lecture 2 notes are now something I want to close as soon as possible.

---

C Programming Topic Wise Test 2

After yesterday's Algorithms test, I wasn't exactly overflowing with confidence about giving another test.

But C Programming is one of the subjects where I generally feel more comfortable, so I decided to go ahead.

And thankfully, the test became a much better experience.

The most interesting part wasn't just the 72% score.

It was analysing how I solved each question and, more importantly, why I lost the marks that I lost.

---

Some Questions Took Time for Verification, Not Because I Was Stuck

One thing I noticed while analysing the test was that the raw time spent on a question doesn't always tell the full story.

For example, there were questions that showed more than two or four minutes of time, but I had actually understood the solution much earlier.

The remaining time was spent:

• verifying options,
• tracing again,
• checking whether I had missed something,
• or making sure the answer I was about to mark was actually correct.

Question 7 was a good example

The recorded time was more than two minutes.

But I had actually solved the key part in around 20 seconds.

I calculated one distinguishing output and checked the options. Only one option matched it.

At that point, there was no need to trace the entire program unnecessarily.

The rest of the time was simply spent checking whether I had interpreted everything correctly.

Sometimes solving the whole question is unnecessary when one condition can eliminate every other option.

A small reminder that in an exam, smart elimination is also a solution method.

---

The First Mistake: Testing Only One Example

One of my incorrect answers was a question about checking whether a function correctly identifies an odd positive integer.

The correct answer involved options A and C.

I marked:

A, B and C.

The reason was embarrassingly simple.

I left the question for later, and by the time I returned to it, I didn't have much time.

So I tested the function using 3, an odd number.

For that particular value, option B appeared to work.

And I marked it.

The problem was that the function was supposed to work for all positive odd integers.

I never tested:

• 5
• 7
• 9

If I had tested even one more value, I would have immediately seen that option B failed.

This wasn't really a lack of understanding about odd numbers or integer division.

It was a rushed verification mistake.

One example supporting an option does not prove that the option works universally.

Apparently, 5 was waiting quietly in the background to expose my answer. 😭

---

The Best Question of the Test: Question 12

Question 12 was probably my favourite question after analysing the entire test.

Ironically, I skipped it during the actual exam.

The question involved an array declared with 10 elements, but only 9 values were explicitly given.

I didn't know what value I was supposed to consider for the remaining element at index 9.

That missing concept stopped me from properly attempting the question.

Later, during the analysis, I learned the rule:

If an array is declared with a fixed size and fewer initialiser values are provided, the remaining elements are automatically initialised to zero.

So:

int a[10] = {4, 10, 5, 6, 9, 3, 1, 20, 7};

also has:

a[9] = 0

That was the only major concept I was missing.

Once I understood it, the rest of the question became much clearer.

The recursive logic involved comparisons and moving through the array using pointer arithmetic. I didn't get the correct answer immediately during analysis because of a silly tracing mistake, but after that, I was clear about the entire mechanism.

This was probably the most valuable thing I learned from today's test.

Sometimes one tiny missing language rule can prevent you from even starting a question whose remaining logic you are perfectly capable of understanding.

---

The Most Painful Mistake: Missing a Nested Function Call

Question 13 was probably the most frustrating mistake of the test.

The expression contained:

GOClasses(GOClasses(i))

During the test, I somehow missed the fact that there was a function call inside another function call.

I effectively solved only:

GOClasses(i)

instead of taking that result and passing it again into:

GOClasses(...)

The annoying part?

I checked my answer twice.

And still missed it.

So my calculations were being checked carefully, but I was calculating the wrong thing from the beginning.

During the test analysis, once I properly read the expression and included the outer function call, I solved the question correctly.

Those were probably two marks I should have taken.

The lesson here is very simple:

Before tracing a complicated expression, understand the structure first.

For a nested call, I should mentally rewrite it as:

Step 1: Solve the inner function call.
Step 2: Pass its result into the outer function.

That would have prevented the entire mistake.

---

Accuracy Matters More Than Looking Fast

A few recursion questions took me longer than expected.

For example, the mutually recursive functions question required careful tracing, and I spent almost six minutes getting the answer.

Could I be faster?

Definitely.

But for now, I would rather be:

Slow and correct

than:

Fast and confidently wrong.

Speed can improve with repeated practice.

Accuracy is what gives the speed a purpose.

The same happened in several other questions. I knew the likely answer but still solved the question from scratch because I wanted to make sure my memory wasn't fooling me.

Human memory is surprisingly confident for something that can be completely wrong.

---

Understanding What the Question Is Actually Asking

Another interesting question involved three functions:

• a()
• b()
• c()

Each function returned 1.

Initially, I thought:

No matter what order the functions are evaluated in, the final numerical value will always be 3.

That was true.

But then I noticed the actual question was asking about the possible outcomes on different compilers.

The functions were also printing their respective letters.

Because the order of evaluation was unspecified, the printed output could appear in different orders:

• abc
• acb
• bac
• bca
• cab
• cba

So the answer was:

3! = 6 possible outcomes

The concept itself was easy. The important part was understanding what the question meant by the word “outcomes.”

GATE questions are often like that.

The technical concept stands there looking harmless while the wording quietly steals two minutes from your life.

---

What My 72% Actually Means

The most useful thing about analysing today's test is that I can now clearly separate my mistakes.

My two incorrect answers were mainly caused by:

1. Rushed verification

I tested only one example when the condition was supposed to work generally.

2. Missing a detail while reading

I completely missed the nested function call in Question 13.

The two skipped questions also gave me useful information:

• One exposed some uncertainty about static and extern linkage across multiple files.
• The other exposed one missing concept about partial array initialisation.

The important part is that this test did not reveal a major weakness in my C Programming fundamentals.

That was a big difference compared to yesterday's Algorithms test.

Yesterday, the 2.67/25 score exposed a genuine conceptual gap in my understanding of Divide and Conquer.

Today's test showed something else.

My C concepts were mostly there.

The bigger danger was:

Rushing, incomplete verification, and occasionally not reading every part of an expression carefully enough.

And honestly, that's a much more manageable problem.

---

Computer Networks Got Postponed

The original plan also included a short Computer Networks warm-up recall.

I didn't get to it.

So CN has been postponed to:

• Saturday, if I get time, or
• Sunday as a backup.

The plan was only to skim notes, recall important concepts, and update the error log if necessary. No new material was planned.

Sometimes the schedule doesn't get completed exactly as written.

Shocking news. A spreadsheet has once again discovered that humans have limited hours and energy. 😭

---

Today's Small Win

My biggest win today was simply giving another test after yesterday's terrible Algorithms result.

Yesterday:

2.67/25 in Algorithms

Today:

18/25 in C Programming

That doesn't erase yesterday's problem.

The Divide and Conquer gap still needs to be fixed.

But it does remind me not to let one terrible test convince me that my entire preparation is terrible.

Different subjects can reveal completely different things.

One test can expose a conceptual gap.

Another can expose careless mistakes.

The score alone doesn't tell the whole story.

The analysis does.

---

Tomorrow

The immediate plan is:

• Complete Group Theory Lecture 2 notes.
• Try to complete the postponed Computer Networks warm-up recall.
• If Saturday gets too busy, move the CN recall to Sunday.
• Continue the November revision and testing schedule without letting one subject's bad result define everything else.

Day 54 was a much better day than Day 53.

Not because everything was perfect.

I still lost marks that I shouldn't have lost.

I still skipped two questions.

And I still have pending notes.

But after the birthday gift of 2.67/25 in Algorithms, scoring 18/25 and crossing 70% for the first time in my topic-wise tests felt like a useful reset.

One bad test exposed a weakness.

The next test reminded me that weaknesses are not the entire story. 📚📈