Your Project
The five opening questions. These always come first, so get them smooth.
Tell me about your current project.
What it does → who uses it → what you built. 60 seconds, then stop.
EvoloConnect is my own product — a vehicle safety platform. There's a QR sticker on the car,
and if something's wrong, anyone can scan it and alert the owner without seeing the owner's
phone number. I built all of it: the ASP.NET Core APIs, the React portal, the React Native app,
and the alert flow — push notification first, then SMS, then a voice call.
For seven years I worked on a workforce management platform for a Sydney client, used by
contact centres in Australia, the US and Europe — staff scheduling, real-time adherence and
forecasting. The platform already existed when I joined. I owned the scheduling and adherence
modules.
Don't open with the technology list. That comes later, if they ask.
Lead with the problem and its cost. No technology in this answer.
A contact centre lives or dies on having the right number of people at the right time. Too
many and you're paying salaries you don't need; too few and calls queue and service levels
break. The platform forecasts demand, builds the schedules, and shows in real time whether
people are doing what the schedule says.
EvoloConnect version: people write their number on the dashboard or can't be reached at all. This gives contact without exposing anyone's number.
Explain your architecture.
Clean Architecture (also called Onion or layered). Business rules sit in
the middle and know nothing about the database or the web.
It's Clean Architecture. The centre is the domain — pure C# entities, no EF, no packages.
Around it the application layer holds the business rules and only talks to interfaces. The API
layer takes the request and returns JSON, no logic there. Infrastructure on the outside has the
real implementations — EF Core, repositories, push and email. Dependencies point inwards only,
so the business logic doesn't know the database exists.
| Why you chose it |
|---|
| One backend serves two portals, two mobile apps and a public page — rules written once |
| Swapping the database or the push provider only changes Infrastructure |
| Business logic can be tested with fake repositories — no database needed |
"Why not simple 3-tier?" — It is, but with dependencies inverted. In 3-tier
the business layer references the data layer; here it only defines interfaces.
"Why no MediatR/CQRS?" — Single product team. It would add indirection
without a real benefit. The architecture allows it later.
"What would you improve?" — Redis on the public
scan endpoint, Hangfire for the background jobs, integration tests on payments.
What is your role?
Never claim you designed the Call Design platform. Learn this word for word:
The platform already existed when I joined. I owned the
scheduling and adherence modules — the APIs, the React screens and the stored procedures behind
them.
| Safe to say | Don't say |
|---|---|
| "I owned the scheduling module end to end" | "I designed the platform" |
| "I chose how to model that data" | "I chose the architecture" |
| "I was on call for the areas I owned" | "I led the team" |
EvoloConnect is different — it's your product, so claim all of it: database, APIs, web portal, mobile app, release.
Stand-up first, and an overlap call with the Sydney client. Then the story I'm on — usually
the API and the React screen together so the feature is finished, not half-done. I review other
people's pull requests during the day, and anything production threw up overnight comes
first.
Make sure code reviews and production ownership are in there — those two are what separate senior from mid-level.
Know your own words
You say I owned the scheduling and adherence modules
. If they ask what
adherence is and you hesitate, that's worse than never mentioning it. Two sentences is
all you need.
Adherence
Did the agent actually do what the schedule said, at the time it said?
| Time | Scheduled to be |
|---|---|
| 09:00–11:00 | On calls |
| 11:00–11:15 | Break |
| 11:15–13:00 | On calls |
The phone system says what she was actually doing. Back from break at 11:25 instead of 11:15 = 10 minutes out of adherence. Over a day it becomes a percentage — "94% adherent".
Why the business cares: the forecast says 40 people are needed on calls at 11:15. If ten are still on break, calls queue and the service level breaks — even though the schedule was right. Real-time adherence is the live screen a team leader watches so they can act in the moment instead of reading about it tomorrow.
Adherence compares what an agent actually did against what their schedule said they should be
doing, and scores it as a percentage. We took agent state events from the telephony system,
matched them against the published schedule, and drove a real-time screen team leaders watch — so
if people are late back from break while calls are queuing, they can act on it
immediately.
The stale data in Q9 was this — agent state events stopped flowing, so the live screen showed six-hour-old numbers while managers made staffing decisions off them. That's why it mattered.
The other words you may hear
| Term | Means |
|---|---|
| Adherence | Right thing at the right time |
| Conformance | Right total hours worked — not the same thing |
| Shrinkage | Time paid but not on calls — breaks, training, meetings, sickness |
| Occupancy | How much of their available time was spent handling contacts |
| AHT | Average handle time per call |
| Service level | e.g. "80% of calls answered within 20 seconds" |
| Forecasting | Predicting call volume so you know how many people to schedule |
| ACD | The phone system that routes calls and reports agent state |