harisrid Tech News

A primer

I’ve prepped behavioral interviews in the past, primarily targeting for senior-level or staff-level positions at companies, but I still think that it’s a good exercise to work through written example at lower engineering levels. What do stories resemble for entry-level new graduates or mid-level engineers? What should they communicate if they wind up in an interview loop at another tech company?

Alright, let’s begin!!!

The Situation

Where to begin? What’s the situation?

It’s Q3 of Google, and I’m working a junior-level role on the Google Analytics Team ( termed GA for brevity). I’m facilitating on ongoing migration of customers from the old product, Universal Analytics, to GA to help clientele maximize the effectiveness of their advertising campaigns.

I’m paired up with a senior engineer, my tech lead, on a high-impact task. My tech lead noticed that external teams utilize GA’s server diff testing code, which is hard-coded, space-consuming, and difficult to update. If we update the server diff tests, we not only can refactor down 10,000+ lines of code closer to a 100, but we can also expedite developer velocity and bolster end-to-end infrastructure testing correctness.

The Task

I’m tasked to write optimal code to do the refactoring from static hard-coded requests and responses to dynamically updateable requests and responses. My tech lead helps me out from time-to-time – they identify locations to make changes or provide references to useful structures and libraries – but the implementation is my responsibility.

And there’s two challenges.

The first challenge being development – we have to update both the requests and the responses. And while responses are intuitive, requests are harder.

And the second being that the requests and responses are variables held in a sister team’s infrastructure components and workflows. This entails needing to work with difficult lambda functions, moving components, and data flows on another team’s codebase to accurately capture state.

The Actions

So I take a couple of actions.

First, my tech lead and I chart design course. We split a complex multi-week business ask into two-phased development, each lasting 2-3 weeks. Phase one – updateGoldens – entailed updating only the responses. And phase two – useGoldens – would entail updating both requests and responses.

During both phases, I’m writing code to capture state and write the variables out to an external file. By using a file, I can then read from, or write to, it later as state evolves over time.

Once I confirm that file I/O works, I remove the long hard-coded strings and reconfirm that every test case scenario still passes the server diff tests. I checked feature correctness by verifying that pairs of expected and actual value comparisons stayed the same, before and after the refactor work.

The Results

In the end, I delivered a result : a successful working feature, titled useOrUpdateGoldens. Developers on my team could execute two paths dynamically in a command-line esque style. The first command , updateGoldens, preserved requests but updated responses. The second command, useGoldens, updated both requests and responses.

My team members strongly appreciated the deliverable; it reduced toil and the number of dev cycles needed to manually copy-paste and verifying the integration testing code correctness. The deliverable also helped us meet annual refactor goals.

My biggest takeaway was learning the value of phase-based development. Before this project, I used to go in with an all-or-nothing mindset to shipping and delivering to production. But down-scoping an ambiguous, complex ask to smaller, simpler tasks enabled faster execution – end users could immediately test and share feedback on the first feature whilst the second feature went under development, enabling a faster feedback loop in the hiding.