Certification is the floor, not the bar
Anyone can pass a multiple-choice exam. The question that matters is whether this engineer has taken something like your system into production and kept it running afterwards.
- Stage 1
- Referral or direct sourcing
- Stage 2
- Credential verification at source
- Stage 3
- Architecture-led technical screen
- Stage 4
- Two references from managers or buyers
- Ongoing
- Delivery feedback recorded per engagement
- Re-verification
- On credential expiry
Every CloudOps Network engineer passes four stages before appearing on a shortlist: they are sourced by referral rather than open application, their certifications are verified at the issuing source, they complete an architecture-led technical screen on work they actually shipped, and two references are taken from people who managed or paid for that work.
The four stages
Sourced, not self-listed
Engineers arrive through referrals from people already in the network, or through direct sourcing. There is no open application form on this website for a reason: cold traffic produces volume, not quality.
Credentials verified at source
We confirm cloud certifications with the issuer. Where a role calls for Kubernetes, security or data credentials, those are checked the same way. A PDF in an email is not verification.
Technical screen on real systems
A working engineer walks through something the candidate built: why that architecture, what broke, what they would do differently. We are listening for judgement under constraint, not recall.
References from people who paid
Two references, taken from the person who managed the engagement or signed the invoice. We ask what went wrong as well as what went right, and we write the answer down.
What the screen is looking for
Most technical screens test whether someone can produce a correct answer. Ours tests whether they can produce a defensible one, then explain the trade-off they accepted and the failure mode they were watching for.
That matters because contract engineers inherit systems they did not design, under constraints they did not choose, with a deadline someone else set.
Judgement under constraint
Can they explain why the elegant option was wrong here?
Failure literacy
Do they know how the thing they built degrades, and what they instrumented for it?
Handover discipline
Is there documentation, or is the knowledge only in their head?
Client legibility
Can they explain the decision to someone who does not write code?
Vetting questions
What certifications do you verify?
Cloud provider certifications at associate, professional and specialty level, plus Kubernetes, security and data credentials where they apply to the role. We verify them at the issuing source.
Is certification enough to get into the network?
No. Certification is a floor. The decision is made on the technical screen and references, which are about work that actually shipped.
How many applicants get in?
A minority. The network is invite-led and the screen is designed to remove people rather than to include them.
Do you re-check engineers over time?
Yes. Credentials are re-verified on expiry, and delivery feedback from each engagement is recorded against the engineer's record.
What happens if an engineer underperforms?
The delivery lead raises it, the engineer is replaced if the client wants a replacement, and the record follows the engineer. Repeated issues end network membership.
Tell us what you are building
Describe the work in a few lines. We come back with a shortlist of engineers who have done it before, their availability, and a rate range. No account, no platform fee, no obligation to hire.
Most briefs get a shortlist within three business days.