Devices, Platforms and This Role

Device platform engineering is building the software that lets a fleet of hardware be set up, controlled, monitored and updated: the on-device web UI an admin opens in a browser, the REST and command-line APIs that integrators script against, the agent that talks to cloud management, and the glue between all of that and the operating system underneath. It's full stack work, but the "server" is a video bar bolted above a TV in a meeting room, and there are tens of thousands of them, in buildings you'll never visit.

A good mental model: a web app is a restaurant; a device fleet is a meal-kit company. In a restaurant everyone eats in your building, and when you change the recipe every customer gets the new dish at the next meal. A meal-kit company ships boxes to thousands of kitchens it never sees. Each kitchen cooks whatever version of the kit it last received, with its own oven, its own quirks, and sometimes a box that has been sitting in the cupboard for months. You can't walk in and fix a dish; you can only send a better box and hope it gets opened.

That changes the engineering. On a web service there is one version in production (or two, during a deploy), rollback is a button, and logs are a query away. On a device fleet many versions are live at once for years, some updates are one-way, the device may be offline or behind a firewall when you need it, and other companies sit in your release path. HP says Poly VideoOS 5.0 "establishes the foundation for future updates to Android 17 and support through 2032" (HP newsroom, 3 February 2026): a release shipped in 2026 is planned to be supported for six more years.

Those rows come from real public facts about the platform this role works on:

• Updates are not always automatic. Poly's configuration guide lists upgrade.auto.enable with the default "False (Teams and Zoom default)" and "True (All other conferencing providers default)" (Poly VideoOS Configuration Parameter Reference Guide 4.1.0, HP, PDF dated November 2023). A Teams or Zoom room waits for an admin.
• Partners deliver firmware. Microsoft says Android OS and firmware updates for Teams devices "are provided by hardware Original Equipment Manufacturers (OEM) to Microsoft for certification" and then distributed through the Teams Admin Center (Microsoft Learn, "Android versioning support for Teams devices", last updated 28 September 2026). The HP Support Community's post for 5.0.0 says the release "will be delivered initially via the Microsoft Teams Admin Center" (community knowledge-base post "PolyOS 5.0.0", 6 May 2026).
• Some upgrades can't be undone. "Once you update your system to Poly VideoOS 5.0.0, you cannot downgrade" (Poly VideoOS Software Release Notes 5.X, HP Support, read 27 October 2026).

The model below shows what that means for the versions in the field. A thousand devices get a new release, 4.6. Forty percent update themselves through a staged rollout; the rest wait for an admin, as Teams and Zoom rooms do by default. Five percent are unreachable in any given week.

// A fleet of 1,000 room devices gets a new release (4.6). Who is on what, week by week?
// Seeded PRNG (mulberry32) so the output is the same on every run.
function mulberry32(seed) {
  return () => {
    seed |= 0; seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = mulberry32(42);

// Starting mix of versions, and how each device gets updates.
const fleet = Array.from({ length: 1000 }, (_, id) => {
  const r = rand();
  return {
    id,
    version: r < 0.5 ? "4.5" : r < 0.8 ? "4.4" : "4.3",
    autoUpdate: rand() < 0.4, // the rest wait for an admin to push the update
    ring: rand(), // position in the staged rollout: 0..1
  };
});

// Staged rollout for auto-updating devices: share of the fleet eligible each week.
const eligibleShare = [0, 0.01, 0.1, 0.5, 1];
const share = (week) => eligibleShare[Math.min(week, eligibleShare.length - 1)];

console.log("week  on 4.6   versions in the field");
for (let week = 0; week <= 12; week++) {
  for (const d of fleet) {
    if (d.version === "4.6") continue;
    const online = rand() > 0.05; // 5% are switched off or unreachable in any given week
    if (!online) continue;
    if (d.autoUpdate && d.ring < share(week) && rand() < 0.9) d.version = "4.6";
    else if (!d.autoUpdate && week >= 2 && rand() < 0.12) d.version = "4.6";
  }
  if (week % 2 === 0 || week === 1) {
    const counts = {};
    for (const d of fleet) counts[d.version] = (counts[d.version] ?? 0) + 1;
    const mix = Object.keys(counts).sort().map((v) => `${v}:${counts[v]}`).join(" ");
    console.log(`${String(week).padStart(4)}  ${String((counts["4.6"] ?? 0) / 10).padStart(5)}%   ${mix}`);
  }
}
const old = fleet.filter((d) => d.version !== "4.6");
console.log(`after 12 weeks: ${old.length} devices still on an older version (${old.filter((d) => d.version === "4.3").length} on 4.3)`);

week  on 4.6   versions in the field
   0      0%   4.3:188 4.4:289 4.5:523
   1    0.2%   4.3:188 4.4:289 4.5:521 4.6:2
   2    9.2%   4.3:172 4.4:269 4.5:467 4.6:92
   4   53.2%   4.3:88 4.4:139 4.5:241 4.6:532
   6   66.2%   4.3:69 4.4:98 4.5:171 4.6:662
   8   72.8%   4.3:49 4.4:77 4.5:146 4.6:728
  10   77.3%   4.3:41 4.4:71 4.5:115 4.6:773
  12     82%   4.3:36 4.4:53 4.5:91 4.6:820
after 12 weeks: 180 devices still on an older version (36 on 4.3)

Every managed device, whether it's a video bar, a printer, a router or a smart thermostat, has the same handful of parts. Front doors take requests: a web server for the admin UI, a REST API for software, a command line for scripts and room control systems. A security layer decides who's asking and what they may do. A command and settings layer does the actual work, with one set of rules behind every door. A config store holds settings in layers (defaults, local changes, centrally provisioned values). Platform services own the hardware: camera, audio, network, the update engine. A device agent keeps an outbound connection to cloud management and provisioning. Underneath sit the operating system and signed firmware images.

A good mental model: a small office building with one filing cabinet. There's a front desk (web UI), a mail slot (REST) and a phone line (CLI); a security guard checks everyone (auth); one office manager handles every request the same way whichever door it came through (command layer); the filing cabinet holds the current settings, with head office's instructions on top (config store with provisioned values); the workshop in the basement does the physical work (platform services); and a courier visits head office every day for new instructions and parcels (device agent). If each door had its own manager and its own filing cabinet, the building would soon disagree with itself.

Here is what each part does, and the public Poly facts that show it on a real product (all from HP's Poly documentation, cited in the next topic):

The model below builds the middle of that picture in about sixty lines: one config store with layers, written by a REST API, a command line and a provisioning push, with a platform service reacting to a change. It runs with Express 5 and supertest from the site's sandbox; supertest calls the app without opening a fixed port.

// A managed device in miniature: one config store, written by a REST API, a command line and a provisioning
// server, with a platform service reacting to changes. Setting names come from Poly's public parameter guide;
// everything else here is a teaching model, not Poly's implementation.
import express from "express";
import request from "supertest";

const schema = {
  "device.local.deviceName": { type: "string", default: "Room-101" },
  "sec.telnet.enable": { type: "boolean", default: false },
  "sec.web.idleSessionTimeout": { type: "enum", values: [1, 3, 5, 10, 15, 20, 30, 45, 60], default: 10 },
};

// The config store: three layers, highest wins. Provisioned values are read-only for local writers.
const layers = { provisioned: {}, local: {} };
const listeners = [];
const read = (name) => {
  const source = name in layers.provisioned ? "provisioned" : name in layers.local ? "local" : "default";
  const value = source === "default" ? schema[name].default : layers[source][name];
  return { name, value, source, editable: source !== "provisioned" };
};
function write(name, value, writer) {
  const def = schema[name];
  if (!def) return { error: "UNKNOWN_SETTING" };
  const ok = def.type === "enum" ? def.values.includes(value) : typeof value === def.type;
  if (!ok) return { error: "INVALID_VALUE" };
  if (writer !== "provisioning" && name in layers.provisioned) return { error: "READ_ONLY_PROVISIONED" };
  layers[writer === "provisioning" ? "provisioned" : "local"][name] = value;
  for (const fn of listeners) fn(name, value);
  return read(name);
}

// A platform service that owns the Telnet listener and reacts to the setting.
listeners.push((name, value) => {
  if (name === "sec.telnet.enable") console.log(`  platform: telnet listener ${value ? "started on port 24" : "stopped"}`);
});

// Front door 1: REST.
const app = express();
app.use(express.json());
app.get("/api/config/:name", (req, res) => (schema[req.params.name] ? res.json(read(req.params.name)) : res.sendStatus(404)));
app.put("/api/config/:name", (req, res) => {
  const result = write(req.params.name, req.body.value, "rest");
  const status = { UNKNOWN_SETTING: 404, INVALID_VALUE: 422, READ_ONLY_PROVISIONED: 409 }[result.error] ?? 200;
  res.status(status).json(result);
});

// Front door 2: a line-based command interface over the same store.
function cli(line) {
  const [verb, name, raw] = line.split(" ");
  if (verb === "get") return `${name} ${read(name).value}`;
  const value = raw === "true" ? true : raw === "false" ? false : /^\d+$/.test(raw) ? Number(raw) : raw;
  const result = write(name, value, "cli");
  return result.error ? `error: ${result.error}` : `ok ${name} ${result.value}`;
}

const show = (r) => console.log(`REST ${r.req.method} ${r.req.path} -> ${r.status} ${JSON.stringify(r.body)}`);
show(await request(app).get("/api/config/device.local.deviceName"));
console.log(`CLI  set device.local.deviceName Board-Room -> ${cli("set device.local.deviceName Board-Room")}`);
show(await request(app).get("/api/config/device.local.deviceName"));
console.log("PROV push sec.web.idleSessionTimeout=30 ->", write("sec.web.idleSessionTimeout", 30, "provisioning").source);
show(await request(app).put("/api/config/sec.web.idleSessionTimeout").send({ value: 10 }));
console.log(`CLI  set sec.telnet.enable yes -> ${cli("set sec.telnet.enable yes")}`);
show(await request(app).put("/api/config/sec.telnet.enable").send({ value: true }));
console.log(`CLI  get sec.telnet.enable -> ${cli("get sec.telnet.enable")}`);

REST GET /api/config/device.local.deviceName -> 200 {"name":"device.local.deviceName","value":"Room-101","source":"default","editable":true}
CLI  set device.local.deviceName Board-Room -> ok device.local.deviceName Board-Room
REST GET /api/config/device.local.deviceName -> 200 {"name":"device.local.deviceName","value":"Board-Room","source":"local","editable":true}
PROV push sec.web.idleSessionTimeout=30 -> provisioned
REST PUT /api/config/sec.web.idleSessionTimeout -> 409 {"error":"READ_ONLY_PROVISIONED"}
CLI  set sec.telnet.enable yes -> error: INVALID_VALUE
  platform: telnet listener started on port 24
REST PUT /api/config/sec.telnet.enable -> 200 {"name":"sec.telnet.enable","value":true,"source":"local","editable":true}
CLI  get sec.telnet.enable -> sec.telnet.enable true

This topic is the product briefing: what HP's public Poly documentation says about the devices, the software they run, the modes they run in and the ways they're managed and scripted. Every fact below is from a public HP, Microsoft or Google source, named with its date; the sources were read on 27 October 2026. Posts in the HP Support Community's Poly knowledge base are cited as community posts: HP hosts them, but each carries HP's disclaimer that it gives "the personal opinions of the authors, not of HP", so they're not official documentation. Where the public documentation doesn't say something, this page says so instead of guessing. Nothing here is internal HP information, and the role's internal project name ("Project Trinity" in the job description) doesn't appear in any public source I could find.

A useful mental model for the product line: one Android-based platform wearing different hats. The same family of room systems can boot into Poly's own video app, into Microsoft Teams Rooms, into Zoom Rooms or another partner's app, or act as a USB camera and speaker for a laptop. The hardware and the platform underneath (settings, web UI, APIs, management, updates) stay Poly's; the conferencing app on top changes with the "provider" the admin chooses. Most of the web UI and API work in this role is that platform layer.

The company and the product lines

HP completed its acquisition of Poly on 29 August 2022 (HP press release, 29 August 2022: an all-cash deal at $40 a share, "implying a total enterprise value of approximately $3.3 billion, inclusive of Poly's net debt"). Poly's documentation has since moved to HP Support, and newer documents and announcements say "HP Poly".

The admin guides (Poly Partner Mode Administrator Guide 4.7.0, HP, "Last update: September 2026", and Poly Video Mode Administrator Guide 4.7.0, HP, "Last update: July 2025"; both PDFs downloaded from HP in October 2026) describe these room systems and accessories:

HP's community post for 5.0.0 calls the X32, X52, X72 and G62 the second-generation systems ("A Gen2 device, aka a Studio G62, Studio X32, Studio X52 or Studio X72"); the official release notes simply list those four models. That split matters for the OS story below.

The software: Poly VideoOS, also called PolyOS

The official name in HP's release notes and guides is Poly VideoOS. The HP Support Community's knowledge-base posts title the same releases "PolyOS" (for example "PolyOS 5.0.0" with the build string PolyOS 5.0.0-418922), and Google's 2023 announcement said "Poly OS 4.0". The role description uses PolyOS; treat the names as the same product line. The touch controllers run a separate OS, Poly TCOS.

It runs on Android. The public evidence:

• Poly VideoOS 5.0.0 (release date May 2026) "contains an Android 13 update for only Poly Studio G62, Poly Studio X32, Poly Studio X52, and Poly Studio X72 systems", and "Your system updates from Android 10 to Android 13 and your Poly TC10 touch controller updates from Android 11 to Android 12" (Poly VideoOS Software Release Notes 5.X, HP Support).
• 5.0.0 "supports only Microsoft Teams and Poly Device Mode. Your device must be in one of these modes to upgrade successfully." The HP Support Community's post for the release lists the providers not supported on 5.0.0: Poly/SIP, Google Meet, RingCentral, Dialpad, GoTo Meeting and Tencent (community knowledge-base post "PolyOS 5.0.0", 6 May 2026; not official documentation).
• The upgrade path: "Your system must be running Poly VideoOS 4.6.0 before updating to Poly VideoOS 5.0.0", and a system on an earlier version "automatically loads VideoOS 4.6.0" first. It's one-way: "Downgrading from Poly VideoOS 5.x to Poly VideoOS 4.x versions isn't supported", and the release "also updates the system's factory restore partition", so a factory restore doesn't go back to 4.x either.
• "Partner applications are no longer bundled in the main software package. The partner application downloads once you upgrade", from swupdate.lens.poly.com.
• The first-generation systems stay on 4.x: "Poly Studio X30, Poly Studio X50, Poly Studio X70, Poly G7500 or Poly TC8 are incompatible with PolyOS 5.0.0" (community knowledge-base post "PolyOS 5.0.0", 6 May 2026; the official notes say only that the four Gen2 models support 5.0.0, without naming the others).
• Poly VideoOS 5.0.1 (August 2026) is a maintenance release, still Teams and Device Mode only; one fix it lists is "the device shows as offline in Poly Lens cloud after upgrading" (PVENG-41383).
• Poly VideoOS 4.7.0 (June 2026) is a "sustaining release" for "all Poly and partner modes", on both generations. It added a switch to turn off the REST API's XSRF token requirement (more on that below) and "HP Direct Connect" for Teams Rooms touch controllers (community knowledge-base post "PolyOS 4.7.0", 18 June 2026; its fixes cover the G7500 and X30/X50/X70 as well as the Gen2 systems). Its fixes include testing "against both the CVE-2025-48543 Android Runtime Use-After-Free vulnerability and CVE-2024-43093", another sign that 4.x is Android-based.
• HP's ISE announcement says Poly VideoOS 5.0 "delivers a major platform upgrade to Android 13", "establishes the foundation for future updates to Android 17 and support through 2032", and "lays the foundation for Poly VideoOS 5.1, including HP Poly DirectorAI multi-camera automatic switching" (HP newsroom, 3 February 2026). The same post said 5.0 "will be available in February 2026"; the release notes give 5.0.0's release date as May 2026.

Microsoft's certification dates explain some of the pressure on the platform. Microsoft lists, for Teams devices on Android, a certification end date of 3 September 2026 for Android 10 and Android 11 (support ends 3 September 2027), and 15 August 2028 for Android 12 and 13 (support ends 15 August 2030) (Microsoft Learn, last updated 28 September 2026). The Android 10 and 11 date had already been extended once, from 3 September 2025, and the same table lists Android 17 (certification end 16 June 2031), the version HP names as 5.x's future target. HP's notes don't connect 5.0's Teams-first scope to those dates; that link is my inference, and a reasonable question to ask.

Provider modes

A Poly room system runs in Poly Video Mode (Poly's own conferencing app, SIP and H.323) or in Partner Mode, where "Poly Partner Mode allows you to run third-party conferencing applications on supported Poly video systems" (Partner Mode Administrator Guide 4.7.0). The choice is one setting. The configuration guide lists management.provider.select with these values: Poly, Zoom Rooms, Microsoft Teams, GoToRoom, RingCentral Rooms, Device Mode, StarLeaf, BlueJeans Rooms (beta) and Dialpad Conference Room (Poly VideoOS Configuration Parameter Reference Guide 4.1.0, November 2023). That list has moved since 2023:

• "As of Poly VideoOS 4.2.0, BlueJeans is no longer supported", and systems still using it "automatically update to Poly Video Mode" (Partner Mode Administrator Guide 4.7.0).
• Google Meet arrived on the Android-based Studio X30, X50 and X70 with the 4.0 release: "the Google Meet hardware experience will become available in the upcoming Poly OS 4.0 update" (Google Workspace Updates, 9 March 2023).
• Not every provider runs on every system: "Dialpad and Google Meet aren't supported on Poly G7500 systems" and "Poly Studio G62 is certified for Microsoft Teams Rooms, Zoom Rooms, and Tencent only" (Partner Mode Administrator Guide 4.7.0).
• Device Mode turns the room system into a USB camera, microphone and speaker for a laptop. It's available alongside a provider (the guide has "Disable Device Mode to stop the system from being used as an external camera, microphone, and speaker") and as a provider of its own.

The mode decides more than the app on screen. Some settings only apply in one mode ("You can't provision this parameter if the system is in Partner Mode"), some features only exist in one (the community FAQ notes a Miracast/AirPlay REST example "will only work in Poly Provider mode"), and the 5.0.0 upgrade itself depends on the mode. For a web UI and API that means capabilities depend on mode as well as model and version.

How the devices are managed

The public guides describe five ways in:

• The system web interface. "Open a web browser and enter the system's IP address", sign in as admin; the default password "is the last six characters of your system's serial number", and Poly says to change it. "Unlike the local interface, you can configure every setting through the system web interface." Port 80 "Redirects all sessions to HTTPS on port 443" (Partner Mode Administrator Guide 4.7.0).
• Poly Lens. "Poly Lens Cloud provides cloud-based management and insights for your system." A system can be registered during setup or later, and it "remains registered with Poly Lens even after a reset or factory restore." HP describes Lens as "a single management platform" for "settings, firmware updates, and device health" (HP newsroom, 3 February 2026).
• A provisioning service such as Poly Clariti Manager. The system registers at an address of the form https://<server>/ucservice, after which "Provisioned settings are read-only in the system web interface" and the system "automatically checks for and runs software updates every time it restarts and at an interval set by the service."
• Zero Touch Onboarding. On first boot "the system contacting the Poly Zero Touch Onboarding (ZTO) server to determine its mode of operation". The firewall must allow port 443 to zto.poly.com, lens.poly.com and the software download site, and an NTP server is required. During setup the system tries "Zero Touch Onboarding, Poly Lens, then DHCP" in that order.
• The partner's console. In Teams mode, Microsoft says OEM firmware is "distributed through Microsoft Teams Admin Center (TAC) or Teams Rooms Pro management portal (PMP)" (Microsoft Learn, last updated 28 September 2026), and the community post for 5.0.0 says it was delivered "initially via the Microsoft Teams Admin Center".

The documented APIs

REST. The Poly VideoOS REST API Reference Guide (HP document P55757-001A, "Last update: August 2025") covers the G62, G7500, X30, X32, X50, X52, X70 and X72, and describes "the configuration parameters and API commands for Poly VideoOS version 4.4.0". The points worth remembering:

• "The REST API feature is never disabled." "Administrator credentials are required", and "You need a session ID using /rest/session/ to pass API commands to the system."
• Bodies are JSON, and "The REST API cannot accept more than 10 MB of data."
• The guide's sections are Audio, Calendar, Cameras, Collaboration, Conferences, Directory, Session, System, SysTracker (GET /rest/mediastats) and Video; all 107 documented commands are HTTPS with access level Admin. Examples: GET /rest/audio, GET /rest/system/status, POST /rest/system/reboot with {"action": "reboot"}, POST /rest/system/network/ping, GET /rest/system/logs, and GET/POST/DELETE /rest/system/mode/device to read, start and stop Device Mode.
• The error table maps codes to meanings, some of them Poly's own: 404 Unavailable ("Operation or source unavailable"), 415 Error ("Payload invalid or missing one or more required fields"), 501 Not Implemented, 507 Insufficient Storage.
• Since VideoOS 4.6.2 the REST API wants an XSRF token. The community FAQ for the REST API says "Since PolyOS 4.6.2 added X-XSRF-Token to the REST API to prevent Cross-Site Request Forgery attacks", and its examples log in, keep the session_id and XSRF-TOKEN cookies, and send the token back in an X-XSRF-TOKEN header (community knowledge-base post "[FAQ] Rest API for G7500 and Studio X or Studio G62", 8 January 2026, which says the community "is not the official documentation source and is maintained by volunteers and enthusiasts"). The FAQ's examples send the header on every call, GET /rest/system included; the public material I found doesn't say whether reads without it are refused, so don't claim it's "state-changing calls only". The 4.7.0 release post adds a setting under Security > Access, "Require X-XSRF Authentication Token When Using REST API", on by default, with "HP Poly recommends leaving this setting as enabled."

Command line. The Video Mode Administrator Guide 4.7.0 documents a command-line API over SSH, Telnet or a serial port:

• "Use SSH on port 22 if you want encrypted access to the system command-line API" (the setting is "Enable Legacy API Over SSH"). "Use port 24 or 23 to access the system command-line API using telnet", 24 being the default.
• Both are off by default: sec.telnet.enable and sec.ssh.enable default to False in the configuration guide, and the port table lists ports 22, 23 and 24 as not open by default.
• Telnet asks for a password by default, but "you can't restrict telnet access in other ways, such as locking its port for too many failed login attempts (like you can with web or SSH access)"; a session "disconnects after three failed login attempts."
• An RS-232 port in "Control" mode lets "any device connected to the RS-232 port to control the system using API commands"; the Studio G62 and the X-series bars "don't have a serial port." Unlike SSH and Telnet, the serial port isn't off by default: device.serial.mode defaults to "Control" (Configuration Parameter Reference Guide 4.1.0).
• The command reference itself is the "Poly G7500 Command-Line API Reference Guide"; I couldn't open a current copy, so this page doesn't list its commands. The community FAQ gives one example, addrbook all, which "will return all the Speed Dials added to the system."

What the public documentation doesn't say

• How the web UI, the REST API and the command line are built on the device: which processes serve them, whether they share one command layer, how they reach Android system services.
• Anything about "Project Trinity", the team structure, or the plan for the 4.x → 5.x work beyond what the release notes state.
• Why the role description's Android 11 differs from the release notes' Android 10 (see the note above).
• How the session ID is meant to be sent: the REST guide shows the login response with a sessionId but doesn't say. The community FAQ's examples use the session_id cookie.
• When the other providers reach 5.x. HP's February 2026 post names 5.1 and DirectorAI, not a provider schedule.

When an interviewer asks about any of these, say what's public and then how you'd design it, labelled as your design.

The documented REST session, from the outside

Here is the documented login and call sequence, played against a simulated device: a small Express server I wrote that behaves the way the REST guide and the community FAQ describe (session cookie after POST /rest/session, then an XSRF token). The model asks for the token only on state-changing calls, the usual double-submit design; whether the real device also wants it on reads isn't documented. It is not Poly's code, it runs over plain HTTP on localhost where the real device uses HTTPS with its own certificate, and the status codes for the failure cases are my choice.

// The session flow Poly documents for its REST API (POST /rest/session, a session cookie, and since VideoOS 4.6.2
// an X-XSRF-TOKEN header), played against a SIMULATED device. The server is a teaching model, not Poly's code.
import express from "express";
import { randomUUID } from "node:crypto";

const sessions = new Map(); // sessionId -> { user, xsrf }
const cookies = (req) => Object.fromEntries((req.headers.cookie ?? "").split("; ").filter(Boolean).map((c) => c.split("=")));

const device = express();
device.use(express.json({ limit: "10mb" })); // the public guide: the API "cannot accept more than 10 MB"
device.post("/rest/session", (req, res) => {
  if (req.body.user !== "admin" || req.body.password !== "S3cret!") return res.status(403).json({ success: false });
  const sessionId = randomUUID();
  const xsrf = randomUUID();
  sessions.set(sessionId, { user: "admin", xsrf });
  res.append("Set-Cookie", `session_id=${sessionId}; HttpOnly; Secure; Path=/`);
  res.append("Set-Cookie", `XSRF-TOKEN=${xsrf}; Secure; Path=/`); // readable by the page's script, on purpose
  res.json({ success: true, session: { role: "ADMIN", isAuthenticated: true } });
});
device.use("/rest", (req, res, next) => {
  const session = sessions.get(cookies(req).session_id);
  if (!session) return res.status(403).json({ error: "not authenticated" });
  const unsafe = !["GET", "HEAD"].includes(req.method);
  if (unsafe && req.get("X-XSRF-TOKEN") !== session.xsrf) return res.status(403).json({ error: "missing or wrong XSRF token" });
  next();
});
device.get("/rest/system", (req, res) => res.json({ model: "SimulatedBar", softwareVersion: "4.6.2", state: "READY", rebootNeeded: false }));
device.post("/rest/system/reboot", (req, res) => res.json({ accepted: req.body.action === "reboot" }));

const server = device.listen(0, "127.0.0.1"); // an explicit address: the port is then free on 127.0.0.1 too
await new Promise((resolve) => server.once("listening", resolve)); // the port is known once it's listening
const base = `http://127.0.0.1:${server.address().port}`;
const jar = {};
async function call(method, path, body, headers = {}) {
  const res = await fetch(base + path, {
    method,
    headers: { "Content-Type": "application/json", Cookie: Object.entries(jar).map(([k, v]) => `${k}=${v}`).join("; "), ...headers },
    body: body && JSON.stringify(body),
  });
  for (const c of res.headers.getSetCookie()) { const [k, v] = c.split(";")[0].split("="); jar[k] = v; }
  console.log(`${method.padEnd(4)} ${path.padEnd(20)} ${res.status} ${await res.text()}`);
}

await call("GET", "/rest/system");
await call("POST", "/rest/session", { user: "admin", password: "wrong" });
await call("POST", "/rest/session", { user: "admin", password: "S3cret!" });
console.log(`     cookie jar now holds: ${Object.keys(jar).join(", ")}`);
await call("GET", "/rest/system");
await call("POST", "/rest/system/reboot", { action: "reboot" });
await call("POST", "/rest/system/reboot", { action: "reboot" }, { "X-XSRF-TOKEN": jar["XSRF-TOKEN"] });
server.close();

GET  /rest/system         403 {"error":"not authenticated"}
POST /rest/session        403 {"success":false}
POST /rest/session        200 {"success":true,"session":{"role":"ADMIN","isAuthenticated":true}}
     cookie jar now holds: session_id, XSRF-TOKEN
GET  /rest/system         200 {"model":"SimulatedBar","softwareVersion":"4.6.2","state":"READY","rebootNeeded":false}
POST /rest/system/reboot  403 {"error":"missing or wrong XSRF token"}
POST /rest/system/reboot  200 {"accepted":true}

On a device, "the back end" isn't a cluster in a data centre; it's the services inside the box that own settings and hardware. When an admin clicks Save on the network page of the on-device web UI, the request goes from the browser to the device's web server, through authentication and validation, into a settings service that records the change, and from there to a platform service that actually switches the radio off, usually in another process reached over inter-process communication (on Android, typically a bound service over Binder; see Talking to platform services). Then the result has to come back: to the browser that asked, and to every other screen showing the same setting.

A good mental model: an order in a restaurant kitchen. The waiter (web server) takes the order to the pass; the host has already checked the reservation (auth); the order is checked against the menu (validation); the kitchen manager writes it on the board (settings store, version 7 → 8); the right station cooks it (platform service); the bell rings so every waiter sees the board changed (event); and only then does the waiter tell the customer it's done. If the station can't cook it (the radio is busy), the manager rubs it off the board and the waiter says "not right now, try again in five minutes" (rollback, 503 with Retry-After). What you must never do is tell the customer "done" when the order is only on the board.

That sequence is drawn below. Public Poly documentation doesn't describe the internals of its own devices, so this is the general design of a device's request path, not a description of PolyOS.

The model below runs that path in Node: Express is the device's web server and API layer, a settings service stages, applies and commits, and a stand-in for an OS service plays the platform's part. A fake clock adds a cost per step so the timings are readable and identical on every run; the "IPC" is a plain async function call.

// One "Save" click traced through the layers of a device: web server -> auth -> validation -> settings service ->
// platform service (a stand-in for an OS service reached over IPC) -> event to the UI. A teaching model.
import express from "express";
import request from "supertest";

let clock = 0; // fake milliseconds, so the trace is identical on every run
const trace = (layer, msg, cost = 0) => { clock += cost; console.log(`  t=${String(clock).padStart(3)}ms ${layer.padEnd(9)} ${msg}`); };

// The platform side: owns the radio. The web stack never touches hardware directly.
const networkService = {
  wifiEnabled: true,
  busy: false,
  async setWifiEnabled(on) {
    trace("platform", `NetworkService.setWifiEnabled(${on}) via IPC`, 2);
    if (this.busy) { trace("platform", "-> ERROR_BUSY (radio is scanning)", 40); throw Object.assign(new Error("busy"), { code: "ERROR_BUSY" }); }
    this.wifiEnabled = on;
    trace("platform", "-> OK, radio state changed", 120);
  },
};

// The settings service: validates, persists, applies, and rolls back if the platform refuses.
const store = { values: { "wifi.enabled": true }, version: 7 };
const subscribers = [(e) => trace("event", `-> UI socket: ${JSON.stringify(e)}`, 1)];
async function applySettings(patch) {
  const before = { ...store.values };
  Object.assign(store.values, patch);
  trace("settings", `staged ${JSON.stringify(patch)} (config v${store.version} -> v${store.version + 1})`, 3);
  try {
    if ("wifi.enabled" in patch) await networkService.setWifiEnabled(patch["wifi.enabled"]);
  } catch (err) {
    store.values = before;
    trace("settings", `rolled back to v${store.version}`, 1);
    throw err;
  }
  store.version++;
  for (const s of subscribers) s({ type: "settings.changed", version: store.version, keys: Object.keys(patch) });
}

const app = express();
app.use((req, res, next) => { clock = 0; trace("web", `${req.method} ${req.path} (TLS ended at the on-device server)`); next(); });
app.use(express.json());
app.use((req, res, next) => {
  if (req.get("Cookie") !== "session_id=abc") return res.status(401).json({ title: "Not signed in" });
  if (req.get("X-XSRF-TOKEN") !== "t1") return res.status(403).json({ title: "Bad XSRF token" });
  trace("auth", "session abc -> role ADMIN, XSRF ok", 1);
  next();
});
app.patch("/api/v1/settings", async (req, res) => {
  const bad = Object.entries(req.body).find(([k, v]) => k !== "wifi.enabled" || typeof v !== "boolean");
  if (bad) return res.status(422).json({ title: "Invalid setting", detail: bad[0] });
  trace("validate", "body matches the settings schema", 1);
  try {
    await applySettings(req.body);
    trace("web", "200 sent", 1);
    res.json({ version: store.version, restartRequired: false });
  } catch (err) {
    trace("web", "503 sent (retryable)", 1);
    res.status(503).set("Retry-After", "5").json({ type: "/problems/platform-busy", title: "Device busy", code: err.code });
  }
});

const save = (body) => request(app).patch("/api/v1/settings").set("Cookie", "session_id=abc").set("X-XSRF-TOKEN", "t1").send(body);
console.log("Save #1:");
let r = await save({ "wifi.enabled": false });
console.log(`  => ${r.status} ${JSON.stringify(r.body)}  wifi=${networkService.wifiEnabled}`);
console.log("Save #2 (radio busy):");
networkService.busy = true;
r = await save({ "wifi.enabled": true });
console.log(`  => ${r.status} ${JSON.stringify(r.body)}  wifi=${networkService.wifiEnabled} stored=${store.values["wifi.enabled"]}`);

Save #1:
  t=  0ms web       PATCH /api/v1/settings (TLS ended at the on-device server)
  t=  1ms auth      session abc -> role ADMIN, XSRF ok
  t=  2ms validate  body matches the settings schema
  t=  5ms settings  staged {"wifi.enabled":false} (config v7 -> v8)
  t=  7ms platform  NetworkService.setWifiEnabled(false) via IPC
  t=127ms platform  -> OK, radio state changed
  t=128ms event     -> UI socket: {"type":"settings.changed","version":8,"keys":["wifi.enabled"]}
  t=129ms web       200 sent
  => 200 {"version":8,"restartRequired":false}  wifi=false
Save #2 (radio busy):
  t=  0ms web       PATCH /api/v1/settings (TLS ended at the on-device server)
  t=  1ms auth      session abc -> role ADMIN, XSRF ok
  t=  2ms validate  body matches the settings schema
  t=  5ms settings  staged {"wifi.enabled":true} (config v8 -> v9)
  t=  7ms platform  NetworkService.setWifiEnabled(true) via IPC
  t= 47ms platform  -> ERROR_BUSY (radio is scanning)
  t= 48ms settings  rolled back to v8
  t= 49ms web       503 sent (retryable)
  => 503 {"type":"/problems/platform-busy","title":"Device busy","code":"ERROR_BUSY"}  wifi=false stored=false

An OS migration on a device platform means moving everything that runs on the old OS (the web UI server, the APIs, the device agent, the platform integrations, the partner apps) to a new OS version, and then moving the fleet. On this role's platform that's PolyOS 4.x to 5.x, with the Android version underneath jumping several releases at once (the public 5.0.0 notes say Android 10 → 13 on the second-generation systems). The work has three parts that interviewers will probe: parity (does everything that worked before still work?), compatibility (do old scripts, integrations, settings and peripherals still work against the new build?) and phased rollout (how do you move tens of thousands of devices without breaking meeting rooms, when the upgrade can't be undone?).

A good mental model: moving a family to a new house while they keep living their lives. Before moving you list everything they use, including the things nobody wrote down (the spare key under the mat). You check that every key, appliance and plug works in the new house. You move one room at a time and make sure people can still eat and sleep at every step. And because the old house is sold the moment you hand over the keys, you can't move back; if something's wrong you fix it in the new house.

HP's public release notes show the shape of exactly this kind of migration, drawn below: a bridge release that every device must reach first, a new OS for the newer hardware only, one supported mode at launch while the old train keeps shipping for everyone else, and a one-way door.

What the public notes say, step by step, and the general practice each one illustrates:

What changes between Android 10/11 and 13

A multi-version jump collects every behaviour change in between. Android's own lists (Android Developers, "Behavior changes" pages for Android 11, 12 and 13, last updated 23 October 2026) include, among many others:

• Android 11: package visibility ("When an app queries for the list of installed apps on the device, the returned list is filtered"; apps declare what they need with <queries>) and scoped storage enforcement.
• Android 12 (for apps targeting it): components with intent filters must declare android:exported, or "your app can't be installed"; every PendingIntent must specify its mutability; apps "can't start foreground services while running in the background," with a few exceptions.
• Android 13: a runtime notification permission, POST_NOTIFICATIONS, and a Task Manager from which "users can complete a workflow from the notification drawer to stop apps that have ongoing foreground services."

Many of these apply when an app targets the newer API level, and a device vendor's own system apps are built and signed differently from Play Store apps, so which rules bite depends on how each component is built. The public Poly docs don't say how PolyOS's components are packaged. Android 11 to 13: changes that matter goes through them for a device platform.

The web UI and API side of a migration

For the workstreams this role owns, a migration plan usually has these parts:

• An inventory of the surface. Every REST endpoint, CLI command, setting name, event and default, including undocumented ones customers use. HP's community FAQ shows one: GET /rest/system/bluetooth returns the remote's battery level, with the warning "this is working at present but could change at any point. If you need this ensured please work with Poly sales to request this to be documented." Somebody's script depends on it.
• Recorded fixtures and a parity check. Record real requests and responses from the old build and replay them against the new one (the model below).
• Settings migration. The new build reads settings written by the old one on first boot. Migrations are numbered, idempotent and keep unknown keys (the second model).
• Contract tests between teams. The web UI, the platform services, the SDK and partner integrations each get tests against the agreed API contract, so a change on one side fails a build, not a customer (Contract testing).
• Rollout rings with health gates. Lab, internal, a small percentage, wider rings, each promoted only if its health holds (the third model).

The first model is the parity check. Recorded responses from the old build are replayed against the new build, and each difference is classified by shape (field names and types), not by value, because values like version and uptime are supposed to differ. The endpoints and builds are invented for the model.

// Parity check for an OS migration: replay recorded requests against the old (4.x) and new (5.x) builds of the
// same device API and classify every difference. Endpoints and builds are invented for the model.
const shape = (v) =>
  Array.isArray(v) ? [shape(v[0])] : v && typeof v === "object"
    ? Object.fromEntries(Object.entries(v).map(([k, x]) => [k, shape(x)])) : typeof v;

// Responses recorded from the old build, and what the new build returns for the same requests.
const oldBuild = {
  "GET /api/v1/system": [200, { model: "X", version: "4.6.2", uptime: 17250 }],
  "GET /api/v1/audio": [200, { muted: false, volume: 62 }],
  "GET /api/v1/network/wifi": [200, { enabled: true, ssid: "Corp" }],
  "POST /api/v1/system/reboot": [200, { result: true }],
  "GET /api/v1/system/logs": [200, { url: "/logs.tar" }],
};
const newBuild = {
  "GET /api/v1/system": [200, { model: "X", version: "5.0.0", uptime: 12, androidVersion: "13" }],
  "GET /api/v1/audio": [200, { muted: false, volume: "62" }],
  "GET /api/v1/network/wifi": [200, { enabled: true, networkName: "Corp" }],
  "POST /api/v1/system/reboot": [202, { operationId: "op_1" }],
};

function compare(a, b, path = "") {
  const issues = [];
  if (typeof a !== "object" || a === null) return a === b ? [] : [`${path.slice(0, -1) || "body"}: ${a} -> ${b} (BREAKING)`];
  for (const k of Object.keys(a)) {
    if (!(k in b)) issues.push(`${path}${k}: removed (BREAKING)`);
    else issues.push(...compare(a[k], b[k], `${path}${k}.`));
  }
  for (const k of Object.keys(b)) if (!(k in a)) issues.push(`${path}${k}: added (compatible)`);
  return issues;
}

let breaking = 0;
for (const [call, [oldStatus, oldBody]] of Object.entries(oldBuild)) {
  if (!newBuild[call]) { console.log(`MISSING   ${call}`); breaking++; continue; }
  const [newStatus, newBody] = newBuild[call];
  const issues = [
    ...(oldStatus !== newStatus ? [`status: ${oldStatus} -> ${newStatus} (BREAKING)`] : []),
    ...compare(shape(oldBody), shape(newBody)),
  ];
  const isBreaking = issues.some((i) => i.includes("BREAKING"));
  breaking += isBreaking;
  console.log(`${isBreaking ? "BREAKING " : issues.length ? "OK+ADDED " : "SAME     "} ${call}${issues.map((i) => `\n            ${i}`).join("")}`);
}
console.log(`${Object.keys(oldBuild).length} recorded calls, ${breaking} need a decision before 5.x ships`);

OK+ADDED  GET /api/v1/system
            androidVersion: added (compatible)
BREAKING  GET /api/v1/audio
            volume: number -> string (BREAKING)
BREAKING  GET /api/v1/network/wifi
            ssid: removed (BREAKING)
            networkName: added (compatible)
BREAKING  POST /api/v1/system/reboot
            status: 200 -> 202 (BREAKING)
            result: removed (BREAKING)
            operationId: added (compatible)
MISSING   GET /api/v1/system/logs
5 recorded calls, 4 need a decision before 5.x ships

// Migrating a device's stored settings from the old OS release's format to the new one, as numbered steps.
// Each step runs once (the stored schemaVersion says which have run), and keys it doesn't know are kept, not dropped.
const migrations = [
  { to: 2, why: "rename ssid -> wifi.networkName", run: (s) => { if ("ssid" in s) { s["wifi.networkName"] = s.ssid; delete s.ssid; } } },
  { to: 3, why: "volume stored as a number", run: (s) => { if (typeof s["audio.volume"] === "string") s["audio.volume"] = Number(s["audio.volume"]); } },
  { to: 4, why: "provider 'Poly' is now 'videoMode'", run: (s) => { if (s.provider === "Poly") s.provider = "videoMode"; } },
];

function migrate(stored) {
  const s = structuredClone(stored);
  const from = s.schemaVersion ?? 1;
  for (const m of migrations) {
    if (m.to <= from) continue;
    m.run(s);
    s.schemaVersion = m.to;
    console.log(`  v${m.to - 1} -> v${m.to}: ${m.why}`);
  }
  if (s.schemaVersion === from) console.log("  already current, nothing to do");
  return s;
}

const fromOldDevice = { schemaVersion: 1, ssid: "Corp", "audio.volume": "62", provider: "Poly", "partner.zoom.roomId": "r-17" };
console.log("first boot on the new OS:");
const once = migrate(fromOldDevice);
console.log(" ", JSON.stringify(once));
console.log("second boot (or the migration is retried after a crash):");
const twice = migrate(once);
console.log(`  same result: ${JSON.stringify(once) === JSON.stringify(twice)}`);
console.log(`  unknown key kept: partner.zoom.roomId = ${twice["partner.zoom.roomId"]}`);

first boot on the new OS:
  v1 -> v2: rename ssid -> wifi.networkName
  v2 -> v3: volume stored as a number
  v3 -> v4: provider 'Poly' is now 'videoMode'
  {"schemaVersion":4,"audio.volume":62,"provider":"videoMode","partner.zoom.roomId":"r-17","wifi.networkName":"Corp"}
second boot (or the migration is retried after a crash):
  already current, nothing to do
  same result: true
  unknown key kept: partner.zoom.roomId = r-17

// A phased rollout of a one-way OS upgrade through rings, with a health gate after each ring.
// Each device's outcome is drawn from a seeded PRNG (mulberry32), so the run is reproducible.
function mulberry32(seed) {
  return () => {
    seed |= 0; seed = (seed + 0x6d2b79f5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

const rings = [
  { name: "lab", devices: 40 },
  { name: "internal", devices: 200 },
  { name: "early 2%", devices: 400 },
  { name: "10%", devices: 2000 },
  { name: "50%", devices: 8000 },
];
// Gate: stop if more than 1% of upgraded devices fail to come back online, or more than 2% lose a peripheral.
const gate = { offline: 0.01, peripheral: 0.02 };

function rollout(build) {
  const rand = mulberry32(build.seed);
  console.log(`build ${build.name}`);
  for (const ring of rings) {
    let offline = 0, peripheral = 0;
    for (let i = 0; i < ring.devices; i++) {
      if (rand() < build.offlineRate) offline++;
      else if (rand() < build.peripheralRate * (ring.name === "lab" ? 0 : 1)) peripheral++; // lab rigs only carry current peripherals
    }
    const o = offline / ring.devices, p = peripheral / ring.devices;
    const pass = o <= gate.offline && p <= gate.peripheral;
    console.log(`  ${ring.name.padEnd(9)} ${String(ring.devices).padStart(5)} devices  offline ${(o * 100).toFixed(2)}%  peripheral lost ${(p * 100).toFixed(2)}%  ${pass ? "PASS" : "HALT"}`);
    if (!pass) return console.log(`  halted: the upgrade is one-way, so these ${ring.devices} devices need a fix-forward build, not a rollback`);
  }
  console.log("  promoted to 100%");
}

rollout({ name: "v5-rc1", seed: 7, offlineRate: 0.002, peripheralRate: 0.05 });
rollout({ name: "v5-rc2", seed: 7, offlineRate: 0.002, peripheralRate: 0.004 });

build v5-rc1
  lab          40 devices  offline 0.00%  peripheral lost 0.00%  PASS
  internal    200 devices  offline 0.50%  peripheral lost 5.50%  HALT
  halted: the upgrade is one-way, so these 200 devices need a fix-forward build, not a rollback
build v5-rc2
  lab          40 devices  offline 0.00%  peripheral lost 0.00%  PASS
  internal    200 devices  offline 0.50%  peripheral lost 1.00%  PASS
  early 2%    400 devices  offline 0.00%  peripheral lost 0.25%  PASS
  10%        2000 devices  offline 0.25%  peripheral lost 0.65%  PASS
  50%        8000 devices  offline 0.27%  peripheral lost 0.61%  PASS
  promoted to 100%

This role sits where three worlds meet: the browser (an admin web UI in React or Angular), the API (REST and Telnet/command-line interfaces that partners and scripts depend on for years), and the platform (Android services, the SDK and the platform teams who own them), with a team of developers in India to guide. Interviewers for a role like this aren't checking whether you've worked at a device company. They're checking whether you can reason about the things that make device work different, own an API that can't break, work across team boundaries without being blocked, and lead people you mostly see on video calls.

A good mental model for your own pitch: you're the translator. The platform team speaks Android services, permissions and release trains; the web team speaks components, forms and HTTP; partners speak "my script broke"; the India team needs clear contracts and fast answers across a time-zone gap. Your story is that you've worked in more than one of those languages and you turn the conversations between them into contracts, tests and decisions. Every claim in that story has to be something you've actually done: this topic gives structure and prompts, never invented experience.

What they'll probe

Mapping your background to the role

What's true and stated in your brief for these sites: you're an experienced full stack engineer (React, Angular, Node and databases) and you build Android apps. Map each to the role, then fill in your own examples:

• React and Angular → the admin web UI. Settings forms, validation, status dashboards, error and offline states, accessibility. The device-specific twist to talk about: the server is the device, and it can disappear mid-save.
• Node → the API layer and tooling. REST services, validation, auth, line-based servers with the net module, test harnesses, device simulators. Every model on this site is Node; once you've run and changed them yourself, you can say you've worked through small working models of these patterns (preparation, not work experience; see the box below).
• Databases → the config store and history. Schemas, migrations, idempotency, audit trails. Settings migrations on first boot are schema migrations under harsher conditions.
• Android apps → the platform boundary. You know the app side of the line: manifests, permissions, services, lifecycle, adb, logcat. Say plainly where the line is: system apps, platform signing, AIDL services owned by an OS team and OTA pipelines are things you understand conceptually and would learn on the job, unless you've done them.

The answer skeleton below is a template, not an answer. Everything in square brackets is for you to fill with what you actually did; delete any line you can't back with a real example.

1. One line on who I am:     full stack engineer, [years] years, [React/Angular/Node/databases], also build Android apps.
2. The bridge to devices:    "The part of my work closest to this role is [a real project] where [the server / the
                              client / the device] was something I couldn't fully control: [what made it hard]."
3. A decision I made:        "I chose [design] over [alternative] because [constraint], and the result was [outcome,
                              number if you have one]."
4. The Android side:         "On Android I've built [real apps or features], so I know [manifests, services,
                              permissions, adb, logcat]. Platform-level work like [system services, OTA] I know at the
                              design level, and I'd lean on the platform team there."
5. Leading people:           "I've [mentored / reviewed / led] [who], and what worked was [a concrete practice]."
6. Why this role:            "I want to own the web UI and API layer on a platform where compatibility and reliability
                              matter, and the 4.x to 5.x migration is exactly that kind of problem."