How to Interview Contract Developers & Engineers

Last updated: September 11, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

To interview contract developers and engineers, build a short process around the statement of work and use it to answer one question, whether this person can deliver that scope in your environment starting in week one. Two conversations usually settle it, a technical discussion with the engineer they will work beside and a working session on real code, followed by a decision within 48 hours. A full-time loop answers a different question, and it runs long enough to lose the contractors worth hiring.

A medical device company in Carlsbad brought us a six-month contract last fall. They needed an Azure data engineer to move an aging SQL Server warehouse into Azure Data Factory ahead of an ERP cutover in March, and nobody was going to move March. The scope was written. The budget was approved. Then the search went into the same interview loop they use for permanent engineers.

Five rounds. A recruiter screen, the hiring manager, a 90-minute system design session, a panel of four engineers from other teams, and a closing conversation with the director about values and long-term goals. Our first finalist accepted another contract on day nine. The second went on day fourteen.

The third made it all the way to the director on day nineteen, and he asked where she saw herself in five years. She told him the truth. Her plan was his migration through March, a few weeks off, then a new contract by spring. She has run her career that way since 2017 and has never once struggled to find the next one. The feedback came back as “not a long-term fit.” She laughed about that later. On the fourth day after the rejection, the director called us back and asked if she was free. She had started somewhere else that Monday.

Every interviewer in that loop did the job well, by the standards of permanent hiring. That was the trouble. Each round was built to predict whether a person would grow with the company for three years, and the company was buying six months of one deliverable. We cut the process down to two conversations and a decision. The next finalist interviewed on a Tuesday, had an offer Thursday, and started the following Monday. That took five days. The warehouse went live eleven days before the cutover.

Most of my week goes to contract staffing searches for software, data, cloud, and QA seats, so I will say it plainly. I benefit when contract searches close faster. The advice below holds either way, and most of it works whether the contractor comes through us, through another agency, or through somebody’s former coworker.

What Your Full-Time Loop Is Built to Predict

A contract interview is a short, scope-specific evaluation of whether a contractor can deliver a defined piece of work in your environment from the first week. It does not try to predict growth, promotion potential, or culture add, because the engagement ends on a date you already picked.

Permanent loops are designed around the opposite bet. You are going to pay someone for years, train them, promote them, and hope they are still around when the system they built needs rebuilding. So the loop tests range. It asks how a candidate reasons about problems they have never seen, how they would design something from nothing, how they get along with engineers from three other teams, and where they want their career to go. Those are fair questions when the answer shapes the next five years. For a contractor they mostly measure how well somebody interviews.

Laid side by side, the two look like this. The left column is roughly what we see in the full-time engineering loops our clients run. The right column is what works on contract seats.

The last row gets underweighted. A slow decision on a permanent search costs you a candidate, maybe two. On a contract search it costs you most of the slate, because the people worth hiring are usually sitting on more than one submittal and will take the first solid offer at their rate.

They also interview constantly. Stack Overflow’s 2025 Developer Survey puts the freelance and contract share of developers at 13.9%. That’s how many of its 48,000-plus respondents work for themselves. The survey group is broader than agency W-2 contractors, and people who answer developer surveys are not a random sample of anything. Still, roughly one developer in seven sells their time in blocks, and each of them has sat through enough five-round loops to recognize one from the first calendar invite.

None of this makes the permanent loop wrong. If the seat is permanent, the four-stage structure in our technical interview guide for full-time hires is still the right tool. This page covers the other kind of seat.

Build the Interview From the Statement of Work

The most useful thing a hiring manager can bring to our first call is not the job description. It’s a paragraph describing what should exist at the end of week four that does not exist today.

“Senior .NET developer, 7+ years, Azure, microservices” tells me who to look for. “Move the claims intake service from .NET Framework 4.8 to .NET 10, containerize it for AKS, and have it running in staging behind a feature flag by the end of the first month” tells me what to ask. Every interview question worth scheduling traces back to a sentence like that second one. Most reqs don’t have one.

When a client hands me that paragraph, the interview mostly writes itself. The technical conversation turns into a walk through how the candidate would approach the migration, what they would want to look at first, and what tends to break when a Framework app meets a container for the first time. The working session uses a real slice of the claims service, or a scrubbed copy. Nobody has to invent a design prompt about a hypothetical ride-sharing app, which was never going to tell you much about claims intake anyway.

Clients who can’t write the paragraph usually aren’t ready to interview. I would much rather learn that on day one than on day nineteen.

The checking splits along a clean line. A decent agency should clear everything that can be verified from outside your building before a resume ever reaches you, which means availability, start date, rate, work authorization, whether the person has worked in your stack at the version you run, and how their last two engagements ended. On our side most of that happens before the shortlist goes out, usually within 48 hours of a clear scope. If your interviewers are spending their time on any of it, somebody upstream is not doing their part.

What’s left for your team is narrower and much harder to fake. Can this person work in this codebase? Will they work well next to this particular engineer? And what do they do when they hit something they don’t know, which on a contract happens in the first hour?

Two Conversations and a Decision

The process we recommend fits in a week. Most clients run it in three business days once the scope is on paper.

1. Write the first-month deliverable as a paragraph and send it to the agency and both interviewers before anything gets scheduled.
2. Have the agency clear availability, rate, work authorization, identity, and a reference from the last engagement before you see the resume.
3. Hold a 45-minute technical conversation between the candidate and the engineer they will work beside, built around the deliverable.
4. Run a 60- to 90-minute working session on a real piece of your system with that engineer and the hiring manager.
5. Decide within 48 hours of the working session, and give the agency specific feedback on anyone you pass on.

Notice who is missing. There’s no panel of engineers from other teams, no skip-level, no values interview with a director. A four-person panel is a good way to hold a permanent hire to a company-wide bar. On a contract it adds three people who will never work with the contractor and one more calendar to line up, and in my experience that adds about a week to every search that tries it.

The technical conversation should feel like a working meeting. The engineer describes the deliverable, the candidate asks questions, and the two of them talk through an approach. I’ve sat in on a lot of these, and you can usually tell inside fifteen minutes whether the candidate’s questions are the ones your own team would ask. Good contractors ask about the deploy process and who owns the database before they ask about anything else. Nervous ones ask about the tech stack you already listed on the req. You’ll hear the difference.

For the working session we steer clients away from whiteboard algorithms and toward something off the real backlog. A data team might hand over a dbt model that takes forty minutes to run and ask the candidate to find out why. A platform team might share a Terraform plan that fails in staging. An application team can pick a ticket the contractor would realistically pick up in week two and work it together, with the candidate driving and your engineer answering questions the way a colleague would. Scrub anything sensitive first. The point is watching how they get oriented, not whether they finish. Most don’t finish.

Then decide. When I look back at the contract finalists we have lost to other offers, most of them went in the gap between the last conversation and the answer, not during the interviews themselves. Forty-eight hours is plenty of time to decide on a six-month engagement, and a contractor who hears nothing for a week assumes the answer is no and starts somewhere else.

Engineers outside software fit the same shape. A controls engineer for a four-month line retrofit, or a mechanical designer on a capital project, gets a technical conversation with the lead engineer and a working session on real drawings or a real PLC program. Our engineering staffing desk runs those searches on the same two-conversation clock.

The Contract Questions a Permanent Loop Never Gets To

Most of your usual interview questions still work. A handful matter more on a contract than they would on a permanent hire, and a few exist only on a contract. These are the ones I’d protect if the call started running short.

“Tell me about the first two days in a codebase you didn’t write.” It’s my favorite, because the answer is a method rather than an opinion. The best one I’ve heard came from a contract Java developer we placed with an insurer in Irvine. He said he reads the CI pipeline before the code, since the pipeline shows what the team trusts, and then runs git log to find the files that changed most in the last ninety days, because that’s where the bugs and the arguments live. He was committing useful code by his second standup. Two answers make me nervous. One is “I’d read the documentation,” and there usually isn’t any. The other is “I’d ask the team,” which sounds collaborative right up until you ask what, exactly, they would ask.

Ask how their last three engagements ended. Contract resumes are strings of six-month stints by design, so “why so many jobs” tells you nothing. The endings tell you plenty. “It wrapped when the project shipped.” “They extended me twice and then the budget moved to another team.” “They converted me, and I left after a year because I missed contracting.” Each one is fine. The answer that worries me is the same vague phrase three times in a row. When I call the last manager for a reference, the question I care about most is whether they would bring the person back.

What would they need from you by Monday to be useful by Friday? Good contractors answer in specifics. Repo access and the right AWS roles, a person to ask, and one decision somebody has to make before they can start. That answer doubles as a first draft of your contractor onboarding checklist, so write it down.

Somewhere in the conversation, I want to hear about a time a client asked them to build something they thought was wrong. Contractors are paid to advise and then execute, in that order. The order matters. The strong answers describe raising the concern in writing, offering an alternative, and building what the client chose. The worrying ones either quietly built their own version or are still annoyed about it.

Handoff gets its own question. What did they leave behind at the end of their last contract, a README, a runbook, a recorded walkthrough, or nothing? A contractor who leaves nothing behind hands you a second project the day the first one ends.

I also ask directly whether they are on any other engagement right now and whether it overlaps with yours. I ask it early. Remote contractors occasionally hold two full-time contracts at once. Most won’t lie to a direct question, and the answer belongs in the agency agreement either way.

For stack-specific questions, we keep role-by-role sets, starting with our software engineer interview questions. Run them through the deliverable before you use them. A question about a technology the contractor won’t touch in six months is a question you can drop.

Identity Is Part of the Technical Screen Now

Three years ago this section would have been a footnote.

A Gartner survey of 3,000 job candidates in the second quarter of 2025 found that 6% admitted to interview fraud, either posing as someone else or having someone else pose as them. Gartner expects one in four candidate profiles worldwide to be fake by 2028. I believe it. Remote contract seats are the softest target in that picture. They are short, they come with system access on day one, and everyone involved is trying to move quickly.

The FBI’s Internet Crime Complaint Center got more specific in a July 2025 public service announcement on North Korean IT workers, who disguise their identities with help from U.S.-based facilitators, some of whom attend virtual interviews in the worker’s place. One line in it describes exactly what a contract interview has to catch. “Sometimes an individual is employed to pass the initial interview, but the on-the-job work is completed by a different individual.” I read that line twice.

The PSA’s hiring recommendations are practical enough to adopt as written. Require video, with the background unobscured. Capture images you can compare against later meetings. Verify prior employment directly with the companies listed. Grant no system access until the background check is complete. There’s also a tactic that sounds like a joke and isn’t, which is asking the person to wave a hand in front of their face, since that can make AI-generated video glitch. It feels ridiculous the first time you ask. Ask anyway.

We had a candidate for a remote Python contract this spring whose video froze every time a question left the script he had obviously prepared, and whose audio ran half a second behind his mouth. He withdrew the same afternoon we asked for a second call on camera. That is the usual ending. People running this kind of scheme would rather move on to an easier target than sit through a second look.

An agency W-2 contractor also completes an I-9 with the agency as employer and, in most arrangements, clears a background check before the start date, which is one of the quieter advantages of the structure. If you are contracting a 1099 individual or a C2C firm directly, none of that sits between you and the person, and all of the checking falls to you. Our breakdown of W-2, C2C, and 1099 contractor models covers where the rest of the risk moves.

One more habit, and it costs nothing. Put the hiring manager on the first-day video call, not just IT. The person who interviewed the contractor is the only one who can tell whether the same person showed up. IT can’t.

What to Cut, Including One Question That Can Get You Fined

You already know what the five-year question cost the Carlsbad team. Cut it. The same goes for the culture-fit panel and the skip-level conversation, which were built for a relationship that lasts years and mostly produce a longer calendar on one that lasts months.

The long take-home goes too. A mid-to-senior software contractor typically earns somewhere between $60 and $110 an hour, according to our 2026 tech contractor rate benchmarks, so a six-hour assignment asks them to hand over several hundred dollars of billable time for free. The good ones decline. A SaaS company in Costa Mesa sent a six-hour exercise to three contract candidates this spring. Two passed on it. The third returned a repository that was very obviously written by an AI coding tool, and he was the only one willing to do the assignment at all. If the exercise needs more than ninety minutes, pay for it or fold it into the working session.

Now the fine. Hiring managers sometimes ask a contractor what the agency is paying them, or what they made on their last contract. Please don’t. I keep California’s Labor Code section 432.3 bookmarked for exactly this conversation. It says an employer may not seek an applicant’s salary history “orally or in writing, personally or through an agent,” and each violation can draw a civil penalty of $100 to $10,000 from the Labor Commissioner. Other states have similar rules, and whether a client interviewing an agency’s W-2 employee counts as the employer under any of them is a question for your employment counsel, not for me. The legal question hardly matters, though, because the number you need is already in the bill rate, and the agency can walk you through what drives it.

The rest of employment law comes into the room with you, too. The EEOC’s guidance on contingent workers says that a client that rejects staffing firm workers for discriminatory reasons is liable, either as a joint employer or as a third party interferer, if it has enough employees to be covered by the statute. The contractor may not be your employee. The interview is still yours, and a question you would never ask a permanent candidate doesn’t become acceptable because the invoice comes from somebody else.

Contract-to-Hire Changes One Conversation

If the seat is contract-to-hire, some of the permanent questions come back. Only a couple, and they can wait until the technical fit is settled.

What we suggest is adding a single 30-minute conversation with the person who would manage the hire permanently, in the same week as the other two, about the permanent version of the job. What it pays on conversion. What the second year looks like. Whether the candidate even wants to convert, which you should find out now and not in month three. Plenty of excellent contractors have no interest in a permanent role, and a contract-to-hire seat is the wrong place for them.

After that, let the trial do the evaluating. The trial is better at it. Ninety days of watching someone work in your codebase, with your team, on your deadlines, tells you more than any panel could. When a KORE1 placement is still there a year on, and 92% of them are, the trial usually deserves more of the credit than the interview did. Conversion is also less common than most people assume. Our look at contract-to-hire conversion rates explains why the published numbers disagree so badly with each other.

The Pushback I Hear Most

The agency already screened them. Why interview at all?

Agencies screen what can be checked from outside your company, while only your own engineer can judge whether a contractor will be useful inside your codebase in week one.

Skipping the interview entirely does work for true coverage roles, a three-week gap on a help desk, say. For anything that touches your code or your data, one technical conversation and one working session is the minimum I’d accept, and it rarely takes more than three hours of anyone’s time.

How many interview rounds is too many for a contract role?

Three rounds is where contract searches start losing good candidates.

Two conversations, plus the agency’s screen, cover what a contract interview needs to learn. A third can be justified for contract-to-hire. A fourth can’t. Past that, every added round mostly measures a candidate’s patience, and the patient ones are not always the good ones.

Is a take-home assignment fair to ask of a contractor?

Short answer, only if it fits inside ninety minutes or you pay for the time.

Contractors bill by the hour, so an unpaid assignment has a visible price for them in a way it doesn’t for a salaried candidate. AI coding tools have also made finished take-homes much harder to read. I’ve seen three this year that the candidate couldn’t explain on the follow-up call. A live working session tells you more and costs everyone less.

Can we ask what they made on their last contract?

Ask the agency about the bill rate instead, since salary history questions are restricted in California and several other states.

The contractor’s pay history tells you nothing the bill rate doesn’t. If the rate looks high for the market, that’s a conversation with us, and we will walk you through how it was built.

Our favorite candidate says she has two other offers. Is that a bluff?

Assume the other offers are real.

Contractors with current, in-demand skills typically have several submittals out at once, and good ones get offers within days. If you like her after the working session, decide that day. Tell her so. If you need another conversation, schedule it for the next morning and tell her when the decision is coming. A specific date keeps more people in a process than any amount of enthusiasm on the call.

Should contract-to-hire candidates go through our full-time loop?

A compressed version of it, run inside the same week as the contract interviews, is usually the right call.

Add the conversation about the permanent role, and leave the rest of the evaluation to the trial period, which is the entire reason the contract-to-hire model exists. Running the complete permanent loop up front and then a ninety-day trial on top of it asks the candidate to pass the same test twice, and many strong contractors will simply decline the second one.

The Contract Is the Last Round

Most of the extra rounds I see on contract searches come from one fear, that a bad contractor will be expensive to undo. It usually isn’t. An agency assignment that isn’t working can typically be ended and backfilled far faster than a permanent hire can, with no severance and no performance plan. That protection is part of what you pay for in the bill rate, and a five-round loop is a second, slower layer of insurance against the same risk.

So let the interview be short, and let the first two weeks of the contract be the final round. Write the deliverable down first. Put the engineer who will work beside the contractor in the room. Watch them work on something real, check that the person on camera is the person who shows up, and answer within two days.

We’ve filled contract seats for technology and engineering teams since 2005, in thirty-plus metro areas now, and the average IT search here closes in 17 days. The searches that beat that number nearly always started with a written scope. If you have a contract seat open, send us the scope paragraph and we will tell you what the interview should look like before we send anyone. Most of our developer searches run through the software engineer staffing desk.