Harry Park

BASc Computer Engineering · Software Option

Computer engineering rather than straight computer science, on the Software Option — a specialised track in software engineering and software engineering process management, which UBC has since retired. The process half felt like overhead at the time and is the part I lean on most now. The projects didn't pick a lane either — processor design at one end, search ranking at the other — which set the pattern for everything after.

Capstone

A recommendation system for Food.ee, on Elasticsearch over their proprietary APIs

Hardware

A cannon battle game in C on an FPGA board — including designing the processor it ran on

Also built

Pong written in VHDL, and an electromagnetic tether robot

Web Developer I · FortiOS platform

First job out of UBC, and where I learned to be an engineer rather than a student. A Django web GUI on top of C backend APIs for the operating system Fortinet's appliances run — full-stack in a fairly literal sense, and my first taste of both. Twenty-odd projects in two years, mini through medium and each small enough to own end to end, which is enough repetition for thinking a design through and iterating before committing to become habit rather than advice.

Delivery

20+ projects owned, design through implementation

Features

Indicator-of-compromise visualisation and DHCP client configuration — the two I'd point at

Debugging

100+ complex bugs cleared across the platform

SDE I–II · Alexa-Hosted Skills

A managed AWS environment for hundreds of thousands of external developers to run their skills in, which meant our failures were their outages — and constraints from upstream reached them through us. Also where I wrote ask-sdk-jsx-for-apl: watching developers hand-write Alexa Presentation Language as raw JSON got painful enough that I fixed it.

The work I'd point at, though, is the Node.js runtime migration. Lambda was retiring the runtime our customers' skills ran on, which was never ours to negotiate — and until a skill moved, the developer who owned it couldn't ship an update to it at all. Asking hundreds of thousands of people to migrate themselves would have stranded most of them, so we did it for them. The part I'd defend hardest is that we built it to be run again rather than run once: the runtime underneath us was always going to be deprecated again, and a migration you can only perform by hand is a problem you get to solve twice.

Platform impact

2 weeks added to the deprecation deadline after I found and reported a bug in the runtime itself

Releases

Led the Python runtime support and template service releases

On-call

15 min response target on high-priority rotations

Open source

Authored and open-sourced ask-sdk-jsx-for-apl, still on npm

Software Developer II · Viva Amplify

A year on the question that comes before the code. The team was new and the product didn't have a name yet; the work was establishing whether the data side of it was viable at all — which signals were actually available to us, and how much depth we could process fast enough for the idea to hold up. I was also the team's frontend person, which is how I ended up building the barebones dashboard for the first dataplane designs.

Research

0 to 1 feasibility on data ingestion for what's now Viva Amplify

Frontend

Barebones dashboard behind the initial dataplane designs

Team

Owned onboarding and culture for a brand-new team

SDE II · Alerting and on-call

The system that pages people. Nobody thinks about it while it works, and when it drops a page an on-call engineer doesn't get woken while their service is on fire — so the tolerance for failure is about zero. Two years on two things: making it regionally redundant, so one region's bad day can't take paging down with it, and migrating a legacy Perl script system onto managed AWS services so it could grow features again instead of only being kept alive.

The incident I'd point at is the day our upstream voice and SMS provider went down and took the phone and text channels with it. I ran internal communications while our product manager worked the vendor side, which mostly meant telling on-call engineers across the company what they could and couldn't rely on while it lasted. We were back inside two hours, the service never went fully dark because the remaining channels carried it, and none of it was improvised — we followed a runbook that had already been written for exactly this, which is the unglamorous version and the one I'd rather tell.

Incident response

2 hours to recovery on a third-party outage, with no full loss of the alerting service

Reliability

Regional redundancy for a service that can't be allowed to go quiet

Modernisation

Perl script system migrated onto modern managed services

Ownership

Sole engineer on the team outside Seattle — end-to-end by default