Questions People Ask Before They Hire Someone They Have Not Met

A role, a seniority and how many hours a week. That is genuinely enough to begin shortlisting. Everything else — the stack as it really is today, what this person would own in their first month, how much live overlap you need, who they would sit with — makes the shortlist sharper and saves a round of questions, but none of it blocks the start. You do not need a job description, a budget approval or a scheduled call. If you write us three sentences, we will come back with the two or three questions that matter rather than a form to complete.

Two or three vetted profiles within three business days of the brief. The clock starts when we have enough to shortlist against, not when the email lands, so if the brief leaves the seniority or the overlap requirement open we will ask first and start counting after. Each profile comes with the reasoning for it: why this person for this role, what they have done that is comparable, and where they would need support. If someone is a stretch in one dimension we say so on the profile rather than letting you find out in the interview.

Yes, and one developer is the most common request we get. There is no minimum headcount, no mandatory project manager and no account layer attached to the engagement. If that one developer becomes three in six months, the additional people join the same commercial arrangement rather than triggering a fresh negotiation. Equally, if one turns out to be enough, nothing obliges you to grow.

Sometimes yes, sometimes no, and we will tell you which within a day rather than stalling. Availability moves constantly because developers roll on and off engagements. If we do not have a genuine match today, the useful answer is usually a date — when someone suitable is expected to be free — or an adjacent option, such as a strong Node developer who has shipped with Fastify but not NestJS. You decide whether that trade is worth making. What you will not get is a profile stretched to fit a keyword in your brief.

Describe the problem instead of the role and we will work backwards. A queue that keeps backing up, a frontend that has become slow to change, a release process that takes a day: each of those points at a different kind of developer, and the diagnosis is often more valuable than the hire. If the symptoms are vague enough that nobody can tell which way to go, a fixed-scope code audit is usually the cheaper first step. It tells you what the codebase needs, and quite often it defines the hire for you.

No. Shortlisting, sending profiles and interviewing candidates cost you nothing. There is no retainer to see availability and no fee for a search that ends with you deciding not to hire. Charging begins when a developer starts working on your engagement, and not before. We would rather you interview three people and walk away than feel committed by a payment you made before meeting anyone.

You do. They join your standup, your board and your code review, and you set their priorities the same way you set anyone else’s. There is no account manager relaying requirements, because that layer adds a day to every decision and loses the detail that made the decision necessary. We stay involved for contracts, invoicing, replacements and anything that needs a commercial answer. If you find yourself waiting on us to pass along a technical message, tell us — that is a failure of the model, not a feature of it.

It is agreed per engagement rather than fixed, and it is one of the first things we ask about. Europe and the UK generally get near-complete overlap. US Eastern typically gets a few hours in your morning, which covers a standup and a live conversation. US Pacific is asynchronous by default, though developers do shift hours where an engagement genuinely requires live overlap and that is agreed before anyone starts. Australia and New Zealand get an afternoon overlap. Tell us the hours you actually need rather than the hours you would prefer, because it materially narrows the shortlist.

Developers take public holidays in their own country and take leave like anyone else. The expectation is reasonable notice for planned leave — usually a couple of weeks for anything longer than a day — so you can plan the sprint around it rather than discover it on a Monday. Short illness is handled the way it would be with an employee. If an absence becomes long enough to disrupt your roadmap, talk to us: depending on the engagement we can look at cover or at pausing the billing, and we would rather have that conversation early than have you absorb it silently.

Yours. The developer works in your repository, your ticket tracker, your chat and your CI, under an account you create and control. That keeps the audit trail in one place and means access ends the moment you revoke it. Give them the access the role genuinely needs rather than blanket administrator rights — production credentials in particular should follow whatever rule you apply to your own staff. If you need hardware or software licences provided from our side, say so, because it occasionally affects the rate.

Not on a full-time engagement. A full-time developer is dedicated to you for those hours and is not split across accounts, because context switching between two unfamiliar codebases produces a worse version of both. Part-time engagements are different by definition: a developer working two days a week for you will usually have other commitments, and that is disclosed up front. If exclusivity matters to you beyond the contracted hours, raise it before the engagement starts so it can be written down.

Raise it early and directly, first with the developer and then with us if it does not shift. Most communication problems are concrete and fixable: updates that arrive too late to act on, pull requests that land without context, silence when someone is blocked. Those are worth naming precisely rather than filing under a personality clash. If it genuinely cannot be fixed and you are still inside the first two weeks, the replacement guarantee covers it. After that we will still help, but it becomes a normal conversation about the engagement rather than a free swap.

You do. Intellectual property in work produced for you during the engagement vests in you, and the assignment runs through both our agreement with you and our agreement with the developer, so there is no gap where a contractor retains rights they could later assert. This covers source code, configuration, documentation and designs produced as part of the work. The exceptions are the ordinary ones: open-source components keep their own licences, and pre-existing general knowledge and technique that a developer brought with them remain theirs.

Yes, and we would rather sign one before you describe the codebase in detail. We will sign your document if your lawyers have one they prefer, or provide a mutual NDA if that is easier. Developers placed on your engagement are bound by confidentiality terms as well, so the obligation reaches the person actually reading your code and not only the company that introduced them. Assume the very first email you send is not yet covered and keep it general until the document is in place.

Neither yours nor your employee. Developers are engaged through JS Devs and work for you under that arrangement, which means there is no employment relationship between you and the developer. Payroll, taxes and statutory obligations in the developer’s own country sit with us. That distinction matters more than it sounds: it is why you can end an engagement on contractual notice rather than through a termination process, and it is also why direct-hire terms exist if you later want that relationship to change.

It happens, and it is a normal conversation rather than a trap. The agreement contains non-solicitation and direct-hire terms so that neither side is surprised, and the practical effect is that a permanent hire is negotiated with us rather than arranged quietly around us. We would rather agree a fair buyout than lose a good working relationship over it, and a developer who wants to take the offer is not going to be obstructed. The contracts page sets out the position in full.

Access should be scoped to the role, granted by you, and revocable by you. We ask clients to avoid giving blanket production access as a default and to apply the same rules they would apply to their own staff, including anything covering personal data. Where a developer will handle personal data belonging to your users, the obligations should be written into the engagement rather than assumed — tell us what regime applies to you and we will work within it. Our own website enquiry data is covered separately in the privacy policy.

You revoke access, and the developer hands over what only they know: work in progress, branches not yet merged, anything undocumented that would cost the next person a week to rediscover. We ask for that handover to be written down rather than delivered in a call, because a document survives and a conversation does not. Copies of your material held on our side are deleted, and the confidentiality obligations continue after the engagement ends rather than expiring with it.