How Our Clients Pick Their Team Members

Software developers are, as a group, terrible at writing about themselves.

This is not a criticism. Nobody became an engineer because they wanted to work on their personal brand. But it creates a real problem for the person on the other side of the decision, which in this case is you, because the résumé you are picking from is usually a worse version of the person who wrote it.

Good engineers undersell themselves constantly. They write “maintained the billing system” about eight months of work that involved untangling a decade of currency-rounding bugs. The interesting part gets left out because it did not feel interesting to them, and you never find out it happened.

You are going to choose who joins your team. We would rather you choose from something accurate than from whatever an engineer managed to write about themselves at eleven at night. That is why we built Rocks, our internal system, to hold a real profile for every engineer, and hired somebody whose job is writing them.

Somebody interviews each engineer instead of handing them a form

His name is Kerr, and the thing that makes him good at this is unusual: he has a background in software development and a background in marketing.

Either one alone produces a bad profile. A marketer cannot tell which technical detail is the impressive one. They will lead with the number of users and skip the fact that somebody rebuilt the sync that was silently dropping records. An engineer writing their own profile has the opposite problem, producing something accurate, complete, and unreadable, essentially a changelog.

Kerr sits down with each engineer and pulls the stories out. What was actually hard. What broke. What they fixed that nobody asked them to.

I want to be straightforward about what this is. These profiles are marketing. They are written to present our engineers well, and I am not going to pretend otherwise. What makes them useful rather than fluffy is that they are written by somebody who can read the code, so the specifics survive contact with the marketing.

What is actually on a profile

Here is what you get instead of a two-page PDF with a skills word cloud:

• A photo and a short video, usually around ninety seconds, of the engineer talking. You hear how somebody explains things before you ever book a call.
• Skills with years attached to each one. Not a logo wall. React Native two years, Next.js one year, C# fourteen years. You can judge depth per technology rather than guessing.
• Project narratives that name real work. One of our engineers has a profile describing the HubSpot Closed Won integration they built, the invoice-number generation they reworked to kill duplicates, and the timezone bug they chased down that was corrupting payroll hours. That is checkable. “Worked on a client portal” is not.
• Availability, shown plainly.
• Surnames reduced to an initial, because a public profile does not need to be a doxxing surface.

A bench is not one kind of person

The reason we show profiles rather than describing our engineers in the abstract is that the abstract version is always wrong. Three of ours, all real:

One is a full-stack developer about a year into their career. They came in through our Fast Track internship, worked through three escalating projects, finished the internship with a perfect evaluation, and now own client portal integrations and financial features on a live product.

Another is a senior full-stack developer with twelve years of PHP, who has shipped across property management, apartment software, and CRM systems, and lists twenty-six skills.

The third is a senior .NET developer with fourteen years of C# who has led teams of three to eight developers across offshore and onshore projects, and who has been with us since November 2019.

Those three people are not interchangeable, and no amount of prose about our “rigorous vetting process” would tell you which one belongs on your team. The profiles do that work in about ninety seconds each.

One more thing you might notice comparing them: the skills lists are not the same length. One lists twenty-six, another lists nine. We do not pad them. A profile lists what somebody actually works in, not everything they have opened once.

Profiles get rebuilt on two triggers

A profile that is eighteen months stale is worse than no profile, because it is confidently wrong.

Ours get updated when somebody is hired, and again when a client engagement ends and that engineer becomes available. The second trigger is the one that matters, because it is what keeps the availability accurate and what makes sure the last two years of work actually show up before anyone sees the profile again.

Clients can browse the whole bench, but we would rather not make you

Once you are a client, you can log into Rocks and look through everyone available. Some clients like that and go through it themselves.

Most would rather not, and honestly they are right. Reviewing a bench is the part we are supposed to do for you. You have a role to fill and a product to ship, and reading forty profiles to find three is a bad use of a CTO’s afternoon.

The default is a shortlist instead. You tell us what you need, we come back with a small number of people we think fit, with profiles attached, and you take it from there.

How the shortlist actually gets built

Two layers, one machine and one human.

We built our own MCP server against Rocks, so our sales team can query the bench through Claude Cowork in plain language. That matters more than it sounds. A dropdown filter can answer “who knows React.” It cannot answer “who has shipped a payments integration in a regulated industry and would be comfortable being the only engineer on a call with a non-technical founder.” Those are the questions that actually decide a match, and they are the ones we can now ask directly.

The second layer is people. Our engineering leaders meet with the engineers on the bench, so somebody has genuinely sat with these people recently. A profile tells you what somebody has done. An engineering lead who talked to them last week can tell you what they would be good at next, which is a different question and usually the more useful one.

We run mock interviews, because being good at the job is a different skill

Here is something most vendors would not admit.

A lot of our engineers are not very good at client interviews. Not because they are not good engineers, but because somebody who has spent three years heads-down on one client’s codebase has not interviewed since the last decade started. That skill decays. It decays for everybody.

So we run mock interviews with people on the bench. We practice talking through past projects out loud, which is harder than it sounds when the work is three years back. We practice not disappearing into implementation detail when somebody asks a simple question.

None of this is about coaching anyone to say the right thing. It is about making sure a nervous forty minutes does not misrepresent seven good years.

You still interview them

The profile is not the decision. It narrows a bench of hundreds down to two or three people worth an hour of your time, and then you make the call.

We would not want it any other way, because we cannot tell from our side whether somebody will click with your team. I have written before about why an interview cannot fully predict fit, and that is exactly why the first two weeks come with a money-back guarantee. The profile reduces the guesswork. The interview settles the shortlist. The first two weeks tell you the truth.

Ask a vendor to show you a person

The industry standard is to describe engineers in the abstract, with the same three phrases every time: rigorously vetted, top one percent, senior talent.

None of that is checkable, and all of it is what a vendor says when they do not want you looking too closely at who you would actually get.

If you want to see what your team could look like, schedule a call and we will send you real profiles of real people who are available now.