Name: Cristina
Role: Software Engineer, Client Service
Background: Cristina joined Bridgewater in 2017 as a Technology Associate, following two internships at Microsoft and her graduation from the University of Pennsylvania. In her time at Bridgewater, she’s held several leadership positions and broadened her skill set in both software engineering and in the product space.
Describe a project you're working on:
My team has been building a visualization tool that allows our portfolio strategists to tailor analytical insights in real-time during their conversations with clients. What used to require follow-up meetings and hours of analyst work can now be visualized in the moment, with our client-facing portal ingesting client data and instantaneously mapping on top of it Bridgewater's best thinking on portfolio construction.
The really cool thing is that despite being only three years out of school, I am the team lead for an offshore team of eight super talented senior engineers working on this project. Since the kick-off last June in Poland, I’ve learned a ton from working with them – and the experience of leading a team is not something I would have pictured myself doing so soon after graduating.
What meaningful impact have you been able to make here?
In recent weeks, our analysts have put together a set of portfolio stress testing perspectives on the coronavirus situation using my team’s new content editing tool. These tools, and more broadly our platform, allow Bridgewater to quickly deliver insights to our clients on a rapidly changing situation.
What is a failure you've faced, and how have you handled it?
I’m a front-end engineer and our platform was still in beta mode when I started here three years ago. We use a framework called Puppeteer to create end-to-end tests, modeling the workflows that someone would follow if they were using the application. One of my early projects was taking on responsibility for these tests and at the beginning, the tests were giving inconsistent results. This was a huge source of stress for me because every developer on my team of 40 people used it, and the only way you can ship your code is if it passes the tests. But the tests weren’t performing consistently. What I did – which really did not work at all – was to see which tests were faulty and fix those. But by the next day, there would be three more tests that were failing randomly, and I’d have to go and fix those. I did this firefighting exercise for three or four months, which I absolutely hated. Finally, I sat down with a bunch of my team leads to make a systematic fix to all the issues, instead of dealing with them as one-offs. We started stress-testing our tests so that every night, we could see if something emerged as failing more often than we’d expect. Our new, systematic approach allowed us to see the bigger picture and we realized that the failed tests had one thing in common. After we fixed that one underlying cause, the majority of our issues were resolved.
I took away a few lessons. For one, I think I failed because I wasn’t holding the goal; I was thinking about it like I was in school and the project was a task to be done. With that mentality, once your task is complete, it’s over. Consequently, I wasn’t thinking about everything around my goal, which was the wrong way to approach the problem. Second, I learned that I both needed to recognize when I needed help and then actually ask for that help. The project was almost a thing that I wanted to prove I could do on my own. In reality, that’s not how anything works – you always need people helping you out.
What have you learned about yourself from working at Bridgewater?
Number one, I learned that I’m very impatient – which is why I think I like front-end work because you write code and you immediately see it on the screen. It’s instant gratification. I actually learned this from the first project that I did by myself when I was a year into the job. The project was supposed to be done in one month, but it turned into a three-month journey. Initially, I just wanted to get it done. But over the course of the project, I started slowing down and thinking more about the code quality, the architecture, and exploring multiple possibilities at the beginning. I learned that by not rushing at the beginning, I could avoid bugs from popping up later down the road.
I also learned that I wasn’t as precise or meticulous as I thought I was. I went through a period where I was causing all of these issues on the team because I kept breaking things. It wasn’t that I wasn’t paying attention or focusing – I just wasn’t noticing little details that turned out to be important. Once it was called out to me and people pointed out all the different instances, I became much more aware of it. I find that now, because I’m so aware, I’m one of the more precise people on the team and the one catching the majority of the issues before they go out. To me, this change comes from the process of getting that feedback so consistently from teammates who care about me personally and as an engineer.
Looking ahead, what projects are you most excited to tackle?
We’re in the process of redesigning our entire client website and it’s in a new language for me. I’m really excited for this project because it’s going to be a huge change, especially from a design perspective. It’s cool to be part of the entire process of creating a product, from asking the big questions like, “What do we want our client experience to be?” and “What do technically we want to change?” to creating designs that tackle the biggest pain points, to finally being able to start coding for this project and delivering something great for our clients.