Kyaw Linn Thant
Sydney, NSW · kyawlinnthant55@gmail.com · linkedin.com/in/kyaw-linn-thant

Dear Hiring Manager,

I am writing to apply for a Graduate Engineer position in the Industrus Engineering Graduate Program. I am a final-year Biomedical Engineering (Honours) student at the University of Technology Sydney, graduating in December 2026 with a WAM of 84. Over a twelve-week internship at Optik Consultancy I led the hardware build of a Forced Oscillation Technique attachment for CPAP and BiPAP machines, developed for the Respiratory Investigation Unit at Royal North Shore Hospital and the Woolcock Institute of Medical Research, and delivered the first working prototype the project had produced. I address each of the selection criteria below.

3.1 — A commitment to ethical conduct and the highest standards of professional accountability

Situation

The device I built was intended to inform ventilator pressure decisions for COPD patients, so any number it produced would eventually carry clinical weight. When the first assembled board came back and began returning impedance values, those values looked reasonable.

Task

Reasonable is not the same as verified. I had to decide whether to report the device as working on the strength of plausible output, or to establish what it had actually been shown to do before saying anything to the client.

Action

I checked the output against known conditions on the bench before reporting it, rather than treating a plausible reading as a validated one. When I did report to the team and the clinical stakeholders, I was explicit about the boundary: what had been demonstrated on the bench, what remained uncalibrated, and that nothing had been validated against a clinical reference. I raised the limitations myself rather than waiting to be asked.

Result

The prototype was handed over with an accurate account of its state, which meant the clinical partners could judge what it was ready for. I would rather deliver a device with its limitations documented than one that is believed to be further along than it is, particularly where the eventual user is a patient.

3.2 — Demonstrated ability to effectively communicate both with other engineers and with stakeholders from different fields

Situation

The requirements for the device came from respiratory clinicians and researchers at Royal North Shore Hospital and the Woolcock Institute, who described what they needed clinically rather than in engineering terms.

Task

I needed to turn a clinical need, helping titrate ventilator pressure for COPD patients, into quantities I could build against: oscillation frequency, pressure amplitude, sensor range and acceptable measurement error. I also needed the clinicians to understand one technical constraint well enough to accept its consequences, because it shaped the hardware.

Action

I asked about how the measurement would be used at the bedside rather than what specification they wanted, which is what produced the numbers I needed. When explaining why the acquisition architecture mattered, I left the converter details out and put it in terms of the measurement: pressure and flow have to be read at the same moment, because the timing between them is the signal, and reading them one after the other introduces an error that looks like a real change in the patient. Within the engineering team I described the same decision in terms of sequential I²C reads and phase skew.

Result

The specification I worked to came out of those conversations rather than being assumed, and the sensor ranges were chosen against real clinical values. Adjusting the level of technical detail to the audience is the part I would carry into a consulting environment, where the same decision often has to be explained several different ways.

3.3 — The ability to engage with a creative, innovative and proactive environment

Situation

The device measures respiratory impedance, which is derived from the phase relationship between airway pressure and flow, so the two channels must be sampled at the same instant.

Task

The straightforward path was an on-board I²C ADC, as the reference designs available to me used. That converter reads its input channels sequentially rather than together, which introduces a timing skew between the pressure and flow samples and corrupts the phase measurement the device exists to make. I had to decide whether to accept the standard architecture or change it.

Action

I specified the measurement first and then selected hardware to serve it, moving to analog simultaneous sampling with the DAC output and dual ADC acquisition phase-locked to a hardware timer interrupt at 420 Hz. I selected dual Honeywell HSC sensors for airway pressure at ±10 inH₂O and flow at ±2 inH₂O, designed the analog conditioning around them, and took the 2-layer FR-4 board from schematic through routing to Gerber export, passing design rule check with zero errors before fabrication at JLCPCB.

Result

The build produced the first working prototype the project had achieved, after previous teams had not delivered one. Both channels remain phase-coherent, which is what makes the impedance measurement valid rather than merely plausible.

3.4 — Demonstrated ability to use and manage information

Situation

The project had been attempted before I joined, so I inherited partial material from earlier work, and the component selection required comparing options across several manufacturers' datasheets.

Task

I needed to establish what was reusable from the earlier work and what was not, choose sensors and an acquisition path on the evidence rather than on convenience, and document my own build so that the next person did not face the same problem I had.

Action

I worked through the prior material first and separated conclusions that were supported from assumptions that had been carried forward untested, which is where the on-board ADC assumption surfaced. For the sensors I compared pressure ranges, output types and interface options across datasheets against the clinical values I had, which led to the dual Honeywell HSC selection. Through the build I kept the schematic, layout and Gerber versions ordered alongside notes on why each decision was made, and used the Flask dashboard to log acquisition data so results could be reviewed rather than recalled.

Result

The design decisions are traceable to the reasoning and the datasheet evidence behind them, and the project was handed on in a state where someone else could pick it up. Having been on the receiving end of an undocumented handover, I treat documentation as part of delivering the work rather than something after it.

3.5 — The ability to manage your own performance in a professional environment

Situation

I had twelve weeks, a project that previous teams had not completed, and no prior experience with PCB design, which the build required.

Task

I had to sequence the work around a hard external constraint. Board fabrication has a lead time, so the schematic and layout had to be finished and committed well before the end of the internship, or there would be no physical board to test and nothing to hand over.

Action

I worked backwards from the fabrication date. Sensor selection and the acquisition decision came first because everything downstream depended on them, then schematic capture and layout, and I taught myself EasyEDA Pro against that deadline rather than learning it in the abstract. While the board was in fabrication I moved onto work that did not depend on it, the SolidWorks tubing and enclosure components and the firmware, so the wait was not idle. When something did not behave as expected I checked it against the datasheet and the measurement I was trying to make before changing anything, rather than adjusting the design until the symptom disappeared.

Result

The board was fabricated, assembled and tested inside the internship, and the prototype was delivered. Planning around the constraint I could not move, rather than around the order I would have preferred to work in, is the habit I took from it.

3.6 — A demonstrated ability to work as part of a team and to show leadership when required

Situation

I led the hardware side of the build as part of a wider project team, with the work spanning electronics, firmware, mechanical components and the software dashboard, all against the same deadline.

Task

The work had to be divided so that people were not blocked waiting on each other, and the acquisition architecture decision had to be made early because the rest of the hardware depended on it.

Action

I sequenced the work around the dependencies rather than around equal division, settling the sensor and acquisition decisions first so that the mechanical and firmware work could proceed in parallel against fixed interfaces. Departing from the reference design was a call I had to make and then justify, so I explained the phase skew problem to the team rather than asserting the conclusion, on the basis that a decision people understand is one they can build on and challenge. Where I was the one who had read the datasheets I said so, and where someone else knew the ground better I deferred.

Result

The separate strands came together into a working prototype within the twelve weeks. What I took from leading it is that the useful part of the role was removing ambiguity early, because most of the time that was lost on this project before I joined was lost to decisions that had not been made rather than to work that was difficult.

I would welcome the opportunity to discuss how my hardware experience and clinical engineering background could contribute to the Industrus Graduate Program. My resume and a fuller account of the respiratory device are available on this site.

Regards,
Kyaw Linn Thant