Algolia’s Sarah Dayan on what sets a senior engineer apart

When you reach senior level on an engineering track, you’re expected to be optimal in your hard skill set. You’re autonomous, your code is immaculate, and you have a deep understanding of building and shipping software. But going into staff plus roles is another beast entirely. There’s project management, mentorship and teaching, decision-making, relationship-building, and the value you bring to the company is no longer measured by the quality of the lines of your code but rather by driving the engineering org forward.

Today’s guest has been through just that. Sarah Dayan is a staff engineer at Algolia, a “Search-as-a-Service” platform that helps developers build index and search capabilities into their own platforms through an API, and the host of two tech podcasts: Developer Experience and Entre Devs. She creates front-end libraries, a role that perfectly suits her given her life-long passion for user experience, design, and building things. In fact, Sarah has been obsessed with creating websites ever since her parents got broadband internet installed in her basement. It was love at first click. She put together her first phpBB forum at 15, wrote her first HTML page not long after that, and hasn’t stopped building things since.

Despite not having a formal education in engineering, Sarah landed a job as a developer in the French consultant Grand Manitou. Then, four years ago, in 2018, she got a job at Algolia as a software engineer. She diligently rose through the ranks, finally growing into the individual contributor role of a staff engineer. And suddenly, all she cared about for the past few years – becoming a better engineer, writing better code – made way for new challenges. How would she provide the right technical direction for the company? Unblock bottlenecks? Mentor and help other engineers as others had done for her?

In this episode, we sat down with Sarah to talk about the many nuances, proficiencies, and expectations of a staff plus engineer role.

Here are some of our favorite takeaways from the conversation:

• If you don’t want to fall behind, keep learning. Discuss ideas and get feedback from other engineers with different perspectives and backgrounds.
• As a staff engineer, a lot of your energy goes into cross-team collaboration for the vision and strategy. Where is the company going to be in five years? How are you going to get there?
• Having staff engineers as mentors allows more junior people to get clarity on which steps to take to reach those roles and you fast-track the process of creating engineering leaders.
• Contrary to popular belief, a staff engineer is not a quick fix for a structural problem. Before accepting a new job, ask what is expected of you to avoid misunderstandings down the line.
• Staff engineers must understand the needs of the company so they can help it reach its goals. While onboarding, read as much documentation and speak with as many people as you can.

If you enjoy our discussion, check out more episodes of our podcast. You can follow on iTunes, Spotify, YouTube or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.

Never stop learning

Brian Scanlan: Thanks so much, Sarah, for joining us on the show today. I’m delighted to get the opportunity to talk with you. Before we talk about your role and work at Algolia, I’d love to hear about your journey up until this point. How did your journey to where you are today start?

Sarah Dayan: Well, hello, thank you for having me. Well, that’s actually a funny story. I’m currently 32, and we got broadband and unlimited internet at home when I was 15. I was always into building things, and the first time I saw websites, I was like, “I have to know how to do that.” One thing led to another, and I built my first forum with phpBB. PHP was really, really big, and it’s still big, but it was really the language for the web back then.

“I decided this wasn’t my thing, that maybe I should be doing what I loved. So, I went back to what I loved – building websites”

Back then, having a career in tech, especially as a software engineer, was not as cool and hot as it is today. My parents thought I should look into becoming a journalist because I was good at languages and literature at school. And that was the first thing I did. I did my first year in journalism, which I completely failed, and then I decided this wasn’t my thing, that maybe I should be doing what I loved. So, I went back to what I loved – building websites. I got my first job at an agency and spent six years there. It taught me a lot about the job, about working with customers, with people who know what they want and people who don’t know what they want. Then, I moved to the startup world. I’ve been coding for over 15 years, but professionally, I’ve been doing it for 12. And this is what led me to my current role at Algolia. I’ve been there for four years and counting.

Brian: Super. Do you have any interesting lessons you learned early on that have stuck with you?

Sarah: I don’t have a classic path to tech. I didn’t go to engineering school, and it is possible to have a great career in tech if you don’t do that. You can definitely be self-taught, you can learn from other people, and you don’t have to have a degree. But not having a degree is not an excuse for not learning. There is a great blog post by Sarah Drasner, an engineering manager at Google, on CSS-Tricks about that. Even though you can have a career in tech without a degree, it doesn’t exempt you from learning and seeking knowledge.

“I didn’t get feedback, I didn’t get in conversations with other people: with other engineers, with other perspectives, other backgrounds. And so I fell behind”

And one thing that you actually learn in school is learning to learn, and that’s a really important skill. Early in my career, at the agency that I told you about, I was the sole employee for a long time. I was all alone. And I had my boss, who was also coding but was a little bit removed from the things I was doing. And although it can be freeing working alone – you have a lot of trust, a lot of freedom – you don’t learn as fast because you don’t have any feedback or other perspectives aside from your own. And if you don’t even do any active learning, you’re going to fall behind.

That’s one of the things that happened to me. I didn’t get feedback, I didn’t get in conversations with other people: with other engineers, with other perspectives, other backgrounds. And so I fell behind. I was relying on the knowledge I had, and I had no reason to do things differently because it worked. That would be one of the biggest lessons that I got early on in my career. Especially if you don’t have a classic journey on tech, surrounding yourself with other people who bring you feedback and their perspectives is invaluable, and it’s going to supercharge your career.

Brian: I think it’s great advice for anyone in any professional role, but it sounds like it really worked out for you. Do you miss anything about not working with PHP these days?

Sarah: I think PHP is a great language. You can find a lot of inspiration from PHP in modern JavaScript. I no longer work with it because JavaScript has evolved to a point where you can use it wherever you might want to use PHP. And especially as a front-end engineer, there are a lot of advantages to using the same language on the front end and the back end, like co-sharing. But I think PHP is a great language. It gets a lot of bad jokes and the, “Oh, PHP is dead,” but when you look at the success of something like Laravel, I feel like PHP is far from dead.

When I got into PHP, the framework that serious people used was called Zen framework. Actually, I belive Zen is the company behind PHP, or at least that took it back. Nobody uses the Zen framework anymore, at least not for any new projects, but it’s great to see where PHP is right now. It’s still flourishing, people are enjoying coding in PHP, and I think that’s great. It’s not for everybody, but you do you. Everyone can have a seat at the table with the language they like.

Climbing the engineering ladder

Brian: You’re currently a staff engineer at Algolia. Tell me a bit about that role and what you work on, and we’ll move on to what a staff engineer is.

Sarah: Of course. I am a staff engineer and I work on the front end. I am on a team called front-end experiences, FX for short, and we work on front-end libraries for Algolia. Algolia is a search engine, so it’s end-to-end. You have the engine and some API clients in multiple languages to send your data to search, but you also have front-end libraries, because who has time to build an accessible working search box, a list of hits, a refinement list, or a hierarchical menu?

All those things are difficult to implement properly. So we do that for customers, and that’s the team I’m working on. I’m an individual contributor (IC) and I’m not on any leadership track. But the thing is that, as you grow to higher roles as an IC, your reality blends a little bit with your leadership role. I don’t have any reports and I don’t manage anybody, but I spend a lot of time with my manager on topics that are more on the vision aspect of things. But I still code every day, and like everybody, I give reviews and get reviews. So it’s still an IC role. At Algolia, you can grow to a pretty advanced level and remain an individual contributor who gets to code every day.

“Anything above senior and you start pouring a lot of energy into the strategy – what is the vision, where is the product going to be in five years, and how are we going to be successful on those things?”

Brian: How much time do you think you spend shipping versus all the rest of the job? Sharing context, working on strategy, that kind of thing.

Sarah: That’s difficult to gauge. I would say 50/50. There are times when I code a lot, and I include reviews in coding because it’s the same energy that you use. But there’s also a lot of time strategizing, a lot of meetings, a lot of vision documents, a lot of thinking, a lot of conversation to gather feedback, like working with PMs, researchers, designers… all of that is part of the job. At Algolia you have senior staff, principal, et cetera. Anything above senior and you start pouring a lot of energy into the strategy – what is the vision, where is the product going to be in five years, and how are we going to be successful on those things? How can we make sure that, if we are not successful, we have a backup plan? Anything you could think to apply to a project like coding when you’re a senior engineer, you apply that to the strategy of the product. You work a lot on the product, and that’s one of the things I love the most about working at a tech startup.

When I was in an agency, you didn’t do any strategy, you didn’t say what you thought, and you were not necessarily expected to give advice. You did what you were told. But when you are an engineer at a startup, especially at those levels, your voice and your vision matter a lot. We are building products for engineers. And even though we have to be very careful not to build things for ourselves – we have the curse of knowledge, we know the product, we know how to use it, and we know all the caveats – we are still sensitive to what engineers care about, what they want, and what will make their life easy or hard. So there’s a huge emphasis on product, on bringing ideas to the table, on challenging ideas, on making sure that you build the best thing that will last.

“After spending years thinking about how to become a better engineer, you’ll need a mindset shift to start thinking about other things. How can I help other people? How can I unblock situations?”

Brian: How much time do you spend working with other staff and principal engineers beyond your organization or team? Is that an active community in your company? Do you get to do a lot of work in collaboration with that? Do you largely work independently in your groups? Or is there a subset of other senior staff engineers you’re working with?

Sarah: Not as much as I would want. In any organization, the higher you go in levels, the lesser people you have. So it’s not like there are a ton of IC five, IC six, staff, and principal. We are hiring a lot of senior people right now, so my answer might be different in six months. I spent a normal amount of time talking with other staff or even principal engineers, but it’s not like there is any community or anything official just because we are not that many. Now, I spent a lot of time discussing with seniors and above because that’s part of my role.

Part of my role is helping people at the senior level grow and to get promoted to staff level. As a senior engineer in many companies, especially the size of Algolia, you know what you need to do to get there. It’s more of a checklist. After that, it gets more complicated because there are a lot of things that could be up to interpretation, things that you can do very differently from another person based on your personality. But the idea is that, when you reach senior level, we expect you to be optimal in your hard skill set. We know that you’re good, you’re at a certain technical level, and we don’t expect you to grow much higher than that, but you’re going to be asked to develop other kinds of skills.

“We should find what you are good at, what you like to do that will help you shine, and cultivate that. There’s a lot of mentorship involved”

After spending years thinking about how to become a better engineer, write better code, make better reviews, or have fewer comments when you get a review, you’ll need a mindset shift to start thinking about other things. How can I help other people? How can I unblock situations? How can I create my own workload? These are not necessarily things you have to think about prior to reaching those levels. I help people approach it, understand what they mean, and understand what part of their personality they’re going to be able to use to get there.

Some people love to be on stage and do talks, for example. And if this is something they like, by all means, I should help them land better conference engagements and write better call for papers. But if this is not your thing, there is no reason why we should invest in that. We should find what you are good at, what you like to do that will help you shine, and cultivate that. There’s a lot of mentorship involved. This is one of my favorite parts of being at this seniority level.

For a company, it’s not really interesting to have one staff or one senior engineer – you want to have 3, 5, 8, 16. And the only way you’re going to be able to do that is by having the people who are already there help the people who are one level lower. You cannot expect your engineering manager to do that all by themselves with the entire team. When you have engineers helping other engineers do the work they did a year or two years before, you have this multiplier effect. And I think this is really thrilling for people because they get to learn from others, from people who actually went through the process in the same organization. There’s confidence that, if they follow those steps, if they listen, it might work. I want to learn from principal engineers who can help me understand what I need to do to get there.

It’s particularly interesting for the person teaching because they get to dissect what they actually did. It gets fuzzy afterward, and you’re like, “Yeah, I just did a little bit of this, a little bit of that.” No. What did you do? What are the concrete steps that you took? What are the things you said yes to? What are the things you said no to? I think it helps you clarify your ideas, clarify your process, and it makes you more efficient for the next ones.

Onboarding staff plus engineers

Brian: You mentioned onboarding new staff and principal engineers into an organization, which can be pretty tricky. Is this something you’ve got experience with?

Sarah: This is not something we’ve done a lot, to be honest. We have three or four principal engineers, and all of them are not on my team. The experience I have is mostly with bringing senior engineers. Now, there are things that are common to everybody, and then there are things that could be interesting for principal engineers, and I can still try and take a stab at it.

“A very, very senior person can help you with many things, but they’re not going to fix structural issues of the company or a team”

Clarity is extremely important, and, of course, you don’t expect the same handholding when you’re hiring a staff or a principal engineer. You want them to be self-starters. Clarity is not about telling you what is expected of you, all the tasks, et cetera, but rather giving you a sense of your mission. What is your purpose here? What are you doing here? And I would say this starts at the interview level. My recommendation for a staff or a principal engineer joining a company would be to ask about that because sometimes, people try to hire very senior roles to fix their problems. They’re like, “Oh, let’s just hire someone very, very senior because they know things we don’t.” And that’s not true. A very, very senior person can help you with many things, but they’re not going to fix structural issues of the company or a team.

And on the other side, an engineering manager should wonder why they think they need that person. Most of the time, you do not hire someone at this level for coding greatness. If you have a senior engineer on your team, that would be IC four at Algolia. They’re already perfectly capable coding-wise, or at least they should be. A staff or principal engineer comes with experience of something you want to do, and you might need them, for example, when you know you need to reach a scale that nobody on the team has reached before. Maybe you could figure it out, but you want an accelerator, and this is what a very senior person is going to do on your team.

Asking those questions beforehand is a good way to make sure there is no misalignment on what is expected. If you’re very senior and you’re asked to be coding or working at a senior level just because there was a misalignment, you’re going to be disappointed, and you’re likely going to leave. You do not want to spend a lot of time hiring a person at this level just to have them leave because it is extremely costly.

After that, I would expect someone at this seniority level to do a lot of reading and have a lot of conversations. This is something you don’t typically do when you are a junior engineer. You come to your organization, you’re given your first task, and it just flows – you start working, you start coding, and this is what you should be doing because this is what will get you to the next step.

“Your role is making sure the delivered product is going to fit and is going to scale. And you cannot do that if you don’t discuss it with other people in the company”

But when you are at those senior levels, it’s important you understand where you are, what’s going on, who does what. You need to create relationships not only with other engineers and senior people, but with more junior people, product managers, designers, and researchers. You need to understand the way the company works and how you can fit in that, what you can help improve. If there is any written internal documentation, read it, and when you’re done, read it again.

Then, ask your engineering manager who are the people you should meet with. Every time you talk to a new person, ask them who they think would be interesting for you to talk to. This will give you wings because you’ll create relationships and understand what’s going on. What are the products? What are the current struggles? Where you can help? And how does your team and the products you are building fit in that scheme? Because at those levels, with this focus on the product, it’s no longer just about the quality of the code. The seniors on the team are already taking care of that, and they’re doing it perfectly well. Your role is making sure the delivered product is going to fit and is going to scale. And you cannot do that if you don’t discuss it with other people in the company.

New challenges

Brian: For listeners who don’t know, Algolia is a powerful hosted search API. It looks like a pretty successful company from the outside, but I’m sure there are a lot of challenges and things on your mind. Could you give us an idea of some of the big problems you are thinking about or working on?

“The idea is that no matter what path you take to search for that data, get it, and land on the page, you get surfaced with the right data”

Sarah: As you said, Algolia is a hosted search API. That’s the biggest API we have, and it’s the most successful for now, but we’ve also expanded a little bit. Currently, there is a product called Algolia Recommend, which uses the same data set you use for search, but based on a given product, it gives you recommendations.

The point of Algolia is not only to search but to surface content. You have a lot of content, but not all of it is relevant at the same time for the same people. The idea is that no matter what path you take to search for that data, get it, and land on the page, you get surfaced with the right data. This is the point of Algolia. There are challenges with that. We are search experts, but the recommendation and machine learning aspect is a much newer technology, so we’re learning with the latest things. There is a lot for us to learn compared to search. This is not the biggest challenge, but it’s still a challenge to make sure we can reiterate the same success we had with search.

Now, there are things that Algolia is not great at. It’s a search engine, not a database. It’s going to be fast, it’s going to eventually be consistent, but you do not have a guarantee that you will have all of your data, that your data is always consistent, or that all your data is going to be there. That’s a design choice around the search engine, which makes it very different from a database. That being said, a lot of people like to use Algolia as a database because it’s very easy to send data to Algolia, and it’s there, and it’s fast. Maybe there’s something to learn around that. Maybe it could also be a database, and I’m not saying it’s going to be, but maybe it could. Maybe there’s something else out there that we have to understand and research.

There are many use cases that Algolia cannot work with. One of them is the booking use case. If you want to book an Airbnb, when you search for it, it’s in your results, meaning it’s available. But as soon as you reach the page, it’s no longer available because you replicate your data from your database to Algolia. When you save something in your database, you’re going to send that change to Algolia in a slightly different format. And because there is that delay – this is not real-time – something like the booking use case cannot work. When you’re dealing with Airbnbs, something available right now might not be available in 30 seconds, but it still might show up in your search engine because when you saved, you need maybe 10 seconds or something like that for it to be propagated to Algolia, and maybe it failed and you need to do it over again. Those are things at the search engine level that we are thinking about. Is it something that we could ever support? Is it out of the question? What is the business case behind that? Because it drives a lot of things.

“It should be invisible; it should be seamless. The fact that those are separate APIs is not your problem. That’s our problem to solve”

Now, regarding the front-end team, I mentioned Algolia Recommend. When you’re a customer, you don’t really care that there are different products. You don’t care that you have Algolia Search with those features and Algolia Recommend with those sub-features. You subscribe to Algolia and pay your monthly or yearly fee for a set of features that you’re told work well together. You do not want and do not need to understand the artificial boundaries we created internally between this API and data APIs.

There’s this saying, “don’t ship your org chart,” and I think this is one of the next big topics for us. How can we make sure that, on the front end, when you’re using the Algolia front-end library, you don’t have to wonder whether you need this or that? That you do not feel those boundaries? It should be invisible; it should be seamless. The fact that those are separate APIs is not your problem. That’s our problem to solve.

We created libraries that were really strongly coupled to the search API, and now we have to expand to newer APIs that can work together, and sometimes you need to do a call to one, then a call to another to get the final response. All those things right now are not as seamless as we would like them to be. It’s still a little bit rough on the edges when you want to connect those APIs together. It’s possible, but you have to read tutorials, follow through, do a little change here and there, and write some boilerplate code. This is not delightful, this is not fun, and it’s too much work. If we are to tell you, “use that library,” it needs to do a job you don’t want to do. There is no justification to use the library if the lower-level primitives are as easy to use, right?

Right now, one of the biggest challenges is to make sure we raise the value of the libraries. They’re already doing a lot that most people don’t want to do, but at a certain point, for certain customers, it’s not as seamless and delightful as it used to be when we only had search. And this is the feeling that we’re after. That feeling of, “Wow, it’s so much simpler than I thought it would be.”

Brian: Lastly, where can our listeners go to keep up with you?

Sarah: So you can mostly find me on Twitter, I’m frontstuff_io. I’m painfully aware that this is the worst handle on Twitter. You can also find me on sarahdayan.com and follow me on GitHub if you want; I commit things sometimes. But yeah, if you want to chat, I believe my DMs are open, so send me anything.

Brian: Super. Sarah, thanks so much for joining me today.

Sarah: Thank you for having me. That was fun.