dwij in pilot

two hundred cvs.
every one says it’s a fit.
i read them.

i’m dwij, an ai agent that hires engineers for startups. i talk to every applicant, map what they’ve actually built, and bring you the ones who’ve done it, with proof. no recruiters in between. you decide who to hire.

see a sample evidence card →or book 20 minutesi’m an engineer →
pay only if you hire. no retainer.the cv, never rewritteneveryone hears why

built by Dev Ashish, co-founder and ceo, an engineer since 2018 · Codeclowns Technologies LLP, DPIIT recognised · linkedin ↗

dwij
i read your site and your open roles. my draft: real-time streaming, low latency, llm integration. go. mid. what did i get wrong?
founder
mid to senior. and the hard part: staying fast at peak, and never going silent when the model slows.
dwijgot it. that’s enough for me.
what the role needs, read from the chat
real-time streaming ★tail latency ★model fallbacks ★tenant isolationgo · preference
★ deal-breakers: streaming, tail latency, model fallbacks level: mid to senior. owns the media pipeline end to end
backend engineer, real-time voicejob post
you’ll own the pipeline that carries every call, inside 800 ms.
  • p99 under budget at 7 pm, not just at 3 am
  • audio streams with backpressure, one slow call never slows the rest
  • a smaller model takes over before the caller hears silence
written from your chat · no template
200 cvs in
results-driven full-stack engineer, passionate about scalable solutions 93% fit
rebuilt a websocket audio relay after one slow stream stalled every call 96% fit
proven track record in fast-paced environments 94% fit
self-starter delivering impactful outcomes 97% fit
ran model fallbacks for a speech-ai product in production 95% fit
dynamic developer leveraging cutting-edge technologies 93% fit
their code, where they shared it
candidate 1 · voice-relay
authored 88% · 57 commits
calls onFrame → ring.Push → asr.Send
fix shed frames past 200 ms
candidate 2 · work code is private
no public repo
so the session carries it
never held against them
questions are written from what each one actually built.
skill map session · candidate 1 · voicestage 1 of 3
dwij › at 7 pm p99 jumps to 3.2 s. the llm looks normal. where do you look?
“the relay. one slow asr stream, and everyone’s frames wait.”
dwij › right. make one slow call stop hurting the rest.
“a bounded buffer per call. drop frames older than 200 ms.”
every point hit · candidate 2 mapped the same way
candidate 1 · 2 yrs · conversational ai streaming● ● showntail latency● ● shownfallbacks● ○ understands
candidate 2 · 3 yrs · speech ai streaming○ ● thintail latency● ● shownfallbacks● ● shown
each with their quotes, an interview guide, and the cv as written
illustration i do the homework. you correct me.
how dwij works

an agent does the job. you make the call.

dwij does
writes your job post from our chat, talks to every applicant, collects cvs, builds and runs each mapping, matches people to your role, builds the evidence cards, sends you the shortlist.
you do
tell me what you’re building, once. decide who to hire.
a person at dwij
only when something might be unfair to a candidate, like an integrity flag. they talk to the candidate before anything happens.

an agent’s time doesn’t run out at the twentieth cv, so nobody is filtered out by a six-second skim. and every hire teaches it something: the rubrics are recalibrated from which answers predicted a good engineer.

chapter 1 of 7 · the chat

i do the homework. you correct me.

before i ask you anything, i read your website and your open roles, and draft what the role needs. you fix what i got wrong, tell me the hardest problem in a line, and tap what you can’t live without.

about two minutes · nothing about your architecture · scroll the chat
ddwijhiring for a voice ai startup · sample 12 min
dwiji read your site and your two open backend roles. here’s my draft of what the first hire needs. what did i get wrong? product · voice agents for bank support calls needs · real-time streaming, low latency, llm integration stack · go, python, websockets (from your job posts) level · mid
foundermostly right. make it mid to senior. they’d own the pipeline end to end.
dwijgot it. in one line: what’s the hardest thing this person will own in their first six months?
founderkeeping replies fast at peak hours. and not going silent when the model provider slows down.
dwijthat’s enough for me. which of these can’t you live without? ★ real-time streaming ★ tail latency ★ model fallbacks data isolation
founderthose three.
dwijdone. i’ll draft the post for you to approve. nothing goes out without your ok. what you tell me stays private. candidates are tested on similar situations, never on your system.
describe your product… live chat coming soon
chapter 2 of 7 · requirements

your product becomes what the role needs.

concepts, not keywords. someone who streamed video in node can stream audio in go, so i look for the idea, and treat a tool as a preference unless you say otherwise.

voice agents for bank support calls, under 800 ms
★ deal-breaker real-time streaming audio frames over websockets, with backpressure when a consumer falls behind.
★ deal-breaker tail latency p99 under budget at 7 pm, not just the average at 3 am.
★ deal-breaker model fallbacks a slow provider switches to a smaller model before the caller notices.
needed tenant isolation separate keys per bank, every transcript auditable.
preference go the language you named. python is fine. the concepts matter more.
level · mid to seniorowns the media pipeline end to end and makes buffering calls. worked out from the work, not a title.
★ three deal-breakersevery candidate is read against exactly these, in the same way.
one list, used everywherethe post, the questions and the card all come from this.
backend engineer, real-time voice bengaluru · mid to senior · sample

you’ll own the media pipeline that carries every call: audio in, transcript, model, speech out, inside 800 ms.

keep p99 under budget at 7 pm, when it currently crosses 3 seconds.from the chat: “at 7 pm, p99 goes past 3 s.”
stream audio frames with backpressure, so one slow call never slows the rest.from: real-time streaming ★
fall back to a smaller model when the provider slows, before the caller notices.from the chat: “without the caller noticing.”
go is what we run. python is fine. the concepts matter more than the language.from: preference, not a must
no template · no “rockstar” · no keyword listyours to edit
chapter 3 of 7 · job post

the post writes itself, in your words.

every line traces back to something you said. engineers read what the work actually is, so the people who reply are the ones who want it.

chapter 4 of 7 · reading the cvs

every cv says it’s a fit. i read them.

buzzwords out, claims circled, one claim followed all the way to evidence. the margin is mine.

candidatebackend engineer · 2 years · sample cv
1 of 200
summary results-driven engineer passionate about leveraging cutting-edge ai to deliver scalable, low-latency solutions.
experience backend engineer, a conversational ai startup · 2024 to now
  • rebuilt the websocket audio relay after one slow asr stream stalled every live call
  • leveraged llms and microservices to drive impactful outcomes at scale
projects voice-relay: per-call ring buffers, frame shedding past 200 ms · github
skills go, python, webrtc, kafka, kubernetes, redis, langchain, pytorch, aws, grpc, terraform
chapter 5 of 7 · their code

then i read what they built.

when they share a repo, i trace every function to the person who wrote it, follow the call path, and read the fixes. the code tells me what to ask. it never grades anyone.

no public code? that’s most engineers. their work lives in their employer’s private repos. the session carries it, and it is never held against them.
voice-relay · shared by candidate 1 · read-onlysample
who wrote what stream/relay.go88% stream/ring.go100% llm/fallback.py71% vendor/pion-webrtc0%, skipped
the call path onFrame→ ring.Push→ asr.Send ring.Push is bounded per call, and drops frames older than 200 ms
from the history a3f91c per-call ring buffer, shed frames past 200 ms 77b02e llm: fall back to the small model past 400 ms 9c1d40 readme
so i’ll ask “why drop audio frames instead of queueing them? what does the caller hear?” “walk me through a call when the model provider slows to 1.5 s.”
their walk-through is checked against the real call path. i never run their code.
chapter 6 of 7 · skill map

then i ask, out loud.

a 25 minute conversation built from their own work, on whatever they have: laptop, tablet or phone. done once, reused for every company they’re put forward to.

dwij.io/map · skill map session · sample 11:42 / 25:00
anchor 2 of 4 · real-time streaming stage 2 of 3
the situation at 7 pm, p99 jumps from 700 ms to 3.2 s. the llm traces look normal. this is from your repo:
// stream/relay.go · your commit 9e14c2 func (r *Relay) onFrame(f Frame) { r.queue.Push(f) // one queue, all calls r.asr.Send(r.queue.Pop()) }
tap a line to point at it.
dwij › what in this code lets one slow call slow down every call?
“the queue is shared… if one asr stream is slow, everyone’s frames wait behind it. i’d give each call its own bounded buffer.”live transcript
so you mean: a buffer per call, so one slow consumer can’t block the rest? yes, thatnot quite
⌨ type instead listening i don’t know
anchor 2 of 4 · real-time streamingstage 2 of 3 · 11:42
at 7 pm, p99 jumps to 3.2 s. the llm traces look normal. from your repo:
func (r *Relay) onFrame(f Frame) { r.queue.Push(f) // one queue, all calls r.asr.Send(r.queue.Pop()) }
dwij › what lets one slow call slow down every call?
“the queue is shared… i’d give each call its own bounded buffer.”
so you mean: a buffer per call, so one slow consumer can’t block the rest?yesnot quite
⌨ type i don’t know
streaming · stage 2 of 311:42
p99 jumps to 3.2 s at 7 pm. your code:
r.queue.Push(f) // all calls r.asr.Send(r.queue.Pop())
dwij › what lets one slow call slow every call?
“the queue is shared… a bounded buffer per call.”
so you mean: a buffer per call?yesnot quite
⌨ type skip hold to talk
from their own code.the situation is built on a commit they made. no question bank to rehearse. content, not fluency.in english, by voice or typing. pausing to think is fine. they see it first.their card goes to them before it goes to you. see it as the engineer does →
chapter 7 of 7 · evidence

every person i bring you comes with proof.

however many people fit the role, each one arrives with an evidence card: every requirement, two questions, the source behind each mark, an interview guide, and the cv exactly as they wrote it.

candidate 1 of 2 · 2 years at a conversational-ai startup · 30 days notice strong on streaming and tail latency, in code and in reasoning. has not yet run a model fallback in production.
what the role needsunderstandshas done itresult
“the queue was shared, so one slow asr stream stalled every call. i gave each call a bounded buffer and shed frames older than 200 ms.”
reachedstage 3 of 3sourcestaged situation · their repocodevoice-relay/stream/relay.go:41mapped3 oct 2026
sample · not a real candidate mapped 3 oct 2026 · kit v0.3
candidate 2 of 2 · 3 years at a speech-ai company · 60 days notice has run model fallbacks in production and explains them well. the streaming code in their repo, they could not explain.
what the role needsunderstandshas done itresult
their repo has a clean websocket relay with backpressure. asked what happens to frames when the consumer lags, they could not say.
codemedia-gw/ws/relay.ts:88notecode shows it, reasoning missing. often ai-assisted work not yet absorbed.mapped30 sep 2026
sample · not a real candidate mapped 30 sep 2026 · kit v0.3
tap any line to see where it came from · samples, not real candidates
how i judge

two questions. never one score.

for every requirement: do they understand it, and have they done it. a single number hides exactly the gap you need to see before the interview.

i find out through situations that unfold, code they actually wrote, and soon, an ai fluency task. the full method →
has done it →
○ ● thin 3 years in. shipped a streaming relay. couldn’t say what happens when a consumer lags.
● ● shown 2 years in. built a per-call audio buffer, and explained every line of it.
○ ○ not there said plainly. never hidden, never guessed.
● ○ understands final-year. reasons through model fallbacks clearly. hasn’t run one in production yet.
understands it →
sample candidates, placed on one requirement each
what i won’t do an agent you can trust says where it stops. these don’t change, for founders or for candidates.
  • i won’t rewrite a cv.you get it exactly as the candidate wrote it.
  • i won’t apply for anyone.i put people forward, and only after telling them where.
  • i won’t reduce a person to a score.two questions per requirement, each with its source.
  • i won’t read emotion from a voice.i mark what was said. nothing else.
  • i won’t decide who gets hired.you do. and if something looks unfair to a candidate, a person at dwij checks it before anything happens.
  • i won’t sell anyone’s data.it’s used to put people forward, and for nothing else.
questions

what founders ask first.

all questions, answered plainly →
what is dwij?

dwij is an ai agent that hires engineers for startups. it talks to every applicant, reads the work behind the cv, asks about what they have actually built, and brings you the people who have done it, each with an evidence card that shows the source behind every mark. dwij is built by Codeclowns Technologies LLP in Gurugram.

is there a recruiter behind dwij?

no. dwij is an ai agent that does the whole job itself, from the first message to the shortlist. a person at dwij only steps in when something might be unfair to a candidate, and the hiring decision is always yours.

how is dwij different from a recruiter or a job board?

a job board gives you every cv that says it fits. a recruiter gives you a shortlist and an opinion. dwij gives you evidence: for every requirement, whether the person understands it and whether they have done it, with a quote, a stage of a situation or a line of their code behind each mark. you still decide who to hire.

what does dwij cost?

you pay only when you hire someone dwij brought you. there is no retainer, no subscription and no charge per candidate. startups in the pilot get a founding rate, locked for the first year.

do i have to share my architecture or code?

no. i read what is public about your product first, then ask you about outcomes, never your architecture or your code. what you tell me about the role stays between us.

is dwij live?

dwij is in pilot with a small group of startups. some parts you read about here, like the ai fluency task, come later, and you’ll know exactly which parts are ready before you start.

the pilot

join the pilot.

dwij is being built now. a small group of startups will use it first, on founding terms.

●first access when the pilot opens. ●founding terms: pay only if you hire, rate locked for a year. ●a say in what gets built.
the dwij team will be in touch within 2 working days. privacy
Dev Ashish, co-founder and CEO of dwij
Dev Ashish co-founder and ceo Codeclowns Technologies LLP · gurugram · dpiit recognised
who’s behind me

i’m built in gurugram, by people who got tired of watching good engineers lose to good cvs.

want to talk to a person? you’ll get one.

tell me what you’re building.

i’m an engineer →
dwij
dwij is built by Codeclowns Technologies LLP · Gurugram · © 2026