How to use Last-Mile Java: the 15 and 30-day plans

For this lesson, we'll cover who the module is for, the order to use it in, the one test that decides whether you really know an item, and two concrete schedules: a 30-day plan and a 15-day sprint. Both are weighted by how often each area comes up in Java interviews, which is why concurrency and HashMap get far more days than design patterns. We'll finish with how to self-test, what to drop when you fall behind, and how to adjust for junior and senior loops.

01Who this module is for (and who it isn't)

This module assumes you can already write a class, use a List and a Map, throw and catch an exception, and start a thread. If those feel shaky, the plan will move too fast, and you'll be better served by 2 weeks in Java Fundamentals first. Last-Mile doesn't teach Java from zero. It turns knowledge you half-have into answers you can say cleanly under pressure.

It fits three kinds of reader well:

• The working developer with a date set. You use Spring every day but haven't thought about happens-before since university. You need the theory back, fast.
• The career switcher or new grad. You've learned Java recently and need to know which 20% of it gets asked 80% of the time.
• The senior engineer going back to market. You know the material, but you've never had to put ConcurrentHashMap internals into three spoken sentences.

Many candidates with 15 days left try to read everything once, end to end. This is frequently a mistake because one pass of 65 lessons leaves you with a vague feeling of familiarity and no answers you can actually say. Fewer topics, tested out loud and revisited three times, beat a single pass over everything.

02How to use it: checklist, then sheet, then full lesson

The module has three layers, and you move down a layer only when the one above isn't enough. The checklist tells you what to know. The revision sheet gives you the must-say facts and the why. The full lesson gives you the depth, the code and the edge cases. Picture it as a funnel: about 70 checklist items go in, and maybe 15 to 20 of them should ever need a full lesson.

The diagram below shows the loop you'll run for every item, every day.

Fig. 1

A loop of four steps: read the checklist item, try to explain it out loud in 60 seconds, read the revision sheet if you can't, open the full lesson only if the sheet isn't enough, then re-test on day 1, 3 and 7

In practice, a study day looks like this:

1. Open the checklist section for the day's area. Try each item out loud before reading anything. Tick the ones you nail.
2. Read the revision sheet for that area, focusing on the items you couldn't tick. Each sheet item has the must-say fact and 2 to 4 sentences of why.
3. Open the full lesson only for items you still can't explain after the sheet. This is where the code, diagrams and edge cases live.
4. Say it again at the end of the day, without notes. If it comes out clean, tick it.

The revision sheets are: Core Java and OOP, Exceptions, Collections and HashMap, Multithreading and the Java memory model, JVM memory and garbage collection, Java 8 to 21, Design patterns and SOLID, and The final 48 hours.

03The 60-second out-loud test

Here's the rule that decides whether an item is done: set a 60-second timer and explain it out loud, as if the interviewer had asked it a second ago. Not in your head, not by re-reading. Out loud, ideally recorded on your phone. Reading creates recognition; speaking proves recall, and only recall helps you in the room.

A good 60-second answer has four parts, and you can use them as a checklist while you listen back:

When you listen back, mark the item red if you stalled or said something wrong, amber if it was right but missing the number or the trap, and green if all four parts came out. Only green gets a tick. Expect 30 to 50% of items to start red on day 1, even for experienced engineers. That's the point of doing it.

Self-test prompts work best when they force a prediction. For example, before reading the Core Java sheet, predict the output of this:

Integer a = 127, b = 127;
Integer c = 128, d = 128;
System.out.println(a == b); // ?
System.out.println(c == d); // ?

If you can say "true, then false, because autoboxing goes through Integer.valueOf, which caches -128 to 127, so 128 gives two different objects and == compares references", that item is green.

04The 30-day plan

The 30 days split into five phases. Week 1 rebuilds the foundations interviewers open with. Week 2 covers collections and starts concurrency. Week 3 finishes concurrency and covers the JVM. Week 4 handles modern Java, design, and a second pass on your weakest area. The last two days are the final 48 hours. The timeline below shows how the days are distributed by area; notice how much of it is the dark blue concurrency band.

Fig. 2

A 30-day timeline split into five phases, with each day coloured by area: concurrency and the memory model take 7 days, collections and HashMap 5, core Java and exceptions 4, JVM and production 3, Java 8 to 21 and design patterns 2 each, a baseline day, three mock-interview days, a buffer day and two final revision days

Here's how the days add up, so you can see the weighting is deliberate:

Week-by-week goals

Week 1 (Days 1 to 7): foundations

• Run the whole checklist once and mark every item green, amber or red
• Explain pass-by-value, overloading versus overriding, and abstract class versus interface in 60 seconds each
• Explain the string pool, why String is immutable, and the equals/hashCode contract
• Draw the exception hierarchy from memory and explain checked versus unchecked with an opinion
• Explain what finally and try-with-resources do when both the body and close() throw

Week 2 (Days 8 to 14): collections and the start of concurrency

• Walk through HashMap.put and get, including resize and treeification numbers
• Explain why ConcurrentHashMap rejects null and how it locks per bin
• Explain synchronized, wait/notify and why wait sits in a while loop
• Explain happens-before and write double-checked locking with volatile from memory
• Complete mock interview 1 (core Java, exceptions, collections)

Week 3 (Days 15 to 21): concurrency depth and the JVM

• Explain the ThreadPoolExecutor task flow: core threads, queue, max threads, rejection
• Compose two async calls with CompletableFuture and handle an exception in the chain
• Explain virtual threads, carrier threads and pinning in Java 21
• Draw JVM memory areas and name the OutOfMemoryError each one throws
• Complete mock interview 2 (concurrency and JVM)

Week 4 (Days 22 to 30): modern Java, design, and the finish

• Explain map versus flatMap, lazy streams, and when Optional is the wrong tool
• Name the Java 17 and 21 features you'd use and why (records, sealed types, pattern matching)
• Write a thread-safe singleton two ways and explain SOLID with one example each
• Re-test every amber and red item from the whole checklist
• Complete mock interview 3 and the final 48-hour sheet

Day by day

"Re-test" in the last column means the spaced-repetition check from the self-test section below: say the listed items out loud again without notes.

05The 15-day sprint

With 15 days, you keep the same weighting but merge days and drop the full lessons for anything that's already amber. Concurrency still gets the biggest share (4 days), collections gets 2, and you keep two mock days and the final 48 hours. You lose the buffer, so a missed day means using the "what to skip" list below immediately rather than hoping to catch up.

Sprint goals

• Days 1 to 4: every core, exceptions and collections item at least amber
• Days 5 to 8: double-checked locking, pool parameters and happens-before said cleanly
• Day 9: mock 1 done and stumbles logged
• Days 10 to 12: JVM, modern Java and patterns at least amber
• Days 13 to 15: no red items left in concurrency or collections

06How to self-test: spaced repetition on day 1, 3 and 7

Re-reading feels productive and fades within days. Retrieval at growing intervals is what makes an answer stick, and the research on spaced practice has shown this consistently for decades. The schedule I use is simple: say each item out loud on the day you learn it, again 2 days later (day 3), and again 4 days after that (day 7). That's why the "Practise out loud" column keeps saying "Re-test day N".

Keep a tiny log, on paper or in a notes app, with one line per item: the item, the date learned, and green/amber/red at each check. Three rules make it work:

1. Re-test without notes. Open the sheet only after you've tried, to check what you missed.
2. A red at any check resets the clock. The item goes back to day 1.
3. Green on day 7 means done until the final 48 hours. Stop spending time on it.

Mock interviews are the larger version of the same idea. Get a friend, a colleague, or a recorder and a list of 10 random checklist items. Answer each as if live, then review. Mocks catch a different failure from self-tests: you know the fact, but you ramble for 3 minutes or freeze on a follow-up. Log those, and they become your re-pass list for days 26 and 27.

07Behind schedule? What to skip

You will lose a day or two. Life happens. When it does, cut in this order, from the first thing to drop to the last:

Two more rules for slippage. First, never skip a mock to catch up on reading; drop reading instead. Second, if you're more than 3 days behind on the 30-day plan, switch to the 15-day sprint from the matching day rather than trying to compress the rest.

08Adapting for junior and senior roles

The checklist is the same for everyone, but interviewers probe it at very different depths. For a junior or new-grad role, the questions stay close to definitions and small code: what's the difference, what does this print, write this method. For a senior role, every topic gets a "why" and a "what happened in production" follow-up, and concurrency and JVM questions go two levels deeper.

For a senior loop, I'd move 1 day from core OOP and 1 day from design patterns into a "production stories" day around day 20. Write each story as problem, signal, diagnosis, fix, and what you changed afterwards, and keep each one under 2 minutes spoken.

09How to say it in the interview

Everything in this module is aimed at one moment: the interviewer asks a question, and you have about a minute to show you understand it. When I ask a Java question, I'm listening for a correct definition, the mechanism underneath, one concrete number or rule, and an awareness of where it breaks. Candidates who give all four in under a minute sound senior regardless of their title.

Use the same shape for almost every answer: define, explain the mechanism, give the trade-off or number, then the trap or production angle. If the interviewer wants more, they'll ask, and you'll have room to go deeper instead of having used your time on a monologue.

Interview questions for this topicComing soon