My work at Torre covered how people were found, how their experience was presented, and how the team checked the quality of AI results. I built sitemap improvements and AI-assisted profile features, made matching explanations easier to inspect, and worked on evaluation, tracing, and product measurement.
Torre is a hiring platform. People need to find relevant jobs and candidates, then understand whether the experience fits the opening.
01 / Sitemaps & discovery
I made the sitemap reflect the pages worth finding.
The sitemap work started with a mismatch: many submitted pages were not useful search results, while worthwhile profiles were hard to find. Careers pages also needed to stop advertising jobs after hiring had closed.
MY CONTRIBUTION
I built updates for profile, company, and careers sitemaps. Each served a different purpose, so I kept their inclusion rules separate and connected updates to changes in the underlying content.
THE IDEA, ILLUSTRATED
A page becomes discoverable
FROM A USEFUL PAGE TO A DISCOVERABLE URL
/alex
AO
Alex Okafor
Software engineer
Career profile
3projects
PublicPage visibility
Public
sitemap.xml
FOR SEARCH ENGINES
Pages to discover.
URL DIRECTORY3 entries
/maya
/alexIncluded
/jordan
Ready for crawler discovery
PAGE VISIBILITY
Only public pages belong in the sitemap
Public pages enter the sitemap so search engines can find them. Private pages stay out of the list.
How discovery works
A sitemap gives search engines a list of pages to discover. It helps crawlers find content, but does not guarantee indexing. Page access controls remain separate from sitemap inclusion.
When a page becomes public, its URL enters the sitemap. When it becomes private, the URL leaves. Search engines get a list that follows the content.
THE DECISION
Coverage or relevance?
A longer sitemap could still send a search engine to empty or outdated pages. I focused on useful coverage and kept existing listings current through events and cache invalidation. An update needed to change the relevant listing without rebuilding every directory.
WHAT CHANGED
Profile indexing improved. Careers listings became more selective, removing pages that no longer reflected active hiring. For that part of the work, fewer submitted pages was a useful result.
Google-indexed pages
+1,700%Growth in indexed candidate and company pages after the sitemap improvements.
I brought relevant experience forward without changing the facts.
A person’s experience can suit an opening without that connection being obvious in a general profile. I worked on making the introduction and experience descriptions more relevant to the role, while keeping the original career history intact.
MY CONTRIBUTION
I built the generation and presentation features, including structured model output, factual checks, and a tailored résumé view. The original profile remained available while background work prepared the new version.
THE IDEA, ILLUSTRATED
Bring relevant experience into view
ao
Alex OkaforSoftware engineer
Tailoring forPlatform engineer
Before
“I work across onboarding, inventory tools and product data.”
01
Customer onboardingProduct experiments
02
Backend APIsInventory tools
03
Background jobsProduct-data sync
After · tailored introduction
I build backend APIs and background jobsfor inventory and product data.
010203 All experience kept
The right experience, brought forward.
The tailored introduction brings relevant experience forward from the original profile. The emphasis changes; the qualifications stay the same.
THE DECISION
A useful rewrite still has to be true.
The model could borrow a skill from the job description that the candidate had never claimed. Checks had to preserve titles, figures, and supporting experience. There was also a waiting problem: I used priority queues and concurrency control so a profile being opened could take the next available generation slot.
WHAT CHANGED
The profile experiment showed more reviewed candidates progressing to a conversation. The work improved how experience was presented and tested that change against what people did next.
Candidate shortlists
+22%Increase in recruiter shortlists in profile-optimization experiments.
Candidate rejections
−20%Reduction observed in the profile-optimization experiments.
A production model was being deprecated, and its replacement threatened a threefold cost increase. I needed to compare alternatives without trading away quality: fluent answers could still invent a qualification, change a job title, or omit useful experience.
MY CONTRIBUTION
I evaluated three LLM providers through blind cross-judging against the same source examples, checked outputs against explicit criteria, and investigated the failures behind the scores. I revised prompts and repeated the comparisons for profile content and screening questions.
THE IDEA, ILLUSTRATED
Compare answers against evidence
01Same source
02Two answers
03Cross-judge
04Revise prompt
05Score again
CANDIDATE PROFILE · SOURCE OF TRUTH
Built inventory & invoicing APIs with Node.js.
Job asks for Kubernetes. The candidate’s experience does not include it.
Model AREVISED ANSWERModel BJUDGES
I build inventory & invoicing APIs with KubernetesNode.js.
0→2/ 2Grounded claims
Unsupported skill removed. Source fact restored.
Model BREVISED ANSWERModel AJUDGES
I build inventory & invoicing APIs with Node.js.
0→2/ 2Preserved experience
The candidate’s actual work is visible again.
Neither model grades itself.
The revised answers restore Node.js and the missing inventory and invoicing work. Both criterion scores move from zero to two. Scores still need an evidence check.
How the scoring works
Each answer is checked for two things: whether its claims are supported, and whether it preserves relevant experience. A score of 0 fails the check, 1 partially meets it, and 2 meets it.
Both answers are checked against the same profile. One adds a skill the candidate never claimed; the other drops relevant experience. Revising the prompt addresses both mistakes, then the answers are scored again.
THE DECISION
A higher score was not enough.
The evaluations exposed a tension between preventing invention and preserving useful source material. A stricter instruction could remove content it should have kept. Cross-model judging provided another perspective, but I still checked the evidence and used deterministic validation for rules with a definite answer.
WHAT CHANGED
I shipped the highest-performing integration from the comparison. It delivered 43% higher evaluation quality at 23% lower model cost. The process also exposed prompt failures that I could correct and test again.
Evaluation quality
+43%Quality improvement from the selected model integration after comparing three LLM providers.
Model cost
−23%Lower cost for the selected integration in the model comparison.
I made the reasons behind a match available to inspect.
A score can suggest that someone fits a role without explaining why. The person reviewing it needs to see which requirement is supported, which conflicts with the profile, and which cannot yet be answered.
MY CONTRIBUTION
I brought those explanations into candidate and job views, linked skills to supporting experience, and worked on consistent information across the screens. Shared components kept the same matching concepts from being presented differently in each place.
THE IDEA, ILLUSTRATED
Open the reasoning behind a result
MATCH & RANK · OPEN THE REASON
From a verdict to the evidence.
THE OPENING NEEDSBuild backend servicesPlatform engineer
ALEX’S PROFILE
Built an inventory API and background jobs to sync product records.
Experience 01 + 02
MatchRelevant work supports this requirement.
Each factor connects a job requirement to the candidate’s experience.
A job requirement is paired with the experience that supports it. Other factors reveal a mismatch or a question that still needs an answer.
THE DECISION
Missing evidence is different from a mismatch.
A simpler display would have been misleading if it flattened every factor into yes or no. The work preserved match, mismatch, and unknown states, then let people inspect the evidence without making them read everything at once.
WHAT CHANGED
People could move from a verdict to the reason and the experience behind it. The interface made uncertainty visible and reduced conflicting presentations of the same candidate.
Tools & engineeringVue, TypeScript & shared components · API contracts & data consistency · Evidence attribution
The skills behind the work
Vue, TypeScript & shared components
Bring explanations into product views without duplicating their behavior.
API contracts & data consistency
Keep the meaning of candidate information aligned across services and screens.
Evidence attribution
Connect a skill or claim to the experience that supports it.
I gave the team more to investigate than a failed result.
Once AI features were in use, a disappointing result could come from several places. A model call, a search result, and a dashboard count each needed different evidence before the team could decide what to fix.
MY CONTRIBUTION
I added model tracing, connected product events to their search context, and worked on SQL definitions for candidate metrics. I also built the integration that sent search context and displayed results to the team’s n8n review workflow.
THE IDEA, ILLUSTRATED
Make the path of a request inspectable
01 / MODEL BEHAVIOR
The failure leaves a trail.
One request. Every model attempt.
request / demo-1042Generation trace
STARTATTEMPTSEND
Generation · attempt 1
The failed provider attempt stays visible, including its exception.
The first attempt fails; the fallback succeeds. Keeping both in the trace reveals a failure that the final response alone would hide.
THE DECISION
Capture the right context without blocking the user.
The review team needed the result the user actually saw. I worked on carrying that context into the review handoff while keeping a delivery failure from interrupting search. For metrics, I checked what each count represented and kept incomplete periods from distorting comparisons.
WHAT CHANGED
Engineers could inspect model failures and timing. Reviewers received search context to investigate, and product reporting used clearer definitions for the activity being measured.
I followed interrupted work across the browser and backend.
Some of my work was in existing features: searches that needed recovery, résumé imports that stopped too early, media that would not upload, and messages that needed to reach the right conversation.
MY CONTRIBUTION
I traced those failures across their callers and services, then made focused changes to recovery, media handling, imported data, and messaging. I also corrected a service-client lifecycle problem that could exhaust resources.
THE IDEA, ILLUSTRATED
Keep the experience moving while work waits
PRIORITY GENERATION
Keep reviewing. AI catches up.
AO
Alex OkaforSoftware engineer · original profile
Open throughout
WaitingGenerating
Background job
Background job
Finishing a job
Already running
Already running
Alex + this roleOpened now · goes next
Alex + this roleOpened again → same job
The person you’re reviewing goes next.Running jobs finish; waiting background work follows.
A queue holds work until a worker can handle it. The user can keep moving while processing continues in the background.
THE DECISION
Fix the failure at the place that owns it.
A retry is useful when a dependency fails temporarily; it cannot repair an incorrect data merge or a client created too often. The investigation mattered because each symptom needed a different correction, with existing user progress preserved where possible.
WHAT CHANGED
Those changes repaired specific interruptions in applying, searching, and communicating. They also reduced unnecessary resource use in an existing integration.
At Torre, my work crossed backend services, AI evaluation, and the screens people used to make hiring decisions. Following a change through those layers helped me catch problems that were easy to miss in isolation.
“Not just using AI but keeping a critical mindset in order to get the best out of it.”