Who gets hired and onto which teams
Amboras, a San Francisco startup, has seven openings in Alion’s October 21, 2026 snapshot, while Y Combinator’s company profile lists a team size of three. Its application is unusually direct: candidates pick a seat and show their work. The materials point to the central bargain: a compact technical team, with candidates asked to demonstrate ownership through their work rather than rely on pedigree.
Alion’s snapshot places the work in backend engineering, AI/ML, product, and enterprise applications, with backend roles leading the list. Zero G Talent’s board lists the same seven roles by title. The company record names Imad Mokadem and Amin Mokadem as founders. The mix of founding and nonfounding titles, spanning AI, product, full-stack, and commerce systems, points to a build-out of core product and engineering capacity rather than a set of routine vacancies.
The available materials do not include a formal org chart. Job titles and Amboras’s descriptions let readers group the roles by work. The table shows that grouping, not who reports to whom:
| Open role | Closest functional group |
|---|---|
| AI Engineer | AI and machine learning |
| Founding AI Engineer | AI and machine learning; founding scope |
| Product Manager | Product |
| Product Engineer | Product engineering |
| Founding Product Engineer | Product engineering; founding scope |
| Full-Stack Engineer | Backend and full-stack engineering |
| Commerce Systems Engineer | Commerce systems and backend engineering |
Amboras’s AI work sets a practical bar. Its hiring page describes the AI Engineer role as building “the AI that spins up whole stores, copy, and the agents merchants talk to.” The work reaches into the merchant’s operations. Beyond standard role details and an AI Agents tag, the two available AI listings do not spell out a separate technical rubric. Candidates should stay within the boundary Amboras stated: tie technical decisions to something a merchant does.
Product work carries the same standard, though the public role language is limited. The careers page gives its Product Designer seat the mandate to “own how the whole product feels — store builder, AI flows, dashboard.” The Product Engineer and Product Manager openings do not include a separate mandate in the available listings. That gap narrows what applicants can infer, but the role set places product decisions and delivery side by side.
The Full-Stack Engineer role spans the platform merchants use to run their stores. Alion’s Commerce Systems Engineer listing identifies PHP, WooCommerce, AI/ML, and AI Agents. In an Amboras hiring post, the company listed “Building products from scratch” and “Shipping fast and talking directly to customers” and described a “small team, high ownership.”
Minimum experience requirements remain. What the written application does not request is a university, prestigious former employer, or list of technical acronyms. Instead, it asks for evidence of work:
“Tell us which seat you’re after and show us your work. That’s the whole application.”
That instruction turns the application into a work sample.
For an AI candidate, show the system and judgment behind a merchant-facing capability. A full-stack or commerce candidate should trace a requirement through deployment. A product candidate should connect a decision to a merchant touchpoint. A résumé names tools and employers; work reveals whether a candidate can handle the decisions the role demands.
The application is the work sample; the job posting is also where the company puts a price on the role.
What it pays
Y Combinator’s job listings report a salary range for each of the seven roles, and those ranges have a company-level median of $350,000. That median describes those openings, not a promise for an individual offer. The bands show what Amboras says each role costs, not the responsibilities behind the number.
The role postings provide the detail, and Y Combinator’s job listings report the salary and equity ranges:
| Posted role | Experience floor | Salary range (USD/year) | Equity range | Location |
|---|---|---|---|---|
| Founding AI Engineer | 3+ years | $200,000–$400,000 | 0.20%–0.80% | San Francisco, CA, US |
| AI Engineer | 1+ years | $150,000–$350,000 | 0.20%–0.60% | San Francisco, CA, US |
| Founding Product Engineer | 3+ years | $150,000–$350,000 | 0.20%–0.60% | San Francisco, CA, US |
| Product Engineer | 1+ years | $150,000–$300,000 | 0.20%–0.60% | San Francisco, CA, US |
| Full-Stack Engineer | 3+ years | $150,000–$350,000 | 0.20%–0.60% | San Francisco, CA, US |
| Commerce Systems Engineer | 1+ years | $150,000–$350,000 | 0.20%–0.60% | San Francisco, CA, US |
| Product Manager | 1+ years | $150,000–$350,000 | 0.20%–0.60% | San Francisco, CA, US |
Five of seven postings share the $150,000–$350,000 band, so the cash column offers little evidence of a conventional title ladder. The Product Engineer tops out at $300,000; the Founding Product Engineer shares the common band of several nonfounding roles; and only the Founding AI Engineer rises above the common ceiling. The experience floors do not rise in lockstep with pay: the Founding AI Engineer asks for three years while the AI Engineer asks for one, while the Product Manager and Commerce Systems Engineer reach the top of their bands with a one-year floor. The visible data therefore do not support a simple tenure-based pay ladder.
Equity sharpens the founding AI exception. Y Combinator’s job listings show that all six other roles use a 0.20%–0.60% range, while the founding AI role offers 0.20%–0.80%. Amboras does not state the grant type, vesting schedule, exercise terms, or valuation, so candidates should treat the percentages as published ranges, not guaranteed outcomes.
Before accepting, ask for those terms in writing and establish where the offer falls within both published bands. Compare cash with the published equity range rather than treating salary alone as the whole offer. At a startup, compare the ownership on offer with the work the role will require, and state the cash and equity terms plainly before anyone celebrates the top of a range.
The bands show what a seat costs; the next test is how Amboras turns an application into a hiring decision.
How the hiring process works and what gets candidates through it
The application is the first filter. Amboras asks candidates to choose a seat and provide examples of their work; the available page does not name a reviewer or explain how applications are ranked.
The available materials do not describe a separate recruiter screen before an interview, and they name no coding test, solo take-home assignment, or multi-round panel.
The interview and paid trial test how you work. In the earlier Amboras hiring post, the company said its hiring process was “intentionally simple.” A separate post from @ajay_2512x described three steps: a quick interview; a one-week paid trial in which “we work together on real problems”; and a hire if “everything clicks.”
The sequence described in that post puts the practical test after the first conversation, and it does not describe a solo take-home. That format can test more than polished presentation: the interview can showcase fluency, while the trial can show how a candidate frames a problem, makes decisions, and follows through alongside the company.
Public materials do not describe the quick interview’s format. A recorded interview guide says technical candidates may receive more weight in the technical portion of an interview while behavioral questions still come up. Because the guide is not an Amboras document, treat it as preparation advice, not a company rubric. Be ready to explain your actions and results rather than leave an interviewer to infer your contribution from the final output.
The public record defines rejection only in broad terms. The available Amboras pages publish no disqualifier list and identify no background criterion. That absence does not prove an unpublished screen does not exist; it means the public record cannot establish one. Neither Amboras’s pages nor the separate @ajay_2512x post provides a scoring rubric.
With no published rubric, candidates should explain what you did, why you chose it, and what followed. Select one project you can explain without notes and use the same narrative in the quick interview and trial. A consistent account can help an interviewer distinguish a repeatable working method from a polished answer.
Where the work happens
Alion identifies San Francisco as Amboras’s headquarters, and every opening in its October 21, 2026 snapshot is full-time and in office. Its founding AI engineer listing marks the same. Zero G Talent’s board likewise lists all seven roles in San Francisco and no second city.
The work centers on software. Amboras builds prompt-generated storefronts, tests them live, and tracks first-party analytics. Amboras says its product connects to Stripe and PayPal, while Apple Pay, Google Pay, and address autofill come standard. The available postings point to software behavior and merchant use cases; none describes a hardware lab, robotics floor, or fabrication facility.
That operating model puts software behavior and direct merchant feedback at the center of the job.
Who thrives here
An Amboras company post called the startup the “AI-native Shopify” and said its agents run a merchant’s store end to end. For the open engineering and product roles, that reach suggests broad boundaries: the work runs from a merchant request to a measurable change in the store.
The founders’ history explains the commercial pressure. Amboras’s company post reports that Imad Mokadem and Amin Mokadem scaled a $200,000-a-month brand while studying at ETH Zurich and watched overhead eat into the margins, so they built Amboras. Their story supplies the operating context for these roles: the product has to make a merchant’s business work better, not merely demonstrate technical sophistication.
The founding titles suggest a broader remit than execution, although the available postings do not spell out that scope. Candidates can show that capability by explaining how a vague commercial or technical problem became a working system with a clear owner. A general launch description is less useful than a specific account of reducing ambiguity.
Iteration tests judgment after release. Amboras’s store-optimization product generates new hero, offer, layout, and copy variants, sends them live as A/B tests, and promotes the winners automatically. The loop gives candidates a concrete kind of evidence to discuss: a shipped change, the response it produced, and the decision that followed. That is more useful than a concept that never reached a customer. Speed without measurement cannot guide the next version.
Commercial outcomes sit inside the product, too. Each customer session helps Amboras learn what pulls shoppers in, what makes them buy, and what brings them back, and its agents target conversion, average order value, retention, and lifetime value per visitor. A strong candidate connects a technical change to customer behavior and store economics. Amboras reported that beta merchants were seeing a conversion-rate lift of over 80% on the first version it put live. The result came from the company, not an independent test, and does not guarantee the same outcome for every store. The useful question for candidates is what changed for the shopper and the store, not merely whether the code shipped.
The available materials on Amboras say little about employee experience. They cover founder history and job language but contain no interviews with current employees, so they cannot support claims about office rituals or management style.
Before an interview, put the artifact on the table. The interviewer should be able to follow what your decision changed after release. At this size, that record is the difference between a claim and a hire.
Working in frontier tech? Zero G Talent tracks the openings: see every open Amboras role, browse frontier tech jobs, the companies hiring, and the people building the field.