Računarski Fakultet Beograd · Expected 2027
Software Engineering Student
Compilers, concurrency, GPU kernels — and the platforms built on top of them.
The through-line
Five areas, one habit: take systems apart, understand why they work, then build them better.
Explore areasConcurrency. Compilers. Architecture.
coursework · Collaborative university project
Tasks arrive as a JSON dependency graph. The scheduler resolves what can run now, runs those in parallel across a hand-written thread pool, and unlocks the rest as their dependencies complete.
Note 01
Tasks are declared in JSON along with what they depend on. The scheduler works out what is runnable at any moment and dispatches it — nothing is sequenced by hand, so adding a task changes the plan rather than the code.
Note 02
Worker threads, futures, locks and condition variables, built rather than called. Workers block on a condition variable instead of polling for work, which is the difference between a thread pool and a loop that happens to be threaded.
Note 03
Each task declares what it needs in CPU and memory. A task whose dependencies are satisfied still waits when the budget is spent. Cancellation runs through the same state machine, so no worker is left waiting on a task that will never finish.
personal project
Source text goes through a hand-written lexer into tokens, and a recursive-descent parser turns those tokens into an abstract syntax tree that serializes to JSON.
Why it is worth building
Recursive descent is straightforward until the error cases. Reporting a syntax error usefully means carrying accurate line and column information out of the lexer and into every node of the tree, so a message can point at the character that broke rather than at the statement that contained it.
The keyword set is Serbian beer brands. Everything behind it — the token classification, the error positions, the serialized tree — is not a joke.
The lexer emits a stream of classified tokens: keywords, identifiers, numbers, operators, punctuation and comments, each carrying its line and column.
Every cell of the grid is updated in parallel by a custom CUDA kernel. The grid size is configurable, so the same code runs at a size you can debug by eye and at one where the GPU is doing something worth doing.
A naive diffusion step reads and writes the same grid, which makes the result depend on thread scheduling. Double-buffered device memory means every read comes from the previous state, so the update is race-free by construction rather than by luck.
Device allocations persist across steps instead of being reallocated per frame, which keeps CPU–GPU traffic down to what actually has to cross the bus. On a simulation this shape, that is where the time goes.
System design carried through to working software.
Two systems where the design had to survive contact with real users, real money and real deadlines. One replaces software a client already depends on; the other exists to understand what happens when a system is split into services that can each fail on their own.
client project · In development for a higher-education client
A modular-monolith web replacement for an existing desktop student-service application, in development for a contracted higher-education client. Enrollment, courses, exams, grading, finances, documents, scheduling, notifications and reporting, across four role types.
The part that is actually hard
Not the forms. Guaranteeing that two students cannot take the same last seat in a course, that a grade cannot be silently rewritten, and that a financial operation cannot be applied twice — while multiple users act on the same rows at the same moment.
Replacing a desktop system that people already rely on sets the bar: the new one has to be at least as trustworthy as the one it removes.
A React and TypeScript client over a Spring Boot service layer, with the domain modelled in JPA and persisted to MySQL. Authorization sits in the domain model rather than at the edge, because four role types with different authority is a modelling problem, not a routing one.
Request path
Session-based authentication with CSRF protection on state-changing requests. Authorization is permission-based on top of roles, so an administrator and a head administrator differ by the permissions they hold rather than by branches scattered through the code.
The contended paths — taking a course seat, registering an exam result, applying a payment — run inside explicit transactional boundaries, with database constraints as the last line of defence. Pessimistic locking is used where two transactions genuinely cannot both proceed, and idempotency keys stop a retried request from applying an operation twice.
Integration tests run against a real MySQL container rather than an in-memory substitute, so constraint and locking behaviour is exercised as it will actually behave in production. Playwright covers the workflows end to end, and the API is validated against its OpenAPI contract so the client and server cannot drift apart silently.
Test layers
Schema changes are versioned with Flyway, the application is containerised behind nginx, and GitHub Actions runs the pipeline. CodeQL and Trivy scan the code and the image on the way through.
personal project
Five independent Spring Boot services behind one gateway, split along business boundaries rather than technical layers.
Where it gets interesting
Once a booking spans accommodation, reservations and finance, the failure modes are more interesting than the happy path. Inter-service calls go through OpenFeign with Resilience4j guarding them, so a slow or unavailable downstream service produces a handled outcome rather than a cascade.
AI products and explainable systems.
Two products and a prototype. What they share is that the model is only one part — the harder engineering is in metering expensive work, protecting what users trust you with, and explaining an output after the fact.
personal project
Recorded lectures in, transcripts and generated study material out — behind a subscription platform with credits, cloud uploads and asynchronous GPU processing.
A two-hour lecture cannot be processed inside a request, so transcription and generation run asynchronously on GPU infrastructure and the browser is free to close.
Transcripts are user data. They are stored against the account with audit logs and rate limiting around access.
Metered by a credit system, so the expensive work is accounted for exactly once per job.
Best asset for this section: a short silent screen recording (15–25s, muted, looping) of upload → transcript → generated notes. Prefer MP4 (H.264) plus a JPG poster frame.
/projects/lecture-ai/walkthrough.mp4
personal project
The same problem without the platform: a desktop tool that transcribes video in batches, on the GPU when there is one and on the CPU when there is not.
Pipeline
prototype · 1st Honorable Mention · BIO4AI Hackathon, BelBI 2026
An explainable pharmacogenomics engine that ranks antidepressant suitability from genotype and clinical context, and shows which factors produced each result.
Genes the engine reasons over
Highly polymorphic; metabolizer status shifts exposure for many antidepressants.
Drives clearance for several SSRIs, so genotype changes the effective dose.
Relevant for a narrower set of agents, with correspondingly lower evidence weight.
Pharmacogenomic reasoning does not reduce cleanly to a number. Metabolizer status interacts with concurrent medications through phenoconversion, evidence strength varies by gene–drug pair, and two rules can point in opposite directions.
So the engine keeps each contribution separate, with its provenance, and generates the explanation from the same structure that produced the order. A clinician can disagree with the reasoning rather than with a score.
Verified capabilities
Real-time rendering and interactive software.
Three games at different distances from the metal: a turn-based RPG with its rules on a Spring Boot backend, then two OpenGL worlds built around the render loop itself.
competition entry · Nordeus Challenge 2026
A turn-based boss rush where each boss has a weakness and its own mechanics, so a fight is read and adapted to rather than out-scaled.
Stack
Gameplay capture of one boss encounter, silent and looping. This section is built around a large cinematic frame, so this is the asset that carries it.
/projects/monster-trial/gameplay.mp4
Still of hero creation or the equipment screen. Also used as the reduced-motion fallback.
/projects/monster-trial/hero.png
OpenGL lab / two render paths
A networked 3D space and a 2D horror game share the same low-level graphics foundation. Choose a render path to inspect the project.
Real-time 3D first-person multiplayer application written in C with OpenGL and GLSL, networked over UDP sockets.
Every node is connected back to the centre, because every one of these taught something that shows up in the others. The full index is below.
Index
Software Engineering student at Računarski Fakultet Beograd, working across systems programming, backend engineering, GPU computing, concurrency, full-stack platforms and real-time graphics.
The projects on this site are the ones I learned the most from: a concurrent build scheduler written from its thread pool up, a programming language front end, CUDA kernels for a diffusion simulation, a university information system for a real client, and an explainable clinical decision-support prototype.
I am looking for engineering internships where the hard part is the system, not the screen.
Where the work is closest to the machine.
Domain modelling, transactions, and service boundaries.
The surface users actually touch.
How the work stays correct once it leaves my machine.
I am looking for engineering internships where the hard part is the system. Backend, infrastructure, systems programming, GPU work — or something adjacent that I have not thought of yet.