The Highlight: Visualizing Stacks, Queues, and Teaching RPN

By far the most memorable part of my FRQ journey was not just solving problems — it was building and teaching concepts through interactive systems, especially with stacks, queues, and Reverse Polish Notation (RPN).

Instead of just writing notes, I created a stack and queue visualization that allows users to actually see how these data structures work.

Why This Stood Out

Stacks and queues are usually taught as definitions:

  • Stack → Last In, First Out
  • Queue → First In, First Out

But building this made it real:

  • pushing onto a stack → visually adds to the top
  • popping → removes the most recent item
  • queues → show people entering and leaving in order

This shifted my understanding from:

memorizing definitions → actually understanding behavior

Connecting to Reverse Polish Notation (RPN)

This directly connected to one of the most important concepts I learned:

Reverse Polish Notation (RPN)

Instead of writing:

3+4 Your write 34+

This works because of stacks.

The Core Idea

  1. Read tokens left → right
  2. If number → push to stack
  3. If operator → pop 2 values
  4. Apply operation → push result

Why This Clicked for Me

Building the stack visual made RPN finally make sense:

  • I could see values being pushed
  • I could see them being popped
  • I understood why order matters (especially for subtraction/division)

This was the moment where:

Data structures stopped being memorization and became logic.

Teaching FRQs: SignedTextClass

One of the most important teaching experiences was working on:

👉 https://pages.opencodingsociety.com/csa/frqs/2025/2

This FRQ focused on SignedTextClass, which required understanding:

  • string parsing
  • condition checking
  • structured return values

What I Learned From Teaching It

Teaching forced me to think differently:

  • I had to explain why, not just how
  • I had to break down logic step-by-step
  • I had to anticipate student mistakes

Common Challenges I Helped Explain

  • misunderstanding string conditions
  • forgetting edge cases
  • incorrect return logic

Biggest Takeaway

Teaching an FRQ is harder than solving it — but that’s why it works.

Gamified Learning: How We Built Quiz-Based Lessons

Another major part of my learning was creating small gamified quizzes for FRQs and concepts.

Instead of just giving answers, we designed:

  • multiple choice questions
  • concept-based challenges
  • immediate feedback

Example Topics We Turned Into Quizzes

  • indexing (0-index vs 1-index confusion)
  • loops and arrays
  • data abstraction
  • stacks and queues

Why This Helped

Gamification made learning:

  • more engaging
  • less intimidating
  • more interactive

Instead of:

“memorize this concept”

It became:

“test yourself and learn from mistakes”

Blog — FRQ 2024 Question 2 (01/23/2026)

https://shriya1401.github.io/shriyap_2025/2025/11/05/FRQ2IPYNB_2.html

My first real FRQ attempt of the trimester. Working through a 2024 exam question under time constraints was humbling — the problem forced me to read carefully and not jump to code before I understood the structure of what was being asked.

Key takeaway: read the entire problem before writing a single line. The helper methods the exam provides are hints, not distractions.

Issue #31 — FRQ 2024 Question 3 (02/07/2026)

https://shriya1401.github.io/shriyap_2025/2025/11/05/FRQ243IPYNB_2.html

A 2016 exam question that tested string manipulation and method reuse. This is the type of FRQ where a provided helper method is designed to be called repeatedly in Part B to solve a different problem than Part A.

Key takeaway: when the exam provides a helper method, your job in Part B is almost always to call it creatively, not to rewrite its logic.

Blog — FRQ HW 4: Interfaces and Polymorphism (02/11/2026)

https://shriya1401.github.io/shriyap_2025/2025/11/05/FRQ4IPYNB_2.html

This FRQ introduced me to interface-based design in a real problem context. Key notes I documented:

Concept What I Learned
Interfaces and Polymorphism Multiple implementations work interchangeably through an interface contract
Boundary Conditions Use >= / <= carefully — exclusive vs. inclusive is a common mistake
Interface Abstraction Interfaces define what methods exist, not how they work
Encapsulation Instance variables stay private; access controlled through methods
Enhanced For-Loops Iterating over interface types enables polymorphic traversal
Short-Circuit Logic Return early once a condition is met — don’t loop unnecessarily
Naming Conventions Clear names make code self-documenting

Key takeaway: interfaces let you write code that works for any future implementation — this is one of the most powerful OOP tools in Java.

Blog — FRQ 2024 Question 1 (02/11/2026)

https://shriya1401.github.io/shriyap_2025/2025/11/05/FRQ2024IPYNB_2.html

A took an attempt at the 2024 Q1 problem, this time with more than the others confidence. Visiting an FRQ with similar concepts to one from a few weeks ago revealed gaps I didn’t know I had the first time. What felt hard previously felt manageable in February, proof that distributed practice works.

Key takeaway: returning to a similar conceptual FRQ you already “solved” is one of the highest-value study activities. You almost always find something you missed.

Blog — FRQ 2017 Q1: Digits (03/14/2026)

https://shriya1401.github.io/shriyap_2025/2025/11/05/2026v1IPYNB_2.html

The Digits FRQ required building a class that stores individual digits of an integer in an ArrayList and checks whether they form a strictly increasing sequence. My documented takeaways:

  • Constructor naming — must match the class name exactly in Java
  • Digit extraction — use num % 10 to get the last digit, num /= 10 to strip it, insert at index 0 to preserve order
  • Zero edge case — 0 must be handled separately since while (num != 0) never executes for it
  • Strictly increasing check — loop through adjacent pairs; return false immediately on the first violation
  • Loop bound — use i < digitList.size() - 1 to avoid IndexOutOfBoundsException
  • Single-digit numbers — automatically satisfy strictly increasing (no adjacent pair to violate)
public Digits(int num) {
    digitList = new ArrayList<>();
    if (num == 0) {
        digitList.add(0);
        return;
    }
    while (num != 0) {
        digitList.add(0, num % 10);
        num /= 10;
    }
}

public boolean isStrictlyIncreasing() {
    for (int i = 0; i < digitList.size() - 1; i++) {
        if (digitList.get(i) >= digitList.get(i + 1)) return false;
    }
    return true;
}

Key takeaway: the zero edge case and the size() - 1 loop bound are the two places where real exam answers lose points. Edge cases are not afterthoughts — they’re part of the solution.

Blog — FRQ Boolean Homework (03/23/2025)

https://shriya1401.github.io/shriyap_2025/2025/11/05/frq.IPYNB_2.html

My first experience working through the FRQ-2017 Digits problem, which focused on using an ArrayList to store digits and analyze patterns within a number. This problem pushed me to think carefully about edge cases and how data is built step-by-step, especially when extracting digits and preserving their order.

Key takeaway: small details like handling 0, maintaining correct order, and setting proper loop bounds (size() - 1) are where most mistakes happen — precision in edge cases is just as important as the main logic.

Patterns I Noticed Across FRQs

After working through and teaching multiple FRQs, patterns started to appear:

Pattern Example
Stack usage RPN calculator
Order matters subtraction/division in stacks
Loop traversal arrays and ArrayLists
Edge cases empty lists, single values
Helper methods reuse instead of rewriting
Condition logic SignedTextClass

What This Experience Taught Me

1. Understanding > Memorization

Visual tools and teaching made concepts stick much deeper.

2. Data Structures Are Everywhere

Stacks aren’t just for FRQs:

  • calculators
  • undo/redo systems
  • parsing expressions

3. Teaching Is the Best Way to Learn

Explaining SignedTextClass and quizzes made me realize:

if you can teach it, you truly understand it.

4. Interactive Learning Works

Gamified quizzes and visuals made difficult concepts approachable.

Final Reflection

This FRQ journey wasn’t just about preparing for an exam — it was about:

  • building tools
  • teaching others
  • understanding systems

The most memorable part wasn’t solving problems.

It was creating something where:

other people could learn from what I built.