After failing the OCP Java 21 twice, I went back to Chapter 1 and started teaching all 94 certification topics. It changed the way I learned Java.
There is a big difference between understanding something well enough to answer a question and understanding it well enough to explain it to someone else.
I learned that difference during my 17-month journey to the OCP Java 21 certification.
When you’re studying alone, it’s easy to read a page, understand the example, answer a question correctly, and think:
“Got it.”
But then someone asks:
“Why?”
Or:
“What would happen if we changed this line?”
Or:
“Why does this one compile, but the other one doesn’t?”
And suddenly, “I know the answer” is not enough.
You need to understand the rule behind the answer.
You need to find a way to explain it.
And sometimes, while trying to explain it, you discover that you didn’t understand it as well as you thought you did.
I remember one of our weekly meetings early in the community. We were discussing a question involving records and sealed classes. We went through the question, discussed the answer, and could easily have moved on to the next one.
But then Thiago Bonfim started asking questions.
“What if we changed this line?”
“What if there was another class extending the base class?”
And then another “what if?”
And another.
Soon, the original question was no longer enough to answer what we were discussing.
So we opened the IDE.
We changed the code and started testing those different scenarios together. We explored edge cases, tried variations, and spent much more time on that single question than we had originally planned.
But we also left that discussion with a much deeper understanding of the concepts than we had when we first answered the question.
Today, this happens all the time in our weekly meetings. When someone has a question or we want to go deeper into a concept, we open the IDE and explore it together.
That experience taught me something that became increasingly important throughout my preparation:
Sometimes the best question isn’t the one in front of you. It’s the “what if?” that comes after it.
And eventually, that changed the way I learned Java.
I was already teaching during my first preparation
When I started preparing for the certification in 2025, I wasn’t simply reading the Study Guide from beginning to end.
The Java 21 Certification Study Group already existed, and studying had become a community activity.
As I progressed through the OCP Java SE 21 Developer Study Guide, I prepared summaries in Portuguese for each topic and shared them in our Discord server.
I created questions in Google Forms for our weekly meetings.
I prepared slides combining explanations from my summaries with questions we could discuss together.
I created a GitHub repository with code examples from the Study Guide.
And while reading, I constantly opened my IDE to run examples, modify them, break them, and see what Java would actually do.
So teaching was already part of my first preparation.
But after failing the exam twice, something changed.
Going back to Chapter 1
On August 11, 2025, after failing the certification exam twice, I went back to Chapter 1.
I had already been studying and teaching Java with the community for months.
But this time, I wanted to go deeper.
The Study Guide divides the certification content into 94 topics.
I decided that I would go through all 94 of them again.
But instead of simply rereading each topic, I gave myself a new responsibility:
I was going to teach every one of them.
94 topics. 94 opportunities to find out what I didn’t know.
For every topic, I started preparing a video in Portuguese for our Discord community.
One topic per weekday.
Monday through Friday.
At the same time, I created an English carousel about the same topic for LinkedIn.
That meant that before moving forward, I had to take what I had just studied and transform it into something another person could understand.
For the videos, I prepared slides and thought about how I would explain the concept.
For the LinkedIn carousels, I had to compress that same concept into a much smaller format.
And for both, I needed examples.
Suddenly, reading wasn’t the end of the study process.
It was the beginning.
Read it. Understand it. Test it. Explain it. Simplify it.
Then move to the next topic.
And repeat.
Ninety-four times.
Teaching exposes the gaps
One of the most interesting things about teaching is that it exposes the difference between recognizing an explanation and being able to reconstruct it yourself.
When you’re reading a book, the explanation is already there.
The author chose the example.
The author organized the reasoning.
The author decided what information should come first.
You can follow that reasoning and feel that everything makes sense.
But when you close the book and try to explain the same concept yourself, all of that structure disappears.
Now you have to build it.
What is the rule?
What is the simplest example?
What could confuse someone?
What happens if I change this?
Does this compile?
Why does Java behave this way?
That process repeatedly exposed gaps in my understanding.
Sometimes I would start preparing a slide and realize that I couldn’t explain something clearly.
That was a signal.
I wasn’t ready to teach that concept yet.
So I would go back to the Study Guide, experiment with the concept in the IDE, and try to understand what I was missing.
Only then would I return to the explanation.
Teaching became a test of my own understanding.
“Why?” became more important than “What?”
Certification preparation can easily become a process of recognizing rules and patterns.
You see a question.
You recognize the concept being tested.
You find the answer.
Next question.
But teaching made that approach much harder.
If someone asks why an answer is correct, saying “because that’s the rule” isn’t a very useful explanation.
I needed to understand why the other alternatives were wrong too.
What would need to change for one of them to become correct?
Would the code compile if we changed the type?
What happens at runtime?
What exactly is the compiler seeing?
These are also the kinds of questions I eventually started asking myself while reviewing mock exams.
Instead of stopping at:
“I got this question wrong.”
I started asking:
“Why did I get it wrong?”
And then:
“What don’t I understand yet?”
That change became extremely important later in my preparation.
The community became part of the learning process
There was another part of teaching that I couldn’t reproduce by studying alone:
other people’s questions.
When you prepare a presentation, you naturally prepare around the questions you expect.
But someone else doesn’t have the same mental path you do.
They may look at your example and notice something completely different.
They may ask about an edge case you hadn’t considered.
They may misunderstand something you thought was obvious.
Or they may ask a very simple question that turns out to be surprisingly difficult to answer well.
Those moments are valuable.
Every question forces you to look at the subject from another angle.
Sometimes I knew the answer immediately.
Sometimes I had to think.
And sometimes the correct answer was:
“I don’t know. Let’s test it.”
I’ve never had a problem saying that I don’t know something.
Teaching doesn’t mean that I need to have every answer.
If I don’t know, we can open the IDE and see what Java actually does. We can go back to the Study Guide. We can look for the answer somewhere else. And sometimes we do exactly that in the middle of a meeting.
I think there is something powerful about learning this way.
Instead of pretending that the person teaching has all the answers and everyone else is there just to receive them, we investigate the problem together.
That’s one of the reasons I often say that we’re not just preparing for a certification together.
We’re studying and learning Java together.
And after hundreds of hours doing that, I realized that I was learning as much from those moments as I was teaching.
The same Java concept, four different ways
Over time, I realized that I was often interacting with the same concept in several different ways.
I would read it in the Study Guide.
I would experiment with it in the IDE.
I would explain it in Portuguese in a video or weekly meeting.
And I would simplify it in English for a LinkedIn carousel.
Those weren’t four repetitions of exactly the same activity.
Each one required something different from me.
Reading required comprehension.
Coding required experimentation.
Teaching required explanation.
Creating a carousel required simplification.
And questions from the community required me to retrieve that knowledge without knowing in advance exactly what someone was going to ask.
The topic might be the same.
But my brain had to work with it differently each time.
That made the knowledge much harder to keep at the level of:
“I think I understand this.”
Teaching is not the same as knowing
There is a sentence I’ve used to describe this part of my journey:
The first time, I studied the book because I wanted to pass the exam. The second time, I studied it because I needed to teach it. And that made a huge difference.
There is an important nuance behind that sentence.
I was already teaching during my first preparation.
The summaries, weekly meetings, slides, questions, GitHub examples, and discussions were already part of the process.
What changed the second time was the level of commitment.
I had made myself responsible for teaching every one of those 94 topics.
There was nowhere to hide.
I couldn’t simply think:
“I mostly understand this one. I’ll keep going.”
Tomorrow, I had to explain it to someone else.
That responsibility changed the standard I used to decide whether I understood something.
It changed more than my certification preparation
Eventually, I realized this lesson wasn’t really about certification.
Software development requires us to explain things constantly.
Why did we choose this design?
Why does this code behave this way?
Why should we refactor this?
What is the trade-off between these two approaches?
How does this API work?
Why did this production problem happen?
When you’re mentoring another developer, reviewing a pull request, discussing architecture, writing documentation, or presenting a technical idea, knowing something yourself is only part of the job.
You also need to make that knowledge useful to someone else.
And the act of doing that often improves your own understanding.
Today, when I want to know whether I really understand a technical concept, one of the best tests I know is simple:
Can I explain it clearly to someone else?
If I can’t, there is probably still something for me to learn.
Teaching became part of how I learn
When I started the Java 21 Certification Study Group, the goal was to avoid preparing for the certification alone.
I didn’t know that the community would eventually change my own study process.
I didn’t know I would go through the Study Guide twice.
I certainly didn’t know I would end up preparing content for all 94 certification topics.
But somewhere during that process, teaching stopped being something I did after learning.
It became part of learning itself.
Read. Experiment. Explain. Get questioned. Go back. Understand better.
Then repeat.
By the time I returned to the OCP Java 21 exam, I hadn’t simply spent more time studying Java.
I had spent months explaining Java.
And that made a huge difference.
The community started as a way for us to prepare for the certification together.
But eventually, it became one of the most important parts of my own learning.
And that’s another story I’ll tell in a future article.
If you’re preparing for the OCP Java 21 certification, you don’t have to study alone.
We are now more than 500 developers in the Java 21 Certification Study Group, with weekly meetings in Portuguese and English.
Come study with us:
https://sendfox.com/ronaldotavares
OCP Java 21 Certification Journey — Article Series
#1 — 1 Java Certification in 17 Months
#2 — How I Would Prepare for the OCP Java 21 Certification Today
#3 — What I Learned From Failing the OCP Java 21 Twice
#4 — Teaching Java Changed the Way I Learned Java You are here.
Let’s Java!!!
Deixe um comentário