Java Programming Workshops

Write code that works in production, not just in exercises

Java programming workshop session at Weknusa

Program structure

Four tracks, one clear direction

The workshops at Weknusa are structured around what Java developers actually spend their time doing — not a broad survey of topics, but focused work on specific areas where gaps tend to show up on the job.

Each track runs as a standalone unit. Participants can enter at the level that fits their current knowledge and work through assignments that get progressively harder. There is no predetermined pace — the structure is built to accommodate different speeds without sacrificing depth.

1
Core Java and Object-Oriented Design

Classes, inheritance, interfaces, generics — examined through code that has to be debugged, refactored, and justified in review.

Foundations
2
Spring Framework and REST APIs

Building services with Spring Boot, handling HTTP correctly, writing controllers and repositories that hold up under review.

Backend
3
Testing and Code Quality

JUnit, Mockito, integration tests — the track covers why code is written in a testable way, not just how to add annotations.

Quality
4
Concurrency and Performance

Thread safety, the Executor framework, profiling basics — topics that most junior developers avoid until they cause a problem.

Advanced

Participant fit

Not a general coding course

These workshops are designed for people who already have some contact with Java — through university, self-study, or a previous job — and want to move past the point where they understand the syntax but struggle with the architecture. If you have written Java code before and wondered why it was wrong in ways you could not fully explain, that is the gap this addresses.

Workshop participants working through a Java programming assignment

A strong fit if you

  • Have written Java code before — university projects, tutorials, or small scripts — and want to understand what separates that from production work.
  • Currently work in a Java environment but avoid certain areas (threading, testing, design patterns) because they feel unclear.
  • Are preparing for technical interviews and need to demonstrate that you can reason about code, not just write it.
  • Can commit 6–8 hours per week to actual work, including reading, writing, and revising code.

Likely not the right fit if you

  • Have never written a Java class before — the first track assumes you know what a method signature looks like.
  • Are looking for a course that can be finished in a few weekends without extended practice sessions.
  • Want a certificate without doing the code review assignments — feedback is built into the process, not optional.
  • Expect a fixed schedule with instructor-led video lectures at specific broadcast times.

After completion

What changes, specifically

Day 1
Readable code under review

Assignments are reviewed before they are marked complete. By the end of the first track, most participants describe reading their earlier code as uncomfortable — that reaction is a reliable indicator of progress.

Mid-point
Structured debugging habits

Instead of making changes until something works, participants develop a methodical approach: isolate, hypothesize, verify. This is not a technique taught once — it is practiced on every broken assignment.

Completion
A working portfolio project

Each participant builds a small but complete Java service across the workshop — with tests, error handling, and documentation. Something concrete to show, explain, and defend in an interview.

Getting through a workshop does not mean arriving at a fixed skill level — it means leaving with a clearer picture of where you are and what the next step looks like. Some participants move directly into new roles. Others return to their current jobs and handle responsibilities they previously passed off to colleagues.

The scope depends heavily on how much time a participant puts in. The materials support deeper engagement for those who want it — additional exercises, extended assignments, and optional reading for each topic. The minimum path gets you functional. The extended path gets you confident.

Workshop graduate working on a Java project independently

Participant accounts

Stated plainly, not summarized

These are accounts from participants who completed at least two tracks. They were asked to describe what changed in concrete terms — what they could do after that they could not do before, and what the experience of the assignments actually felt like.

No edits were made for tone. The descriptions of difficulty are included because they reflect how the material actually works — not smoothly, and not always quickly.

Daryna Kovalchuk Previously: QA engineer
Now: Junior Java developer
Track 1 + Track 3
"I had been writing test cases for other people's Java code for two years without understanding most of what I was reading. The testing track was hard because I had to write the implementation first, then test it — which meant I could not avoid the parts I had been skipping. By the third assignment I stopped asking for extensions."

Six months after completing the workshop: Moved to a developer role within the same company, working on the backend team that she had previously been testing for.

Bohdan Melnychenko Previously: Self-taught developer
Now: Mid-level backend engineer
Track 2 + Track 4
"I had built side projects in Java for about three years and felt reasonably confident until I started the Spring track. The first code review came back with seven comments. I had not expected that — I thought what I submitted was decent. Working through each comment without defending it changed how I approach feedback at work."

After the concurrency track: Was asked to take over a threading issue at his job that had been sitting unassigned for several months. He fixed it. The fix held.

Iryna Savchuk Previously: CS student
Now: Internship at a software firm
All four tracks
"University covered the theory. I knew what a thread was. I could define a design pattern. What I could not do was write a service from scratch that another developer would not need to rewrite immediately. The portfolio project is what I talked about in my interview. They asked me to walk through the architecture decisions — and I could, because I had made them and then changed them based on review."

At the point of interview: The interviewer noted that her explanation of trade-offs in her REST API design was clearer than some candidates with two years of work experience.

Weknusa Java programming workshop group session