The E-3 Visa for Tech Roles: A Practical Guide for Australian Software Engineers, Data Scientists, and Product Managers

Reviewed 11 May 2026 by Kelvin Tran, attorney licensed in New York and also admitted to practice law in Australia (Supreme Court of Victoria, High Court of Australia); not licensed in California; practice limited to federal immigration law.

For Australian software engineers, data scientists, designers, and product managers, the E-3 is the visa that most likely got you to the US — or that most likely will. The major US tech hubs (San Francisco, Seattle, New York, Austin, Boston, Los Angeles) are full of Australian engineers and product people who started in Sydney, Melbourne, or Brisbane and made the move on E-3. Atlassian, Canva, Google, Meta, Amazon, Microsoft, Apple, Salesforce, Stripe, OpenAI, Scale AI, and basically every other major tech employer hires Australians, and the E-3 is the standard pathway.

The good news: tech roles are generally among the cleaner E-3 cases. Software engineering, data science, security engineering, and most technical roles have well-established specialty-occupation profiles. Computer Science is a recognised specialty discipline. The standard hiring norm — “Bachelor’s degree in Computer Science or related field” — aligns with E-3 requirements. Most Australian software engineers who apply for E-3 are approved without difficulty.

The complication: not all tech roles fit cleanly. Product Manager, Engineering Manager, Designer, Marketing Manager, Sales Engineer, and various other roles in tech are doctrinally borderline. The same generalist hiring norms that create challenges for management consulting apply here — Product Manager is famously a “anyone with strong analytical skills can do it” role that consular officers have read as not requiring a specific specialty degree. The August 2021 MadKudu Inc. v. USCIS class action settlement was specifically about USCIS’s pattern of denying H-1B petitions for Market Research Analyst roles, and similar dynamics affect E-3 cases for borderline tech roles.

This article walks through how the E-3 actually works for tech roles in 2026: which roles are clean, which are borderline, how to construct cases that succeed, and how the major tech employers handle E-3 sponsorship. It also addresses the post-September 2025 environment, where the H-1B Proclamation’s $100,000 fee made E-3 dramatically more attractive to tech employers — and what that means for Australian engineers.

In this article

• Why tech generally works well for E-3
• The clean cases: software engineering and adjacent
• Data science, machine learning, and AI roles
• Security engineering
• The borderline cases: product management
• The borderline cases: design
• Engineering management and senior IC roles
• Marketing and growth roles in tech
• Sales engineering and solutions engineering
• SOC code strategy for tech roles
• Big Tech: Google, Meta, Amazon, Apple, Microsoft, Netflix
• Australian tech firms in the US: Atlassian, Canva, and others
• Startup and scaleup considerations
• Stock compensation and LCA wage compliance
• Remote work and the worksite question
• The September 2025 H-1B Proclamation and what it means for E-3
• Common ways tech cases fail

Why tech generally works well for E-3

Compared to finance and consulting roles (covered in our finance/consulting article), tech roles are generally cleaner E-3 cases. Several structural factors:

Established specialty discipline. Computer Science is a recognised academic discipline with a clear undergraduate and graduate progression. Unlike “general business” or “any analytical major,” CS, software engineering, and related fields have direct curricular alignment with the work performed.

Industry hiring norms favor specialty backgrounds. While tech companies do hire from non-CS backgrounds, the dominant hiring pattern is CS or related quantitative degrees. Job postings typically list “Bachelor’s degree in Computer Science, Computer Engineering, or related technical field” — exactly the language E-3 needs.

Technical interviews emphasise specialty knowledge. The interview process at major tech employers tests algorithmic thinking, system design, coding ability, and other clearly specialty-aligned skills. This supports the case that the role genuinely requires CS-level training.

Job titles align with specialty content. “Software Engineer,” “Backend Engineer,” “Machine Learning Engineer,” “Security Engineer” — these titles carry specialty signal in a way that “Consultant” or “Manager” doesn’t. The title itself communicates the technical nature of the work.

Wage levels are typically high. Major tech employers pay well above prevailing wage levels for software engineering roles in major hubs. This typically positions cases at Level III or Level IV, supporting the specialty argument.

Established E-3 sponsorship infrastructure. Big Tech companies have processed thousands of E-3 visas. Their legal and HR teams know the requirements, the documentation, and the standard playbook. Cases at established employers move smoothly because the employer has the process down.

The combined effect: a typical Australian software engineer applying for an E-3 at Google, Meta, Microsoft, or a similar employer faces approximately the cleanest possible case profile in US immigration. Approval rates are high; complications are rare; the process moves quickly.

But this isn’t universal. The borderline cases — Product Managers, Designers, Marketers, Sales Engineers — face many of the same challenges as finance/consulting roles. And even clean software engineering cases can fail if construction details are wrong.

The clean cases: software engineering and adjacent

The cleanest E-3 cases are core software engineering and technical roles:

Software Engineer / Software Developer

The bread-and-butter E-3 case. SOC 15-1252 (Software Developers). The role profile typically includes:

• Designing and building software systems
• Writing code in production languages (Python, Java, Go, JavaScript, TypeScript, C++, Rust, etc.)
• Working with system architecture, databases, APIs
• Code review and technical mentorship

Australian software engineers with CS, computer engineering, software engineering, or similar undergraduate degrees from Australian universities (UNSW, Sydney, Melbourne, ANU, Monash, UTS, Queensland, Adelaide, etc.) have direct degree-to-role alignment. The case is straightforward.

Frontend, Backend, Full-Stack, Mobile Engineer

All variants of software engineering, all using SOC 15-1252. The specific specialisation (frontend vs backend vs mobile) doesn’t typically affect E-3 analysis materially — the underlying work is software development.

DevOps / Site Reliability Engineer (SRE) / Platform Engineer / Infrastructure Engineer

SOC 15-1244 (Network and Computer Systems Administrators) is sometimes used, but SOC 15-1252 is often more accurate for SRE and Platform roles where the work involves substantial software development on infrastructure systems. The choice depends on the specific role profile:

• Pure systems administration: 15-1244 may apply
• Infrastructure-as-code, platform engineering, building tools: 15-1252 is typically more accurate
• Network architecture: SOC 15-1241 (Computer Network Architects)

For most modern SRE and platform engineering roles at major tech companies, 15-1252 is the better fit because the work is substantively software development rather than traditional sysadmin.

Database Engineer / DBA

SOC 15-1245 (Database Administrators and Architects). Clean specialty profile.

QA Engineer / Test Automation Engineer

SOC 15-1253 (Software Quality Assurance Analysts and Testers) for traditional QA roles. For test automation engineers writing test infrastructure code, 15-1252 may be more accurate. Hybrid roles can go either way.

Mobile Engineer (iOS, Android)

SOC 15-1252. Same as general software engineering with platform-specific focus.

Game Developer / Game Engineer

SOC 15-1252. Specialty profile is the same as general software engineering.

Data science, machine learning, and AI roles

Data and ML roles are typically clean E-3 cases, but the SOC code choice has real consequences for wage levels and case framing.

The SOC options

Multiple codes can apply:

• SOC 15-2051 (Data Scientists) — created in 2018 to formalise the data science occupation. Applies to roles primarily focused on extracting insights from data using statistical and machine learning methods.
• SOC 15-1252 (Software Developers) — applies when the role is primarily building ML systems and infrastructure rather than analysis.
• SOC 15-2031 (Operations Research Analysts) — applies for roles focused on optimisation, simulation, and decision-science work.
• SOC 15-2041 (Statisticians) — applies for roles primarily focused on statistical modeling, often in research contexts.

Choosing between codes

The right code depends on actual primary function:

Data Analyst doing dashboards and reporting: SOC 15-2051 typically, though for primarily analytical (not modeling) roles the case is sometimes harder.

Data Scientist building ML models for product features: SOC 15-2051 or 15-1252 depending on whether the role is more analysis-focused or production-engineering-focused.

Machine Learning Engineer deploying models in production: SOC 15-1252 typically — this is software engineering work with ML focus.

ML Researcher / AI Researcher: SOC 15-2051 or 15-2041, depending on whether the work is more product-oriented or research-oriented. PhD researchers at AI labs typically use 15-2051.

MLOps / ML Infrastructure Engineer: SOC 15-1252 (Software Developer) — the work is building infrastructure for ML systems.

Educational alignment

Data science roles benefit from:

• CS, math, statistics, or quantitative undergraduate degrees — clean alignment.
• Master’s or PhD in CS, statistics, applied math, or related quantitative field — strong alignment, especially for research roles.
• Domain-specific PhDs (physics, computational biology, computational neuroscience) — generally clean, particularly for research-focused roles where the domain expertise matters.

Less aligned backgrounds (humanities, business, etc.) require stronger specialty-of-duties argument, similar to non-CS backgrounds in software engineering.

AI labs and frontier research

The current AI/ML labs (OpenAI, Scale AI, plus various university-spinout research organisations) hire substantial numbers of Australian researchers and engineers. These cases are typically clean because:

• The work is genuinely specialised research
• The wage levels are very high, supporting Level IV analysis
• The educational backgrounds (typically PhD or top-tier MS) align cleanly
• The employers have established E-3 processes

The complication: some AI labs are smaller and less established than typical Big Tech employers, which can affect the practical-administration side. Smaller employers sometimes need more guidance through the E-3 process than experienced Big Tech sponsors.

Security engineering

Security engineering is typically a clean E-3 case but uses different SOC codes than general software engineering.

SOC options

• SOC 15-1212 (Information Security Analysts) — the primary code for security engineers.
• SOC 15-1252 (Software Developers) — applies for security engineers whose work is primarily building security tools and infrastructure.
• SOC 15-1241 (Computer Network Architects) — for network security architects.

Role categories

Application Security Engineer / Product Security Engineer. Building security into product development; threat modeling, code review, security tooling. Either 15-1212 or 15-1252 depending on focus.

Infrastructure Security Engineer. Cloud security, network security, infrastructure hardening. Typically 15-1212 or 15-1241.

Security Operations / Incident Response. SOC analyst, incident responder, threat hunter roles. Typically 15-1212.

Red Team / Penetration Tester. Offensive security roles. Typically 15-1212; sometimes 15-1252 for tool-building focus.

Security Researcher. Vulnerability research, malware analysis, advanced persistent threat tracking. Typically 15-1212 with research emphasis.

Specialty alignment

Security roles benefit from:

• CS or computer engineering undergraduate degrees — clean alignment.
• Cybersecurity / information security degrees — direct alignment.
• Industry certifications (OSCP, GIAC, CISSP, etc.) — supporting evidence, particularly for candidates with non-CS undergraduate backgrounds.

Government security clearances aren’t typically relevant for E-3 (which prohibits classified work in most cases), but security industry certifications strengthen the specialty case.

The borderline cases: product management

Product Manager is the most famously problematic tech role for E-3 (and H-1B). The role is clearly important and clearly specialised in practice, but the doctrinal alignment with E-3’s specialty-occupation framework is awkward.

Why PM is doctrinally challenging

Several factors:

Generalist hiring norms. Top tech employers explicitly recruit PMs from multiple backgrounds: CS, engineering, business, product design, even humanities. Apple’s job postings sometimes describe PM roles as appropriate for candidates with “Bachelor’s degree in Computer Science, Engineering, Business, or related field” — the “or related field” clause is what consular officers seize on.

Job titles that don’t communicate specialty. “Product Manager,” “Senior Product Manager,” “Group Product Manager,” “Director of Product” — none of these titles inherently signal a specific specialty discipline.

Variable role profiles. A PM role at one company looks substantially different from a PM role at another. Some PMs do heavy technical work; others do user research; others do market analysis. This variability undermines the specialty argument.

The MadKudu context. The August 2021 MadKudu Inc. v. USCIS class action settlement specifically addressed USCIS’s pattern of denying H-1B petitions for Market Research Analyst roles (SOC 13-1161). While that settlement applied to a specific occupation and a specific time period, the underlying issue — generalist roles with variable degree requirements — affects PM cases similarly.

Strong PM cases

The strongest E-3 cases for PM roles involve:

Technical Product Manager (TPM) framing. A TPM whose work is primarily technical — coordinating with engineering teams on architectural decisions, making technical trade-off calls, writing technical specifications — has a stronger case than a generalist PM. The relevant SOC code may shift toward 15-1252 (Software Developers) for heavily technical TPMs.

Engineering background. A PM with a CS or engineering undergraduate degree, who’s worked as a software engineer before transitioning to PM, has clean educational alignment regardless of the role’s generalist hiring norms.

Specialised domain. A PM working in a technical domain (security products, infrastructure platforms, ML/AI products, developer tools) can frame the role as requiring domain-specific expertise that’s harder to dispute.

Detailed technical duty descriptions. “Defines product roadmap” doesn’t help. “Defines technical architecture for distributed systems product, including API design, scalability requirements, data model decisions, and developer-experience trade-offs” does.

Senior level. Senior PM, Group PM, and Director-level roles often have cleaner cases than junior PM roles because the work is more clearly strategic and complex.

SOC code strategy for PM

Multiple codes can apply, with different success patterns:

• SOC 13-1199 (Business Operations Specialists, All Other) — frequently used but typically problematic. The “All Other” catch-all reads as evidence the role isn’t a specific specialty.
• SOC 15-1252 (Software Developers) — appropriate for heavily technical TPMs whose work substantially overlaps with software engineering.
• SOC 11-2021 (Marketing Managers) — sometimes used for PMs in marketing-adjacent contexts; typically problematic.
• SOC 13-1111 (Management Analysts) — sometimes appropriate for PMs whose work is primarily business-analysis-oriented.

The right choice depends on actual primary function. For product managers whose work is genuinely technical, SOC 15-1252 with detailed technical-duty support letters is often the strongest framing.

Common PM refusals

Recurring failure patterns:

Generic PM job description. “Owns the product roadmap, works with engineering and design, prioritises features.” This doesn’t articulate specialty.

Mismatched undergraduate degree. A PM with a humanities or business undergraduate degree faces harder analysis than one with a CS or engineering degree.

SOC 13-1199 used without strong narrative. The “All Other” code requires substantial supporting documentation to establish specialty. Filing under 13-1199 with thin supporting documentation invites RFE or refusal.

Wage level too low. Filing PM roles at Level I or Level II wages signals routine work that doesn’t require specialty knowledge.

No technical content in duty description. Even for non-TPM roles, surfacing the technical aspects of the work strengthens the case.

The borderline cases: design

Design roles in tech — UX designers, UI designers, product designers, design researchers — are doctrinally borderline for E-3.

Why design is challenging

Varied educational backgrounds. Designers come from graphic design programs, HCI master’s programs, fine art programs, CS programs with HCI focus, self-taught backgrounds, etc. The “specific specialty degree” requirement maps poorly.

Mixed work types. Design roles span visual work, research, prototyping, system design, accessibility analysis, motion design. The specialty profile is harder to articulate as one discipline.

SOC code complexity. The applicable SOC codes have varying specialty-occupation profiles.

SOC options

• SOC 15-1255 (Web and Digital Interface Designers) — created in 2018 to formalise this category. Better E-3 profile than 27-1024 because of clearer technical alignment.
• SOC 27-1024 (Graphic Designers) — historically used but typically problematic for E-3 because the OOH lists “associate degree” as sometimes sufficient.
• SOC 27-1014 (Special Effects Artists and Animators) — for motion designers and similar.
• SOC 15-1252 (Software Developers) — sometimes appropriate for designers whose work involves substantial code (design engineers, design technologists).

Strong design cases

The strongest E-3 cases for design roles involve:

Product Designer at a tech company with technical focus. A designer whose work involves system design, prototyping in code, and direct collaboration with engineering on technical implementation has stronger case than a pure visual designer.

Senior or Staff Designer roles. More senior designers face cleaner cases because the work is more clearly strategic and specialised.

HCI or design master’s degree. Educational alignment with the specialty area strengthens the case.

SOC 15-1255 framing. This code has cleaner E-3 profile than 27-1024.

Refusal patterns

The recurring issues:

Pure visual design roles with non-CS backgrounds. A graphic designer with a fine art degree applying for a generic UI designer role at a tech company faces harder analysis than a senior product designer with HCI training applying for a senior product role.

SOC 27-1024 with thin specialty narrative. This SOC code has known E-3 challenges; using it requires substantial supporting documentation.

Visual-only role descriptions. Duty descriptions focused on aesthetic decisions rather than specialty technical work weaken the case.

Engineering management and senior IC roles

Senior software engineering roles — Staff Engineer, Principal Engineer, Distinguished Engineer — and engineering management roles — Engineering Manager, Senior Engineering Manager, Director of Engineering, VP Engineering — have specific E-3 considerations.

Senior IC (Individual Contributor) roles

Staff and Principal engineers typically use SOC 15-1252 (Software Developers) at Level IV wages. The case is generally clean because:

• The work is clearly specialised software engineering
• Wage levels at major tech employers easily clear Level IV
• The seniority signals complexity

The complication: some Staff and Principal IC roles involve substantial leadership and architectural work that’s less directly hands-on coding. The case framing should emphasise the technical leadership, system design, and complex problem-solving aspects rather than presenting the role as basic software development.

Engineering Manager roles

Engineering Managers typically use SOC 11-3021 (Computer and Information Systems Managers). The shift from 15-1252 to 11-3021 reflects the role’s primarily managerial nature.

For E-3 purposes:

• The shift to 11-3021 is appropriate for true engineering managers (people management, hiring, performance reviews, project management)
• For managers who are still substantially hands-on technically, 15-1252 may still be appropriate
• The wage levels at 11-3021 are typically higher than 15-1252, supporting Level IV analysis

Director / VP roles

More senior management roles continue under SOC 11-3021 typically, with potentially different SOC codes (such as 11-1011 Chief Executives) for very senior roles. The specialty-occupation case at director level focuses on the strategic and technical decision-making aspects of the role.

The IC-to-manager transition

A common career inflection: an Australian software engineer on E-3 gets promoted to Engineering Manager. Does this require an LCA amendment?

The answer is typically yes, because:

• The SOC code changes (15-1252 → 11-3021)
• The role profile changes materially (technical work to managerial work)
• The wage may change

The amendment isn’t necessarily complicated, but it requires a new LCA, possibly a new I-129 amendment, and updated documentation. Communicate the promotion to your immigration counsel before it takes effect.

Marketing and growth roles in tech

Tech marketing roles — growth marketing, content marketing, product marketing, demand generation, marketing operations — are typically harder E-3 cases than core engineering roles.

Why marketing is challenging

Same dynamics as PM and consulting:

• Generalist hiring norms
• Multiple acceptable degree backgrounds
• Job titles that don’t communicate specialty
• Variable role profiles across employers

SOC options

• SOC 11-2021 (Marketing Managers) — for senior marketing roles
• SOC 13-1161 (Market Research Analysts) — historically problematic post-MadKudu
• SOC 15-2051 (Data Scientists) — for marketing data scientists
• SOC 13-1199 (Business Operations Specialists, All Other) — sometimes used; typically problematic

Strong marketing cases

The strongest cases involve:

Product Marketing Manager at a technical product company. When the role requires deep understanding of technical products and translation to market positioning, the specialty argument is stronger.

Marketing Data Scientist or Growth Engineer. Roles where the work is primarily analytical and quantitative can use SOC 15-2051 with cleaner specialty profile.

Senior or Director-level roles. More senior marketing roles have cleaner cases because the work is more strategic and complex.

Marketing roles at technical-product companies. Marketing for developer tools, infrastructure products, or technical APIs has clearer specialty profile than general consumer marketing.

Common refusal patterns

• Generic “Marketing Manager” with broad degree requirement
• SOC 13-1161 (Market Research Analyst) post-MadKudu without addressing the specific issues
• Marketing roles at non-technical companies (less specialty signal)
• Junior marketing roles at any company

Sales engineering and solutions engineering

Sales engineers, solutions engineers, customer success engineers, and similar pre-sales / post-sales technical roles are often the hardest tech E-3 cases.

Why sales engineering is challenging

The “sales” framing is typically problematic for E-3:

• Sales is inherently about commercial activity, not specialty work
• The technical depth varies by company and role
• Standard sales-coded SOC categories aren’t specialty-occupation-friendly

SOC options

• SOC 15-1252 (Software Developers) — appropriate for solutions engineers with substantial code-writing focus
• SOC 41-3031 (Securities, Commodities, and Financial Services Sales Agents) — typically inappropriate (not the right fit) and problematic for E-3
• SOC 11-2021 (Marketing Managers) — sometimes used for senior solutions roles; typically problematic
• SOC 15-1299 (Computer Occupations, All Other) — catch-all that’s typically problematic

Strong sales engineering cases

The strongest cases involve:

Pre-sales solutions engineers at technical product companies. When the role is primarily about technical demonstrations, integration architectures, and solving technical problems for prospective customers, the specialty argument is workable.

Customer success engineers at developer tools companies. Post-sales technical roles at companies whose products are themselves technical (databases, observability tools, infrastructure platforms) can establish specialty more easily than generic SaaS post-sales.

Solutions architects. Architecture-focused pre-sales work at major tech companies (AWS, GCP, Azure) typically has stronger specialty profile than generic solutions engineering.

Detailed technical duty descriptions. “Designs cloud infrastructure architectures incorporating Kubernetes, Terraform, and managed services for enterprise customers” works better than “supports sales team with technical demonstrations.”

Refusal patterns

• “Sales engineer” framing without strong technical content
• Pre-sales roles at non-technical companies
• Junior solutions roles
• Sales-coded SOC selections

SOC code strategy for tech roles

A consolidated view of SOC code strategy for tech:

Role type	Primary SOC option	Alternative SOCs	Notes
Software Engineer (any specialty)	15-1252 Software Developers	—	Cleanest case
DevOps / SRE / Platform Engineer	15-1252 Software Developers	15-1244 Network Admins	15-1252 for software-heavy work
Data Scientist (modeling)	15-2051 Data Scientists	15-1252 Software Developers	15-2051 for analysis-focus
ML Engineer	15-1252 Software Developers	15-2051 Data Scientists	15-1252 for production ML
AI Researcher	15-2051 Data Scientists	15-2041 Statisticians	Either fits research roles
Security Engineer	15-1212 Information Security Analysts	15-1252 Software Developers	Either depending on focus
Database Engineer / DBA	15-1245 Database Administrators	—	Standard
QA Engineer	15-1253 QA Analysts	15-1252 for automation focus	Both work
Product Manager (technical)	15-1252 Software Developers	13-1199 Business Ops	15-1252 if heavily technical
Product Manager (general)	13-1199 Business Operations	13-1111 Management Analysts	Borderline; needs strong narrative
Engineering Manager	11-3021 Computer Systems Managers	15-1252 if hands-on	Standard for management
UX/UI Designer	15-1255 Web and Digital Interface Designers	27-1024 Graphic Designers	15-1255 has cleaner profile
Product Designer	15-1255 Web and Digital Interface Designers	27-1024	Similar to UX
Sales Engineer	15-1252 Software Developers	15-1299 Computer Occupations	Borderline
Solutions Architect	15-1252 Software Developers	15-1241 Computer Network Architects	Either works
Technical Writer	27-3023 News Analysts, Reporters	27-3042 Technical Writers	Standard
Marketing Manager (tech)	11-2021 Marketing Managers	—	Borderline

Several SOC codes are typically problematic for tech:

• 15-1299 Computer Occupations, All Other — vague catch-all; consular officers often read this as evidence the role isn’t a true specialty
• 13-1199 Business Operations Specialists, All Other — same issue, particularly problematic for PM
• 41-3031 and other sales-coded SOCs — sales coding undermines specialty argument

Avoid these codes where alternatives exist; when they’re the most accurate fit, build the case carefully with substantial supporting documentation.

Big Tech: Google, Meta, Amazon, Apple, Microsoft, Netflix

The major US tech employers — typically referred to collectively as Big Tech, FAANG, or similar — sponsor large numbers of Australian E-3 holders. Their patterns:

Established processes

These employers have processed thousands of E-3 visas. Their legal and HR teams know the requirements; their internal documentation is templated; their relationships with consulates are established. For an Australian software engineer joining one of these companies, the E-3 process is typically among the smoothest possible.

Standard role classifications

Big Tech employers typically have well-developed internal mappings of role to SOC code, role to LCA wage level, and role to specialty-occupation justification. A Software Engineer L3 at one of these companies has a documented profile that the immigration team has used hundreds of times.

High wage levels

Total compensation at Big Tech easily clears prevailing wage thresholds at Level IV. Base salaries plus stock plus bonuses for senior software engineers often reach $400K-$700K+ for senior IC roles in major hubs. The wage compliance is essentially never an issue for clean E-3 cases at these companies.

Established specialty narratives

These employers have well-developed specialty-occupation narratives for engineering roles, refined through years of E-3 and H-1B practice. A consular officer reviewing a Software Engineer petition from Google or Meta sees documentation that’s well-crafted, comprehensive, and aligned with established practice.

Known patterns at specific employers

While each company has its own internal practices, some general observations:

Google / Alphabet. Major E-3 sponsor; well-established processes. Wide range of role types from software engineering to ML research to product management.

Meta (Facebook). Major E-3 sponsor. Typically clean cases; established internal documentation.

Amazon (including AWS). Substantial E-3 sponsorship; AWS technical roles particularly well-fit for E-3 due to clear specialty profiles.

Apple. Selective E-3 sponsor; high standards for documentation. Cupertino-headquartered with various US offices.

Microsoft. Major E-3 sponsor; well-established processes. Includes both Microsoft proper and various subsidiaries (LinkedIn, GitHub).

Netflix. Smaller E-3 footprint than other Big Tech but does sponsor; tends toward senior roles.

Salesforce. Major SF-based E-3 sponsor across cloud platform engineering and product roles.

NVIDIA. Significant E-3 sponsor, particularly for ML and chip-related software engineering. Roles align cleanly with E-3 specialty profile.

Common considerations at Big Tech

Promotion-driven LCA amendments. Senior software engineers at Big Tech progress through level systems (L3 → L4 → L5 → L6 → L7+ in typical Google nomenclature). Promotions within software engineering levels typically don’t require LCA amendments. Promotions to engineering management do (SOC change to 11-3021).

Worksite shifts. Big Tech employees sometimes move between offices (San Francisco → New York, Seattle → Austin, etc.). Worksite changes affect the LCA and may require amendment. See our LCA article for the worksite analysis.

Stock compensation. RSUs at Big Tech form substantial parts of total compensation. They don’t satisfy LCA wage requirements (which look at cash wages), but they don’t create issues if the cash base salary clears the LCA wage. See stock compensation below.

Internal transfers from Australian offices. Atlassian-style scenarios where an Australian moves from the Sydney office of a Big Tech company to a US office on E-3 are common. The internal hiring decision validates qualifications, but the US E-3 case is still a separate analysis.

Australian tech firms in the US: Atlassian, Canva, and others

Several major Australian tech firms have substantial US presence and sponsor Australian employees on E-3. These employers have unique patterns.

Atlassian

Atlassian is the largest Australian tech company by US headcount, with major offices in San Francisco, Mountain View, Austin, and elsewhere. The company has been sponsoring E-3 visas for over a decade and has highly refined processes.

Patterns at Atlassian:

• Established process. The internal immigration and HR teams know E-3 requirements deeply.
• Wide role range. Software engineering, product management, design, marketing, sales — Atlassian’s E-3 sponsorship spans the full role spectrum.
• Australian-Sydney-to-US transfers. Many Atlassian US E-3 holders started at the Sydney office. The internal transfer dynamic supports the case.
• Documentation quality. The company’s E-3 documentation is typically high-quality and aligned with established practice.

Canva

Canva is another major Australian tech employer with substantial US presence. Smaller US footprint than Atlassian but growing. Similar patterns:

• Established E-3 sponsorship processes
• Wide role range
• Australian-to-US transfers common
• High-quality documentation

Other Australian tech firms

• SafetyCulture — workplace safety platform with US presence
• Culture Amp — employee experience platform with US presence
• Linktree — social media platform with US presence
• Blackmagic Design — video production technology, well-established US presence
• Cochlear — medical device company with US R&D and operations
• WiseTech Global — logistics software with global presence
• NEXTDC, MEGAPORT, others — various Australian tech-adjacent companies with US offices

These firms typically have E-3 sponsorship experience (because they hire Australians for both Australian and US offices), though processes vary by company size and US footprint.

The transfer dynamic

For internal transfers from Australian arms to US offices on E-3:

• The internal hiring decision validates qualifications
• The role transfer typically involves continuity, supporting specialty argument
• The Australian salary band and US salary band may differ; the US compensation must independently meet LCA wage requirements
• The role description and duties must independently establish US E-3 specialty occupation — Australian role descriptions don’t automatically translate

Startup and scaleup considerations

Beyond Big Tech and major Australian firms, many Australians work at smaller US tech companies — Series A to D startups, scaleups, and unicorns. These employers have different patterns.

Why startups can be harder E-3 sponsors

Less established processes. A Series B startup may have sponsored a handful of E-3s ever; the process isn’t as polished as Big Tech.

Smaller HR/legal teams. Startups often don’t have dedicated immigration legal teams. The E-3 process is sometimes handled by external counsel without deep startup-specific expertise, or by HR teams new to E-3.

Documentation gaps. Startups sometimes don’t have well-documented internal salary bands, written role descriptions, or formal organizational structures. This affects the LCA support letter and specialty narrative.

Worksite uncertainty. Distributed startups, remote-first companies, and rapidly-changing office locations create LCA worksite complications.

Compensation structure complexity. Startup compensation often involves substantial equity components with various structures (ISOs, NSOs, RSUs, refresher grants, etc.). The cash component must still meet LCA wage requirements.

Strong startup E-3 cases

Well-funded scaleups (Series C+). Companies that have raised substantial capital typically have processes mature enough to support E-3 cleanly. Stripe, Databricks, Snowflake, and similar pre-IPO scaleups generally have strong E-3 capabilities.

Y Combinator alumni and well-known investors. Companies with recognised institutional backing have stronger cases at consulates because the bona fide nature of the employer is more easily established.

Senior roles. Senior technical roles at startups face cleaner cases than junior roles because the work is more clearly specialised.

Technical product focus. Startups whose products are themselves technical (developer tools, infrastructure, AI/ML) have cleaner specialty narratives than consumer product startups.

Common startup challenges

First-time E-3 sponsorship. A startup that’s never sponsored an E-3 needs to establish FEIN verification with DOL, set up FLAG portal access, and learn the process. This adds 1-2 weeks to the timeline. See our LCA article.

LCA wage challenges. Startups sometimes pay below-market base salaries with heavy equity. If the cash base salary doesn’t meet the prevailing wage, the E-3 doesn’t work without restructuring compensation.

Worksite documentation. Distributed startups need to clearly identify the worker’s worksite for LCA purposes. “Remote” isn’t a worksite; the worker’s home address is.

Limited Big-Tech-style infrastructure. Internal HR processes, payroll systems, and legal documentation may need to be developed for E-3 compliance. The startup learns as it goes.

Pre-employment due diligence

For Australians considering startup roles, useful diligence questions:

• Has the company sponsored E-3 (or H-1B) visas before?
• Who handles immigration sponsorship — internal team or external counsel?
• What’s the cash base salary versus the prevailing wage for the role and location?
• What’s the worksite arrangement — fully remote, hybrid, in-office?
• Are there established salary bands that would survive a WHD audit?

These questions save complications later.

Stock compensation and LCA wage compliance

Tech compensation is heavily weighted toward stock — RSUs, options, ESPP, refresher grants. This creates LCA wage compliance considerations similar to (but distinct from) the bonus issues in finance.

What the LCA wage requirement covers

Per 20 CFR § 655.731, the employer must pay the E-3 worker the higher of the prevailing wage or the actual wage. The “wage” is typically expressed as cash compensation paid as wages.

Stock compensation doesn’t substitute for the cash LCA wage. The base salary alone must meet the LCA-attested wage; stock is additional.

Why this rarely creates problems at Big Tech

For typical Big Tech offers, base salaries clear prevailing wages comfortably:

• Software Engineer L4 in San Francisco at Google: Base salary typically $180K-$220K; prevailing wage for SOC 15-1252 Level III in SF is well below this
• Senior Software Engineer at Meta in NYC: Base salary typically $230K-$280K; clears Level IV prevailing wage
• Staff Engineer in Seattle at Microsoft: Base salary typically $250K-$320K; clears Level IV easily

The cash base salary alone meets the LCA wage requirement. Stock is purely additive.

When stock compensation creates issues

A few scenarios:

Lower-base/higher-stock arrangements. Some startups pay below-market base salaries with heavy equity. If the cash base falls below the prevailing wage, the LCA cannot be satisfied through stock. This requires either increasing the base salary or restructuring compensation.

LCA attested at total comp. If an employer attests the LCA wage at total compensation (base + stock + bonus) rather than base salary, the cash base salary must still meet that attested figure. Attesting $400K when the cash base is $200K creates a wage compliance violation.

Refresher grants and changing comp structure. Compensation structure changes over time (refresher grants, vesting cliffs, etc.). If at any point the cash base salary falls below the LCA wage, that’s a compliance issue.

Equity-only arrangements. Some startups offer equity in lieu of cash compensation. This doesn’t work for E-3 — there must be a cash wage that meets the LCA-attested level.

LCA wage strategy for tech compensation

The right approach:

• Use cash base salary, not total compensation. Avoid the trap of attesting total comp.
• Document the actual wage system. Internal salary bands and equity structures should be documented in the public access file.
• Annual reviews. Compensation reviews should include verification that cash base salary continues to meet the LCA wage.
• Don’t reduce base salary mid-LCA. A base salary cut during an active LCA period is a wage compliance violation regardless of total compensation structure.

For more on LCA wage compliance, see our LCA article.

Remote work and the worksite question

Tech has more remote and distributed work than most other sectors. This creates LCA worksite complications.

The DOL position on remote work

Per August 2023 DOL OFLC FAQ guidance:

• An E-3 worker’s home, where they regularly perform work, is a “place of employment” within the meaning of the regulation and must be listed on the LCA.
• If the worker moves to a new home in a different metropolitan statistical area (MSA), a new or amended LCA is required.
• If the move is within the same MSA, the public access file should reflect the new worksite, but a new LCA may not be required.
• “Telework from anywhere” arrangements are not compatible with the LCA structure.

Practical implications for tech workers

Fully remote with stable home address. The worker’s home address is the worksite. A new LCA is needed if the worker moves to a different MSA. This works but requires LCA refiling on each MSA-changing move.

Hybrid arrangements (3 days office, 2 days home). Both the office and the home are worksites. The LCA can list both, or the dominant worksite, depending on the arrangement.

Fully office-based. The office is the worksite. No remote work complications.

“Work from anywhere” arrangements. These don’t fit the LCA structure cleanly. Some employers handle this by listing the company headquarters as the worksite, but this is technically incorrect if the worker doesn’t actually work there.

Frequent travel between locations. Sales engineers, solutions architects, and similar roles that visit customer sites need to address travel patterns. Travel within the same MSA is less complicated; cross-country travel requires more careful LCA structuring.

Common worksite issues for tech roles

Australians moving across US states. An Australian E-3 holder who joins a Silicon Valley company, then moves to Austin, Texas, needs an LCA amendment. The MSA change requires new LCA filing.

Distributed company hires. A worker hired by a fully-distributed company (no central office) typically lists their home address as the worksite. If the company is genuinely distributed, this works.

Annual home moves. Workers who move annually (city to city for personal reasons) create repeated LCA amendment burden. Some employers manage this through standardised LCA refiling processes.

International remote work. A small but growing pattern: Australians who want to work remotely from Australia for a US E-3 employer. This is structurally complicated — E-3 work authorization is for US-based employment, not remote work from Australia. The LCA worksite must be a US worksite.

For more on the worksite analysis, see our LCA article.

The September 2025 H-1B Proclamation and what it means for E-3

The September 19, 2025 Presidential Proclamation imposed a $100,000 fee on certain H-1B petitions. This dramatically changed the calculus for tech employers and made E-3 substantially more attractive.

The Proclamation in brief

The September 19, 2025 Proclamation, issued under INA § 212(f), imposed a $100,000 supplemental fee on H-1B petitions for new arrivals. The fee applies to entries occurring after the Proclamation’s effective date for petitions covering employment of H-1B nonimmigrants entering after that date.

Why E-3 is unaffected

The Proclamation, by its terms, applies only to H-1B petitions filed under INA § 101(a)(15)(H)(i)(b). The E-3 is a distinct visa classification under INA § 101(a)(15)(E)(iii), and is not within the Proclamation’s scope.

E-3 fees and procedures continue under their pre-existing structure. There is no $100,000 supplemental fee on E-3.

Why this matters for tech employers

Pre-September 2025, tech employers typically used both H-1B (for non-Australian foreign workers) and E-3 (for Australian workers). The visas were treated as roughly comparable — both required LCAs, both required specialty-occupation justification, both had similar fee profiles.

Post-Proclamation, H-1B is dramatically more expensive. A $100,000 fee per petition is a significant deterrent to H-1B sponsorship, particularly for early-career hires whose total cost-to-employ may not justify the fee.

The result: E-3, which was always a “nice to have” alternative for Australian hires, became substantially more attractive in absolute terms. Many tech employers have actively shifted hiring strategies to favor E-3-eligible candidates (Australians) where possible.

What this means for Australian engineers

More employer interest. Tech employers that previously didn’t actively recruit in Australia have started to. The relative cost advantage of hiring Australians on E-3 versus other foreigners on H-1B is meaningful.

Faster hiring processes. Some tech employers have streamlined their E-3 sponsorship processes specifically to capture the cost advantage. Australian candidates may experience faster offers and faster onboarding.

Premium positioning. Some Australians have leveraged the E-3 cost advantage in compensation negotiations, recognising that they’re substantially cheaper to sponsor than alternatives.

Increased E-3 demand. Aggregate E-3 demand has increased post-Proclamation, with corresponding pressure on consular appointment availability in Australia.

What hasn’t changed

The substantive E-3 analysis is unchanged:

• Specialty occupation requirements still apply
• LCA wage compliance still applies
• Annual cap of 10,500 still applies (and remains substantially unfilled)
• Consular processing requirements still apply
• The September 2025 changes (interview waivers, third-country processing) still apply

The Proclamation made E-3 more attractive in relative terms; it didn’t make E-3 itself easier or different.

Common ways tech cases fail

The recurring failure patterns specific to tech roles:

SOC 15-1299 used for software engineering. The “Computer Occupations, All Other” catch-all signals that the role doesn’t fit a standard category. Use SOC 15-1252 (Software Developers) for actual software engineering work.

SOC 13-1199 used for Product Manager without strong narrative. “Business Operations Specialists, All Other” requires substantial supporting documentation when used for PM. Either build the documentation comprehensively or shift to a more specific SOC.

Generic role descriptions. “Builds web applications” doesn’t establish specialty. “Designs and implements distributed microservices using Kubernetes orchestration, Go programming language, and Apache Kafka messaging architecture for high-throughput financial transaction processing” does.

Wage level too low for senior roles. A Staff Engineer at Google filed at Level II is anomalous. The wage level should reflect actual seniority.

Designer cases with SOC 27-1024 and weak narrative. Graphic Designer SOC has known E-3 challenges; use SOC 15-1255 (Web and Digital Interface Designers) where appropriate, with strong technical-content narrative.

PM cases with non-CS undergraduate background and no technical narrative. A PM with a humanities undergraduate degree needs explicit framing of the role’s technical content to establish specialty.

Sales engineering cases with sales-coded SOC. Avoid SOC 41-3031 and similar sales-coded options; use 15-1252 with technical-duty emphasis.

Worksite ambiguity for distributed companies. “Remote” or “various” worksites don’t satisfy LCA. List the worker’s actual home address.

Stock compensation attested as wages. Cash base salary alone must meet LCA wage; attesting total comp creates compliance risk.

Engineering Manager promotions without LCA amendment. SOC change from 15-1252 to 11-3021 requires LCA amendment.

MSA moves without amendment. Cross-MSA worksite changes require LCA amendment; failures here create downstream compliance issues.

Australian-to-US transfer cases without independent US analysis. Internal transfer doesn’t substitute for US E-3 specialty-occupation analysis. Each US E-3 case needs to satisfy US standards independently.

Startup cases with thin documentation. First-time E-3 sponsoring startups need careful documentation construction. RFEs are common when documentation is thin.

Big Tech promotion that crosses SOC categories. Senior IC to manager transitions, IC to director transitions — these typically require LCA amendments that are sometimes overlooked.

Equity-only or below-prevailing-wage cash arrangements. Compensation must include sufficient cash wages to meet LCA requirements; equity alone doesn’t satisfy.

Marketing or growth role mistakenly treated as engineering case. Marketing-coded roles need to be analysed under marketing/business SOC codes, not engineering codes, regardless of how technical the marketing work feels.

A final note on case construction

For tech roles, the difference between a clean E-3 case and a problematic one is usually about role classification accuracy and documentation quality. The same Australian software engineer with the same background can have very different outcomes at different employers depending on how the case is constructed.

The patterns that produce successful cases:

• Right SOC code, chosen with reference to actual primary function
• Specific, technical duty descriptions emphasising specialty content
• Wage level matched to actual seniority (typically Level III or IV at major tech employers)
• Educational credentials clearly aligned with specialty (CS, engineering, related quantitative)
• Worksite documentation matching actual work arrangement
• Compensation structured so cash base salary clearly meets LCA wage

The patterns that produce failures:

• Generic SOC codes (15-1299, 13-1199) without strong supporting narrative
• Vague duty descriptions
• Wage levels chosen for fee minimisation rather than role accuracy
• Designer or PM cases without specialty-content emphasis
• Worksite ambiguity for distributed companies
• Equity-heavy compensation structures with insufficient cash wages

For Australian tech workers considering an E-3, the practical advice is to engage with your immigration counsel before the LCA is filed — particularly for any role that’s not core software engineering. The case is much easier to build correctly the first time than to defend after a refusal or RFE.

---

Where this article ends and case-specific advice begins

Everything above is general information about how E-3 cases for tech roles are typically structured and what typically goes wrong. It is not advice on any particular role’s eligibility, any particular SOC code choice, or any particular case strategy. Tech roles span a wide range of profiles, and the borderline cases (PM, Designer, Marketing, Sales Engineering) are particularly fact-specific.

If you’re considering an E-3 for a tech role and want a structured assessment of your case — the right SOC code, the strongest specialty-occupation framing, potential complications, and how to address them — book a free 20-minute consultation and we’ll walk through it. We handle tech E-3 cases as part of our E-3 Essentials and E-3 Complex packages, with the latter typically appropriate for borderline-specialty-occupation cases (PM, Designer, Marketing, Sales Engineering).

A note on legal-determination questions. Whether a specific role qualifies as a specialty occupation, whether a specific SOC code is appropriate, and whether a specific case construction will succeed are case-specific legal determinations that require individual assessment rather than general guidance. We’re happy to provide that assessment in a consultation.

---

Related reading

• The complete E-3 visa guide for Australians
• E-3 specialty occupation: how consuls actually decide
• The Labor Condition Application (LCA) for E-3 visas
• E-3 visa refusals: why they happen and what to do next
• The 3-year Australian degree problem and how to solve it
• The E-3 visa for finance and consulting roles

---

Attorney Advertising. The information on this website is for general informational purposes only and does not constitute legal advice. Use of this website does not create an attorney-client relationship. Communications with the firm are not protected as confidential until a written engagement letter has been signed by both parties. Prior results do not guarantee a similar outcome. Last reviewed 11 May 2026.