A Day in the Life of a Solutions Engineer
The Solutions Engineer role at Facebook is an unusual position, and it is not surprising that many people have misconceptions about what it entails. In this post, I’m going to attempt to clarify what it is and what it isn’t.
To begin with, the title of this post is already misleading. I lied to you, and I’m only slightly sorry about that because it’s a useful lie. It serves as a segue into the point that there isn’t really a typical day as a Solutions Engineer. Some days you will be talking to CTOs, product managers, tech leads, and so on, to understand their business and help them understand where Facebook’s technology can be best used to add value for them and their customers. Some days you may get buried in code and have hours dissolve away in a stream of Monokai coloured lines.
The Solutions Engineer role at Facebook is an engineering position that sits within the sales side of the organization. The fact that the role straddles the divide of these two functional areas isn’t an operational accident but a deliberate decision. We provide engineering expertise for the sales teams and a link to the actual users of our tech for the product teams. So far you may be seeing a resemblance between what I’ve described and similar named roles in other companies.
However, a Facebook Solutions Engineer is a slightly rarer creature because we’re also expected to build; specifically, we’re expected to build new things. The rationale is that by having technical people engage with end users, those technical people would be uniquely placed to understand gaps in Facebook’s tech and be able to create new products and features.
Some of you may have already spotted a potential issue with a team tasked with always looking for the next build project. The more successful we’d become at that, the more we’d become weighed down by maintaining the tech we’d created, and at some point we’d effectively grind to a halt. So we’re not a product team. We own the product for as long as we’re still proving that it’s worth continuing with. After that point, the code becomes the property of a product team. Anything that’s built must be built with the knowledge that it will need to be handed over.
That’s the bones of it. The above explains the essential responsibilities of the role, but it doesn’t really give an impression of what it’s actually like to do the work. Is it fun? Is it challenging? Will it bring peace to my restless soul? The rest of this post will attempt to give you a taste of what being a Solutions Engineer is like.
Most days start with catching up on overnight messages. Facebook is a multi-national company and not everyone you’ll be working with will be in a time zone that lines up with yours. The effect of this as a European is usually attempting each morning to find out what your U.S. colleagues have done and checking whether anyone has been asking for you specifically. After that I personally grab another coffee, but that’s not a job requirement. Really, any mug based drink is considered acceptable. On any given week, you’ll likely have at least one external company that you’re working closely with. This may be a large company with which you have a long-term relationship or a small (but interesting) company that you’re helping build a new integration. So, your next port of call will be to check in with their current state. Are there any outstanding questions or blockers they have? Are there any data you’re looking to gather to measure their progress? Do you know where they are in their build? Some days the answer to these questions can be no, no, and yes, respectively, and you can move on to some longer-term projects, work on any products you’re building, and/or plan any new proposals you have.
Dealing with questions and blockers
It is likely that your focus company of the moment is going to face an issue when they start building out their integration. This is because nothing in tech is ever straightforward, and every company represents a novel, previously unconsidered edge case. There are a number of ways in which you might deal with this. You may know the answer or know who does, in which case it’s basically an email. It’s more interesting when you don’t know the answer, as this may involve some investigative work. Is this a bug? Or perhaps the company has some odd structure that falls prey to some integrity check rules? You can reach out to the wider team to see if anyone has seen anything similar, but often you might find yourself digging into the code and the logging tools to find out what’s happened.
After some time has passed, cool, you’ve worked it out. Maybe it’s not exactly a bug but an unsupported use case. Now you need to decide whether or not you simply need to notify the product team, code up a fix for it yourself, or advise the company to work around it. In fact, often you might find yourself ‘architecting’ technical implementation details for the companies you work with, as you’re the only person who knows enough about the company to understand their setup and who understands the Facebook tech.
Gathering Data
Being a Solutions Engineer is a state of constantly needing more data. If we’re going to have the ability to propose and build new products, then we have the responsibility of showing that the products add value and that we’re not simply adding future technical debt. Further, you will need to be an advocate for the companies you work with, and to do this you will need to prove that the problems they face are both real and significant enough for you to be able effect change. Facebook has excellent data scientists, but their time is often in high demand, so you will often need to dig into the data yourself. A such, having an understanding of how to build SQL queries and construct dashboards is invaluable. Fortunately, there are plenty of internal tools and tutorials to help you understand how best to do this and, if you’re unsure about your assumptions, you can ask the data team to review your results.
Building
This bit is largely the same as the initial build of a project in most places. You spot the gap in Facebook’s products, gather data to back up your arguments, make a proposal, and get sign off. Then you start coding. The one part that is a bit unusual is the fact that you will need to think about how you hand the product over if it works well enough to be continued. To that end, you’ll tend to build a close working relationship with several product teams and come to an agreement, before the project gets too far along, about which team will take it over. This is not as onerous as it sounds and basically means you can have more people help with the planning and the review stages.
Unrelated to anything, that stock image is an amazing result for ‘coding’, a chunk of minified javascript. I think I’d be terrified of anyone that could code like that and hold the execution model in their head.
Direct Interaction
And, finally, there’s the interaction you have with the external companies. You have some choice in how you manage this interaction, but you will probably find yourself in a few email chains and several meetings. In pre-pandemic times, this could have meant making an on-site visit to the company. But even in that strangely dream-like past, you may equally have decided that the meeting was best held over video chat. As a Solutions Engineer, you represent a pretty powerful collaborator for the company in their work with Facebook. As a result, you will be someone that they trust and actively want to speak with. In turn, you’re likely to want them to succeed, and will find yourself wanting to help them where you can, celebrating their wins as you do your own.
Done
That’s pretty much it, from the work point of view at any rate. You will also get to work alongside some extremely welcoming, smart and interesting people. Then again, every company throws something like that out at the end of their “Why work for us?” pitch. Frankly I think the sentiment is a bigger deal than a single line conveys and far harder to convince people of without them seeing for themselves.
