← Home

How to write an engineering requirement that a supplier can actually fill

Written by HookStep. Last updated .

Most of the delay in hiring a contract engineer happens before anyone is interviewed: the supplier reads a requirement, guesses at what it leaves out, and sends profiles that miss. This guide lists what a requirement should state, why each item changes who gets put forward, and what was missing from the requirements other companies sent HookStep in September and October 2026.

Share your requirement

  • State the outcome, not just the stack: what the engineer will have built or fixed after three months.
  • Give one budget figure or a range, say whether it is per month or per year, and say whether GST is on top.
  • Say the engagement type (contract, contract-to-hire or permanent), the term, the work mode and city, and the hours that must overlap with your team.
  • Separate the two or three skills you will reject a profile for from the ones that are nice to have.
  • Say who interviews, how many rounds there are, and how soon someone has to start.

A supplier matches a requirement against people it already knows and then sources for the gaps. Every field you leave blank is filled with an assumption, and the assumption is usually the one that makes the role easiest to fill: a lower seniority, a wider budget, remote instead of on-site. The profiles that come back reflect that guess, you reject them, and a week is gone.

The opposite also happens. A requirement that lists twelve tools as mandatory looks precise, but almost nobody has all twelve, so the supplier either sends nobody or quietly decides which six you really meant. Saying which ones you would reject a profile for is what makes a requirement precise.

  • Role and outcome. "Senior data engineer" says little. "Move our nightly batch jobs from on-premise SQL Server to Databricks and own them afterwards" tells a supplier who has done that before.
  • Seniority as years and as scope. Years of experience is the common filter, but also say what the person will own: a module, a service, a team of three.
  • Must-have skills, at most three. These are the ones you would reject a profile for. Everything else goes under nice to have.
  • Budget. One figure or a range, per month for contract roles or per year (CTC) for permanent roles, and whether GST is added on top. If the budget is fixed upstream and cannot move, say so; it saves a negotiation that cannot succeed.
  • Engagement type. Contract, contract-to-hire, or permanent placement. For contract-to-hire, say roughly when you expect to decide on conversion.
  • Term. Three months, six months extendable, one year minimum. A supplier puts forward different people for a three-month fix than for a one-year build.
  • Work mode and place. Remote, hybrid or on-site, the city, and how many days a week in the office.
  • Hours. Indian Standard Time is UTC+5:30. If the role needs overlap with US or European hours, give the exact window, for example 2 pm to 11 pm IST.
  • Payroll. Whether the engineer stays on the supplier's payroll and is invoiced monthly (corp-to-corp), or moves to yours or your staffing partner's payroll for the contract.
  • Process and start date. Who interviews, how many rounds, whether there is a take-home task, and the latest start date that still works.

Our guide to IT staffing rates lists 24 contract requirements (29 roles) that staffing firms and IT companies sent us between 18 September and 21 October 2026. Every one stated a budget, which is better than most job posts manage. The gaps were elsewhere.

Only 6 of the 24 stated a term, such as six months extendable or a one-year minimum. Only 6 said whether GST was on top of the monthly figure, so for the other 18 a supplier had to ask before it could quote. Two did not state the experience required, and one did not say where or how the person would work.

None of those gaps stopped a role from being filled, but each one cost a round of questions and answers before the first profile could go out. It is the same reason we ask employers who use our own form for the stack, seniority, time zone overlap, budget and engagement type up front.

  • A budget with no unit. "1.3" could be lakh a month or lakh a year; "₹15 lakh" could be CTC or the cost of a contract. Write the unit every time.
  • Hours that are implied. "US client" does not say whether the engineer works US hours, overlaps for two hours, or never speaks to the client. Give the window.
  • Copying the previous person's CV into the requirement. The new hire will not have the same career, and the supplier will send people who match the old CV, not the work.
  • A start date of "immediate" with no fallback. Many employed engineers in India have to serve a notice period before they can join. Say what happens if the best person can start in six weeks rather than one.

Senior backend engineer, contract, six months extendable. Build and own the payment reconciliation service we are splitting out of our monolith. Must have: Java with Spring Boot, PostgreSQL, and having run a service in production on AWS. Nice to have: Kafka. 6 to 9 years. Budget ₹1.5 lakh a month plus GST, on the supplier's payroll. Remote from India, with 10 am to 2 pm UK time overlap. Two interviews (technical, then the engineering manager), no take-home. Start by 1 December; we can wait four weeks longer for the right person.

That is about 90 words, and a supplier can match against every line of it.

HookStep's own records: the 24 contract requirements (29 roles) that staffing firms, IT services companies and intermediaries sent us between 18 September and 21 October 2026, the same set as on /learn/it-staffing-rates-india. The example requirement is written for this guide and is not a real role.

Should I publish the budget in an engineering requirement?

To a supplier, yes. Without it the supplier guesses, and the profiles that come back are either over or under what you can pay. Every one of the 24 contract requirements we analysed stated a budget.

How many must-have skills should a requirement list?

Two or three: the ones you would reject a profile for. Put the rest under nice to have, so a supplier does not discard a strong engineer for missing a tool they could learn in a week.

What is the difference between corp-to-corp and payroll contracts?

Corp-to-corp means the engineer stays on the supplier's payroll and the supplier invoices you each month. On a payroll contract, the engineer joins your payroll, or your staffing partner's, for the contract. The same monthly figure covers different costs in each case, so say which one you mean.

Hiring now? Tell us about the role, read how it works, or see the FAQ.