Work on the whole problem, not a slice of it

• Build features in React and TypeScript, and the Node services behind them. Usually both halves of the same feature in the same week.
• Write the migration, run it against staging, and be the person who runs it in production.
• Sit in the scoping call and say what you think the work will really take. That estimate is yours to defend and yours to revise out loud when it changes.
• Review two or three pull requests a day, and take review on your own without treating it as a verdict.
• Fix the bug you shipped. Support rotates, but nobody hands their own defects to the next person.
• Answer the client directly when they ask why a page got slower, and answer it with a measurement.

• Three years or more building web applications that real people used. Coursework and side projects are not the same thing.
• React and TypeScript day to day. You should be able to read a component you did not write and say why it re-renders.
• Node on the server, and enough SQL to write a join and read a query plan without opening a tab.
• You have deployed something to AWS or Azure yourself, even if somebody else set up the account.

Nice to have

• Next.js, and an opinion about when server rendering earns its cost.
• Agency or consultancy experience, where requirements move after the estimate.
• You have mentored a junior developer and enjoyed it.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A CV and a link to code you wrote: a repository, a published package, a merged pull request in something public. If none of that exists, a short note on the hardest bug you have fixed and how you found it does the same job.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Competitive salary and equity
• Health insurance
• Flexible work hours
• Professional development budget

• Design screens in Figma and then sit with the engineer building them the same week, not two sprints later.
• Run the design system on a client product: components, states, and the rule for when a new component is justified.
• Turn a vague brief into two or three options with the trade-offs written next to them, and present those options to the client yourself.
• Specify the empty state, the error state, and the loading state. Those are the screens that get skipped, and they are the ones users hit on a bad day.
• Watch a handful of people use the prototype, then change the design based on what they did rather than what they said.
• Check the built interface against the design, raise the differences that matter, and let go of the two pixels that do not.

• Two years or more designing web and mobile interfaces that shipped and stayed shipped.
• Figma to a professional standard: components, variants, auto layout, and a file another designer can pick up without ringing you.
• A portfolio with the reasoning in it. One project explained properly beats twelve screenshots.
• Enough HTML and CSS to know what you are asking an engineer to build.

Nice to have

• Motion and prototyping work.
• Accessibility practice: contrast, focus order, and a keyboard path through the whole flow.
• You have designed for a training or education product.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A portfolio link and one project walked through in your own words: what the brief was, what you tried first, what you changed after someone used it. Password-protected client work is fine, send the password.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Creative freedom
• Latest design tools
• Collaborative environment
• Remote work options

• Own build, test, and release for client projects. Defined in code, reviewed like any other change, and boring by design.
• Take a new environment from nothing to running with one command, then keep that command true a year later.
• Set the alerting up, then answer the alerts. If something pages a person at 3am and did not need to, fixing the alert is the work.
• Move a client off a hand-built server onto something reproducible, without asking for a weekend of downtime.
• Find the cloud spend that is genuinely wasted, cut it, and say plainly which part is not worth cutting.
• Write the runbook so the next person does not have to ask you.

• Three years or more running production infrastructure that you were on call for.
• AWS, Azure, or GCP in depth. One of them properly is worth more here than three of them vaguely.
• Docker, and Kubernetes where the workload justifies it. Knowing when it does not counts just as much.
• Infrastructure as code, Terraform preferred, plus CI configuration you wrote rather than inherited.

Nice to have

• Security work: secret handling, least privilege, a patching routine that survives contact with a deadline.
• Database operations, including a restore you have actually tested.
• You have taught cloud or DevOps to people starting from zero.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A CV plus a short description of one system you are responsible for: what it runs on, what broke, and what you changed so it stopped breaking. Terraform or pipeline config we can read is better than a certification list.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Ownership of the deploy pipeline
• Learning opportunities
• Flexible schedule
• Relocation assistance

• Sit in the client call, then write down what was agreed, including the part nobody wanted to say out loud.
• Keep one ordered list per project and defend that order to the client and to the team, using the same reasons for both.
• Write acceptance criteria before build starts, so QA is not guessing and the developer is not inventing.
• Cut scope when the estimate and the date disagree, and tell the client before they notice rather than after.
• Report weekly, in writing, on what shipped against what was promised. No slide deck required.
• Say no to a request that would damage the product, and give the reason in one paragraph.

• Four years or more in product or delivery, some of it in client services where the requirements move after signature.
• You can read a schema and follow a pull request. You do not need to write the code.
• Writing that survives a time zone gap: a decision the other office cannot misread at 7am.
• Agile as a working habit rather than a certificate.

Nice to have

• A background in engineering, QA, or design.
• You have run a fixed-price project and lived with the scope you agreed.
• Experience with training or education products.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A CV and one page on a decision you got wrong: what you chose, what it cost, and what you do differently now. That tells us more than a roadmap screenshot.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Impact on product direction
• Cross-functional collaboration
• Professional growth
• Stock options

• Write the test plan from the acceptance criteria, before the feature exists, and raise the cases nobody wrote down.
• Automate the paths that keep breaking and leave the rest manual. Not every click is worth a script.
• Keep a Playwright or Cypress suite green enough that a red run stops a merge and nobody argues about it.
• File bugs a developer can reproduce on the first read: steps, environment, expected, actual, and the evidence.
• Test on the devices real users hold, not on the newest phone in the office.
• Sign off releases, and say plainly when something is not ready to go out.

• Two years or more testing web or mobile products in a team that shipped regularly.
• One automation framework properly: Playwright, Cypress, or Selenium.
• API testing, and enough SQL to check the data sitting behind the screen.
• The habit of reading a spec and finding the case it does not cover.

Nice to have

• Performance or load testing.
• CI configuration, so the suite runs without you.
• Accessibility testing against WCAG.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A CV, a bug report you are proud of with the identifying details removed, and a link to test code if you have any that is yours to share. This one is a contract role, so tell us your notice period and the hours a week you can commit.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Flexible contract terms
• Remote work
• Training opportunities
• Potential for full-time conversion

• Write and edit what goes on the site, and hold the voice: plain verbs, no filler, no numbers we cannot show the working for.
• Run the campaigns for the training programme. That is how most students find us, and it is the part with the clearest result.
• Get the real story of a project out of the engineers who did it, then publish it without overclaiming on their behalf.
• Own search and analytics for the site: what people looked for, what they read, and what they did next.
• Build the case study library from work we can genuinely show, which means chasing client permission rather than writing around it.
• Report monthly on what worked and what did not, with the numbers attached to both.

• Three years or more in B2B or technical marketing, with writing you can show us.
• Search, analytics, and paid campaigns hands on. Not briefed out to an agency and reported upward.
• You can edit a draft from an engineer without flattening what made it worth reading.
• You are comfortable refusing a claim we cannot back, including when the request comes from us.

Nice to have

• Marketing for a training or education programme.
• Basic HTML and working inside a CMS or a codebase.
• You have grown a function from one person to a small team.

• Every change is reviewed before it merges, including changes written by whoever is leading the project.
• One person owns a piece of work from the scoping conversation through to what runs in production, and stays with it after release.
• Two offices, Hyderabad and Union City. Hyderabad evening is California morning, so anything that needs everyone in one call goes there. The rest of the day is yours to arrange.
• Most of us teach a few hours a month on the free training programme. It is optional. It is also the fastest way to find out how well you know your own work.

A CV and three pieces of writing you would put your name to, ideally including one that had to explain something technical to a non-technical reader. Tell us what result each one had, or that you never found out.

Someone who does the job reads your application, usually within a week. If it fits, a short call about your experience, then a longer working conversation with the people you would sit with, built around a real problem from our work rather than a puzzle. Two conversations, normally inside three weeks. You get a clear answer either way.

• Creative autonomy
• Marketing budget
• Team building opportunities
• Performance bonuses