Engineer Q&A: Spencer Wilson, Client Engineer, San Francisco

This post continues the summer 2018 Q&A series, an effort to introduce the world to the Engineering team at Optimizely. If you missed it, consider checking out the introductory post by our VP of Engineering. If you’re interested in joining the team, we’ve over a dozen openings in SDKs (SF one and two), app backend (SF and Austin), distributed systems (SF and Austin), management (SF and Austin), and more.

Tell us about yourself! What’s your name, what do you do at Optimizely, and how long have you been here? Tell us a bit about your trajectory to get here.

Hello! My name is Spencer and I’m an engineer at Optimizely. I first learned about the company while prepping for a job fair during my senior year at the University of California, San Diego, where I met my future manager, Jenny Lin. I interned here in summer 2016 working on our web app frontend, returned to school in the fall for my final quarter, took a brief hike through the Andes in Peru, and started full-time in January 2017. I was given a generous offer to join whatever team interested me, which led me to our Web Client team. We maintain “the snippet”: the third-party JavaScript that powers most of the A/B/n-way testing and personalization on the web. I’ve also been lending support to our Full Stack SDKs, as well as to the Python application that our customers use to manage both their Web and Full Stack experimentation.

Some Quechuan friends and me

I’m from the east Bay Area, where I was fortunate to grow up with ample access to computers (thanks 🙏, Mom and Dad!). When I was 13 or 14 years old I remember being at a Boy Scout summer camp and seeing a counselor on his laptop during some downtime, typing the word printf in a monospace type on an all-black screen. It was captivating! The pure aesthetic of it imparted some magic for sure, but there was more to it than that. Beneath the surface of these machines we all enjoyed, it seemed to me, lied some language that — if one only knew the proper incantations — could be used to… well, I didn’t know what they could be used for, yet. I didn’t know anything, other than that typing words into a “command prompt”, having results come back at you, and knowing that you wrote the instructions underlying it all was thrilling as heck.

If one googled “how to program” in July 2008, I assume what turned up was C tutorials, because that’s where I ended up. For context this was about two years after the initial release of jQuery, six months before Python 3, and ten months before Node.js. My first program was Basic Math Assistant:

Pure innovation, built with Windows XP, Code::Blocks, and MinGW.

From there programming was an on again, off again hobby, with periods where I drew considerable inspiration from the Nintendo Wii homebrew scene (blog posts like this, or WiiBrew, or spectating on IRC) and video game system emulators like Dolphin. Ultimately, the only nontrivial program I wrote before university was OpenSearch, a CLI utility to do “relative searching”: given a search pattern of bytes, scan a file for a byte sequence whose interrelationship matches that of the pattern. For example, “acb” matches “xzy”. Old games often stored their text uncompressed and used mostly-8-bit, non-ASCII character encodings; relative search is effective at reverse engineering such encodings, which is particularly useful for “translation hacking”. A hacker might take, say, an English-only game and patch it to be in another language. This way, some games that were only released in one region of the world could reach a wider audience.

Looking for “Goombario” within Paper Mario, a Nintendo 64 gem.

Experiments with programming continued, but I also became enamored with mathematics and physics during high school. I took a detour in university studying electrical engineering, but was constantly more interested in my computer science-friends’ courses than my own. Halfway through year three I changed majors to computer engineering, and about two years later started full-time at Optimizely. All told, I’m very grateful that I’ve wound up in a profession that feels “right” to me so relatively early in my career.

What are you working on this quarter?

I’m collaborating with another engineer on a new feature, Custom Audience Integrations, that will enable our services team, solutions partners, and customers to easily integrate our Web products with any external source of audience targeting data. With the feature, Optimizely customers will be able to express experiment targeting conditions using the same terms and definitions (like visitor attributes, segments, audiences, etc.) that they might have already defined in other systems (such as other SaaS vendors), enabling knowledge reuse and reporting consistency. It’s a neat project, in part because it posed some interesting technical challenges (e.g., how and where to run untrusted server-side JavaScript), but also because it’s an empowering feature that makes our experimentation platform more extensible and interoperable. Doing “one thing well” (or three things — experimentation, personalization, and feature rollouts — better than anyone else) and easily integrating with other tools that also do one thing well is kind of like applying Unix philosophy to SaaS products, which I’m pretty on board with.

I also enjoy writing, and have been helping improve our Full Stack SDK documentation by doing things like clarifying prose in docs and authoring a TypeScript declaration file describing the interface of our JavaScript SDK, which will eventually be used to generate reference docs and give users an enhanced experience when adding Full Stack to TypeScript projects.

What’s unique about engineering at Optimizely?

One thing that’s totally cool and almost surely unique is that our head of engineering (Bill Press, who authored this series’ intro post) runs a weekly meditation group in the office.

Another thing I appreciate is that our Product, Engineering, and Design organizations share a desire to live up to some of the company’s cultural values. Some of those values are ownership, integrity, and transparency, and they all come through daily in neat ways.

Ownership, as I see it, means that we’re encouraged to identify issues, drive them to resolution, and take pride in a job well done. It also means that we strive for things to always have clear, unambiguous owners, because there’s nothing more sad than an abandoned or forgotten system. It’s valuable, even in a simple logistical sense, to have a point person or team for everything. Though this isn’t to say that I only stick to working on the systems that I “own”; at our size there’s still a lot of cross-pollination that naturally occurs as priorities evolve. I mentioned that I originally mostly contributed to the Web client, but lately have been helping out with Full Stack. I’m shaping up to be more of a generalist than a specialist, so this flexibility is really nice, particularly when paired with a management team that understands the added value of having peoples’ work aligned with their interests.

By integrity we mean intellectual honesty, things like admitting when you don’t know things, admitting mistakes, and preferring finding the truth over winning an argument. One of my favorite things is when folks post in our #engineering Slack channel owning mistakes that have far-reaching effects (e.g., blowing through a Sentry quota or merging an automated test that fails sporadically). For me, it feels like it really encourages a culture of understanding and security, where mistakes are acceptable and learning opportunities (see Infinite Hows, it’s great), and that we actually are one team — something that can easily be said, but requires a plethora of organizational habits to be in place if it’s to have any hope of ringing true for employees.

Transparency has clear ties to the above (who owns what, how mistakes happen, etc.), but also applies in the sense of such questions as: how do prioritization decisions get made? How is the business doing overall? Where are we excelling and where do we have room to improve? I hear from friends at other tech companies in San Francisco that such information is not easily available, and reaching outside of their sphere of familiarity to find it is likely to be fruitless; leadership is less accessible, and work is so distributed that a lot of boundaries between teams are totally, frustratingly opaque. I’m sure that we owe being able to pull off transparency, at least in part, to our moderate size, and preserving this and other values will surely take concerted effort as we continue to grow.

Lastly, I want to mention how neat having a diverse team is. In particular, diversity of backgrounds and personalities is very cool. I work with people that took much more interesting paths than I did to be here (like Jess, Derek, and Lauren), and their unique experiences and perspectives are constantly teaching me new ways to think about problems, balance work and life, and be a good teammate.

What advice do you have for people trying to break into your role?

I’ll address students here, since I was one not too long ago.

If you’re going to job fairs, don’t open the conversation with “So what do you guys do?” My first manager told me months later that I stood out from the others at the fair simply by demonstrating I’d done a modest amount of research before talking to them. Feels kind of like a low bar, but I suppose that’s the reality if the company isn’t yet a household name.

Also, I encourage you to find an unmet need around campus, get a group together, and build an application that addresses that need. For me, this was trying to build an application that tracked event attendance for members of a student org. Most school programming assignments in classes are scoped to a single, self-contained program, but a “simple” project like an attendance tracker can expose you to a lot of new things: multi-component systems, application fundamentals, or even a programming language that’s not Java or C++. Being acquainted with things like configuring a VPS from scratch, DNS, authentication and authorization, and JavaScript all made me feel a lot more confident and capable. A lot of students can feel disillusioned, like they know considerable theory (looking at you, data structures) but can’t even conceive of how to build anything interesting; a side project or two was a way out of that feeling, for me. Lastly, if you do decide to give this project thing a shot, try not to stress about making it perfect. The event tracker application that we built, half-functional as it was, was thrown away the next year, to be rewritten by those that came after us. I’m happy about that, since it means they got to learn things too!

Thanks for reading. We’ve got some great work ahead of us, and if you’d like to be a part of it, we’re hiring!

  • Help make mobile product experimentation at scale seamless with iOS and Android SDKs
  • My team is looking for a manager
  • Lots of other roles: app backend (SF and Austin), distributed systems (SF and Austin), and more.