SENIOR CONNECTED FIRMWARE DEVELOPER

We need to output HTML fragment with sections: headings

for sections like About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. Use

• for any list of duties/requirements/benefits, and

  for prose. Do NOT repeat job title as heading. Do NOT put Job ID/requisition numbers as headings. Preserve all substantive info; remove boilerplate, navigation, legal, EEO, equal-opportunity, scam-warning, duplicated lines, application instructions. Include a section only when posting has real specific content; never emit heading with filler. Prefer few substantive sections over many thin ones. We need to parse the posting and extract sections. The posting includes: - About Us (company description) – could be "About the role"? Actually "About Us" is company description. Could be "About the role" heading? The instruction says use

  for section headings (e.g. About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule). So we can map sections accordingly. We have: - About Us (company description) – maybe treat as "About the role"? Actually "About the role" is about the job, not company. But we have "About Us" describing company. Could still be under "About the role"? Might be better to have "About the role" containing description of role? But we have "The Opportunity" which describes role. So we could treat "About Us" as company overview maybe not needed? The instruction says include a section only when posting has real specific content. The "About Us" is substantive. Could map to "About the role"? Might be okay. Better to follow the given headings: About the role, Responsibilities, Requirements, Qualifications, Skills, Benefits, Pay, Schedule. We need to extract content for each. Let's parse: - About the role: Could be "The Opportunity" paragraph describing the role. Also maybe "Senior Connected Firmware Developer Needham, MA" location. But we should not repeat job title. So we can put location in a short

  maybe. - Responsibilities: The bullet list under "What You'll Own" includes several subheadings: Connected Firmware Delivery, Platform Implementation, Design Review & Partner Governance, Engineering Standards & Infrastructure, Collaboration & Technical Growth. Each has multiple sentences. Could treat each as responsibility items. - Requirements: Could be "What You'll Bring Experience" and "Technical Expertise" and "Education". Might be split into Requirements and Qualifications and Skills. The instruction says we can have sections for Requirements, Qualifications, Skills. We need to decide mapping. We have: Experience: 5+ years embedded software/firmware, with depth in wireless connectivity or connected-device features. Production connected firmware shipped. Building to architecture defined by others. Consumer electronics/IoT/smart home preferred. CI/CD, automated testing, build infrastructure preferred. Reviewing/integrating code from external partners advantage. Technical Expertise: Strong embedded C; C++ on resource-constrained platforms. Wireless connectivity technologies: Wi-Fi, Bluetooth/BLE, Matter, Thread, Zigbee. Device provisioning, pairing, companion app integration: BLE GATT, Wi-Fi onboarding, cloud device registration/authentication. RTOS. Git-based workflows, CI builds (gcc, CMake, headless), unit testing (Ceedling or equivalent), static analysis. Debug on target hardware — oscilloscopes, logic analyzers, JTAG/SWD, trace. OTA update mechanisms and device security fundamentals. Display technologies and embedded graphics/UI frameworks (a plus). Education: Bachelor's degree in Computer Engineering, Electrical Engineering, Computer Science, or related discipline required. Competencies: Ownership and follow-through, technical rigor, clear written and verbal communication, collaboration across hardware, cloud, and mobile, standards discipline under schedule pressure. Thus we can map: - Requirements: Experience (5+ years, production firmware, etc.) maybe. - Qualifications: Education (Bachelor's degree) maybe. - Skills: Technical Expertise list (languages, technologies, tools) plus Competencies (soft skills). Could combine. But we need to avoid thin sections. Perhaps combine Requirements and Qualifications into one? But instruction says prefer few substantive sections over many thin ones. So we could have sections: About the role, Responsibilities, Requirements (including experience, education, technical skills), Benefits, Pay. Possibly also Skills? But we can incorporate skills into Requirements. We also have Benefits: listed under "The Company offers the following benefits for this position..." includes many items. Pay: Salary range $125,000—$150,000 USD. Schedule: Not mentioned. So we should not include Schedule section. We also have "Our Culture", "What We Offer", "Diversity, Equity, and Inclusion", "Learn More About Us", etc. Those are boilerplate or generic; we should remove. We need to remove duplicated lines, cookie/navigation/legal/EEO/equal-opportunity/scam-warning boilerplate, application instructions. So we cut out sections like "Our Culture", "What We Offer", "At SharkNinja, Diversity, Equity, and Inclusion are vital..." etc. Also "Learn More About Us Life At SharkNinja Outrageously Extraordinary SharkNinja Candidate Privacy Notice..." etc. Also "Apply" at end. Thus final HTML will contain sections: About the role (maybe using "The Opportunity" plus location), Responsibilities (the "What You'll Own" subsections), Requirements (Experience, Education, Technical Expertise, Competencies), Benefits, Pay. We need to use

  for each section heading. Use

  • for any list of duties/requirements/benefits. Use

    for prose. We must preserve all substantive information; do not invent or summarize away detail. So we need to keep the details as given, but we can format them into lists. We must not repeat job title as heading. So we won't have

    Senior Connected Firmware Developer

    . We must not put Job ID/requisition numbers as headings (none present). We need to ensure we don't include filler like "commensurate with experience" etc. Not present. Now craft HTML. First, maybe a short paragraph for location and brief intro: "Needham, MA". Could be in About the role section. Let's structure:

    About the role

    Needham, MA. The Opportunity: This is the hands‑on connected‑firmware role at SharkNinja — you write the code that makes our products connect. Two things sit with you: the connected features SharkNinja deliberately keeps in‑house (wireless connectivity, device provisioning and pairing, over‑the‑air updates, and the differentiated connected experiences that set our products apart), and the platform layer other connected programs depend on (connectivity stacks, provisioning code, and shared app/cloud integration components). The connectivity interface contracts, app/cloud API boundaries, and wireless platform selection criteria are already defined. Your work is building to those decisions: production connected‑feature code end to end, plus the reference implementations that prove the architecture out for every program and partner that follows.

    That seems to capture the Opportunity paragraph. Now Responsibilities: We have several bullet groups. Could create a
    with each responsibility as
    • containing the description. We need to keep the details: Under "What You'll Own" there are headings: Connected Firmware Delivery, Platform Implementation, Design Review & Partner Governance, Engineering Standards & Infrastructure, Collaboration & Technical Growth. Each has multiple sentences. We can make each heading as part of the
    • maybe with or just plain text. Since we cannot add extra tags beyond

      ,

      • ,

        . We can include inside

      • ? The instruction didn't forbid other tags, but to be safe we can just include plain text. Thus:

        Responsibilities

        • Connected Firmware Delivery: Design, implement, and debug production embedded firmware for connected consumer and home appliance products. Connected features end to end — requirements clarification, implementation, unit test, integration, and release support. Building in the retained areas: wireless connectivity, device provisioning and pairing, OTA, and differentiated connected experiences. Development against the connectivity architecture, interface, and app/cloud integration standards — adopting platform components rather than rebuilding them.
        • Platform Implementation: Implement the defined reference architectures and reference implementations — Bluetooth/BLE, Wi‑Fi, Zigbee, Thread, and Matter stacks, plus provisioning and pairing code — reused across product categories. Build and maintain shared connectivity and app/cloud integration components, including BLE GATT profiles, Wi‑Fi onboarding, and cloud device registration. Build to the defined interface contracts and platform decisions. Prototype new connectivity and app‑integration technologies to de‑risk decisions ahead of program commitment.
        • Design Review & Partner Governance: Participate in technical design reviews for internal and partner‑developed connected firmware. Review partner‑delivered connected code and integrate it against SharkNinja standards. Turn architectural intent into working reference code and shipped connected features that partners and other programs can build against without interpretation. Support partner technical capability assessments for wireless and app‑integration subsystems.
        • Engineering Standards & Infrastructure: Write unit tests and maintain code coverage against the standard applied across internal and supplier code; resolve static analysis findings, with no unresolved critical or high‑severity issues at release. Build and maintain CI pipeline, static analysis configuration, and interoperability test‑harness infrastructure for owned connected features and platform components. Verify the reproducibility standard in practice — confirm that source, toolchain, and build manifest deliverables actually rebuild the shipping binary. Work in feature branches with PR‑gated merges, ticket‑linked commits, and commit messages sufficient to generate release notes.
        • Collaboration & Technical Growth: Work under the technical direction of Principal Engineers on connected platform capabilities and design review, building toward broader architectural scope over time. Bring up firmware on target hardware and debug hardware‑software‑app integration issues with Hardware Engineering, Cloud, and Mobile App teams. Support certification activities — Bluetooth SIG, Wi‑Fi Alliance, Matter — with hands‑on testing and issue resolution. Coordinate with firmware engineers in other regions to drive continuous improvement.
        Now Requirements: We'll combine Experience, Education, Technical Expertise, Competencies. We could split into sub-sections but maybe just one Requirements section with lists. We need to preserve all details. Let's create a
        with items for each bullet. But we need to avoid too thin sections; but we can have one Requirements section with multiple
        • each covering a category. We could have:

          Requirements

          • Experience: 5+ years of embedded software and firmware development, with meaningful depth in wireless connectivity or connected‑device features. Production connected firmware you've delivered and shipped in commercial products. Building to an architecture defined by others — implementing connectivity stacks, provisioning flows, or app/cloud integration from documented interface contracts. Consumer electronics, IoT devices, smart home products, or comparable connected high‑volume products (preferred). CI/CD, automated testing, or build infrastructure for embedded systems (strongly preferred). Reviewing or integrating code from external development partners (an advantage).
          • Education: Bachelor's degree in Computer Engineering, Electrical Engineering, Computer Science, or a related discipline required.
          • Technical Expertise: Strong embedded C; C++ on resource‑constrained platforms. Wireless connectivity technologies: Wi‑Fi, Bluetooth/BLE, Matter, Thread, Zigbee. Device provisioning, pairing, and companion app integration: BLE GATT, Wi‑Fi onboarding, cloud device registration and authentication. Real‑Time Operating Systems (RTOS). Git‑based workflows, CI builds (gcc, CMake, headless), unit testing (Ceedling or equivalent), static analysis. Debug on target hardware — oscilloscopes, logic analyzers, JTAG/SWD, trace. OTA update mechanisms and device security fundamentals for connected products. Display technologies and embedded