Professional work · Full stack
AuroraJobs
Jobs and careers platform for university students, employers, and university career services. I was responsible for the application end to end, in a Ruby on Rails monolith.
- Company
- AuroraJobs
- Period
- Early 2021 — mid-2024
- Role
- Full-Stack Software Engineer
- Scope
- The whole application: the student product, the employer portal, the internal dashboard, deployments, and infrastructure.
- Status
- Finished project
Problem and context
Students looking for a first job and companies hiring junior profiles rarely meet somewhere built for that stage: general job boards treat both as one more case. AuroraJobs put jobs, training, and content around that specific moment.
Who it's forUniversity students taking their first steps, companies hiring junior profiles, and university career services.
What I owned
I built the application end to end and led product development: data modelling, backend, frontend, tests, and deployments, plus work allocation, pull-request reviews, and mentoring the other two developers.
The student product
Profiles, dynamic filters and forms for describing what they were after, job listings, and the full application flow.
The employer product
Panels showing each opening's candidates already ranked, with their video interview and the reject, save, or contact actions on the same screen.
The internal dashboard
The tool the team used to configure all of the above — filters, forms, and ranking criteria — without going through a deployment.
What else it covers
- Matching engine between students and openings.
- Analytics dashboards for university career services.
- auroraHacks, the content side: editorials, events, and a podcast.
- Deployments and product infrastructure.
Where my part ends
The tech team consisted of the CTO, two developers, and me. The CTO focused mainly on infrastructure and administrative work; I led product development, split the work, reviewed pull requests, and mentored the other two developers. Product retained the final call on scope and priorities.
Decisions
A Rails monolith instead of services
- Situation
- There were few of us, and profiles, openings, matching, applications, content, and analytics all had to be built at roughly the same time.
- What I decided
- Keep everything in a Ruby on Rails monolith, with Sidekiq for async work.
- Why
- At that team size, splitting into services would have added deployments, contracts between parts, and scattered debugging without solving any problem we actually had.
- What changed
- Data model and interface changed together, and a complete feature fit into a short cycle.
Make configurable whatever changed every week
- Situation
- Filters, student forms, and ranking criteria shifted with every product conversation. Each tweak was a development task and a deployment.
- What I decided
- Move them into the internal dashboard and let the team configure them there.
- Why
- What changes for business reasons should not have to go through me to change.
- What changed
- Product adjusted filters and forms without waiting on development, and I stopped receiving tickets that were business decisions dressed as technical work.
Split the work and review it instead of building it all
- Situation
- The product was growing faster than I could write it, and two developers joined the team.
- What I decided
- Split work by area, review their pull requests, and pair when it helped, rather than keeping the hard parts for myself.
- Why
- Hoarding the difficult work meant the team never learned the domain and I became the bottleneck.
- What changed
- All three developers could work in parallel, with their own areas and architecture decisions discussed in review. The difficult parts of the product no longer depended on one person.
Results
Product could change filters and forms without opening a development task or waiting for a deployment.
EvidenceThe internal dashboard stored the configuration used by the student product and employer portal.
The monolith shortened product cycles because modelling, backend, and interface changes could ship together.
EvidenceThe same Rails application covered data and business logic through to the interface and production.
All three developers worked in parallel and the product relied less on any one person.
EvidenceWork was split by area, with pull requests, pairing, and architecture decisions shared in review.
I led development technically while continuing to ship complete features from data modelling through to production.
EvidenceI split the work, reviewed pull requests, and mentored the other two developers while remaining hands-on.
About the numbersUser numbers, funding, and the exact scope of the infrastructure belong to the company and are not published here.
Inside
Click to enlarge
01 / 06
01The home page, with the three ways into the product: jobs, guidance, and training. 02Discover: search leads, with employers and featured courses underneath. 03The listing filters — city, field, experience, contract, on-site or remote — all configurable from inside. 04Learning: courses by category and the podcast, inside the same app. 05auroraHacks, the content side: editorials, events, and podcasts by field. 06The employer portal: ranked candidates, video interview, and the decision on one screen.