Free Form AI

Michael Berk (00:00.945)
Welcome back to another episode of Freeform AI. My name is Michael Burke. do data engineering and machine learning at Databricks. Today I'm joined by my cohost. His name is Ben Wilson. He's wearing a robe and he...

Ben (00:14.286)
builds in product tutorials using React at Databricks.

Michael Berk (00:19.889)
Yes, once again, thank you for your service. Today, we've been chatting per usual for an hour prior to recording. And some interesting stories have come up, dealing with some potentially good people, some potentially bad people, and everything in the middle. And then thinking about how this quality of a teammate can be perceived at different levels. And Ben has led a bunch of teams, so we were just chatting about what it's like to make people cry on Zoom.

And probably not always the best solution, but sometimes it's warranted. So for this topic, we're going to be focusing on at each level of a data scientist's career. And we've been did roughly into intern, high, medium, and low. Or I guess low, medium, and high. What should you be doing in terms of benefiting the team and benefiting yourself? And then generally, what should you not be doing? What are the bad things?

Sound about right, Ben? Cool. So adding a little bit of background, humans are social creatures. When we work in teams, we look to collaborate. There's also a lot of emotional components. And as an organization, you also want to ship stuff. You want to make things that are useful, make things that work, and overall unify towards the business's mission. So starting off with an intern. Intern is typically the lowest level of a data scientist's career, I guess. And it's often where a lot of people start.

So either you're transitioning from a different role or a different field, or you're still in school and you're looking to get experience in the data science world. So Ben, what does an intern typically look to do? What should an intern try? What is their goal?

Ben (02:05.07)
a really great intern is there to learn and to demonstrate their value to that organization.

Michael Berk (02:15.229)
Did you ever intern by the way? Okay. No, Cool.

Ben (02:22.914)
I've had many interns work on teams that I was on though.

Michael Berk (02:26.705)
What are the ones that stood out? What were their characteristics?

Ben (02:30.018)
The ones that were incredibly humble and were hungry to learn asked curiosity based questions that were reasonable, that they put in some significant thought or research on their own before asking. And those questions were highly relevant to the task that they were assigned. So was like, they just wanted to usually assign an intern a project that the team doesn't have capacity for that.

It could be a pie in the sky, like, hey, we don't know if this is going to work out, but we'll learn from that. And we'll also have something really cool for an intern to say that they built during their internship.

There are times where I've had interns where it's like, Hey, half your time is going to be doing this fairly unpleasant task that the rest of the team, not that they don't want to do it. It's, it could be that, but it's more like we, we don't have capacity to do this thing that we need to do that is maybe boring to do. so regardless of what it is, a good intern will just be enthusiastic about.

doing that, not because of the end product of the result of what they're doing, but more that they're in it for the process. They kind of learn something that they've never seen before and learn it and get guidance from people who have either done it before or have a lot more context about how to do it properly.

Michael Berk (03:52.839)
Yeah.

Michael Berk (04:04.861)
Yeah, bringing that energy, think, is huge. Teams really value that. And I remember I've done two internships, I guess. And both times when I would come in, I'd be like, wow, this is amazing. It's so exciting to be working on such a challenging big problem. And they're like, yeah, I've been doing this for three years. I forgot that this is interesting and challenging and big and cool. And so that fresh perspective is really nice. People appreciate that. So bringing energy is definitely valued.

And then also as Ben, you said saying yes to everything. You don't know what you're good at. You don't know what you're bad at. Just say yes, learn, get guidance from people, and try to contribute however you can.

Ben (04:45.964)
Yeah. And also when in the process of doing that internship project or series of projects, if you get stuck, don't keep that to yourself. Like ask questions, get help. People want to help generally. And if you're at a place where nobody wants to help, then at least you know, at the end of that internship, you're never applying for a job there. But if you can have a really good experience during an internship,

by just asking questions and picking people's brains. You're like, hey, I'm kind of stuck on this thing. I'd really like to sit down for a half an hour and just discuss some of my thoughts with you and see if you can help unblock the fact that I can't figure this out. And usually a more senior person will be like, yeah, I can make 35 minutes for you. Let's chat. And at the end of that, you are probably

A, unblocked. B, you've built sort of a professional relationship with somebody that hopefully, if it went well during that discussion, that person's kind of got your back and then they'll probably be willing to help you again if you get stuck in a similar place. And thirdly, that person now has context on what it is that you're working on. if, when it comes to review time of your

your implementation, they're going to be more willing to like volunteer to be like, yeah, I'll check that out and make sure that everything is done the right way. So you will ship a better product at the end.

Michael Berk (06:25.276)
Yeah.

Michael Berk (06:28.687)
Yeah, have you heard of this theory where people are more likely to like you if they have helped you?

Ben (06:38.01)
for sure.

Michael Berk (06:39.163)
Yeah. So just if you ask for help and they do it, even if there's like a bit of resistance at first, it's hard for them not to have emotional investment in you in that project, at least somewhat going forward.

Ben (06:51.872)
provided that conversation went well.

Michael Berk (06:54.205)
True. Yeah.

Ben (06:58.454)
If it's an emotional power play that most senior people would be able to see through that, really, this person is just trying to manipulate me or something, like they don't actually need help, then that'll blow up in your face, depending on who the person is. Most senior people would get very annoyed at something like that. I would. But if it's genuine and you're like, hey, I really need advice, like, yeah, I'll give you whatever you need.

Michael Berk (07:05.095)
Mm-hmm.

Michael Berk (07:10.642)
Yeah.

Michael Berk (07:19.485)
Yeah.

Michael Berk (07:25.649)
Yeah. Yeah. Another tip that I received at my junior year of college internship over that summer was there's often this craze out of college to go get the best job, whether it be the name or the pay or the perks. And my manager at the time was like, take a step back and think about if you actually like this field, like explore it, see how we do work, see what

our actual day-to-day tasks are and see if that's something you could envision yourself doing for years. That's something that think interns are always looking to please and just get the return offer. But think critically about whether that's something you actually want to be doing because it's very easy to pivot your career and move into something else, especially if you're that early.

Ben (08:13.67)
yeah, for sure. Yeah, like I've seen interns that are effectively insulated from the team dynamic where I mean, most companies are present when included are going to put an intern on on call rotation for like severity incidents. They just don't have the background or know all the systems that are involved in, in responding to something like that. But

They should be included in those day-to-day activities. If you run a stand-up every day, they need to be there just so they can hear and listen to what's going on. During that period that they're in your team, whoever's running that meeting should be conscious of the fact that they're there to include them in the discussion. Or when everybody's firing off acronym soup and talking about systems that we all have context on.

be able to explain to that person in the meeting or that lead should take that person aside on their one-on-one, which they should be having as well, to ask them like, hey, what did you not understand at standup like last night or this morning? Or do you have any questions for me about what you heard so that they have exposure to, this is what this is actually about? And some people are like, yeah, this sucks. I don't want to do this. Like, this is not for me.

I thought I was just going to be building stuff. didn't think I'd have to maintain it. And then other people are like, that's super cool. So that's how troubleshooting is done. Got it.

Michael Berk (09:51.813)
Exactly. Cool. So that I think is a pretty good summary of internships. Do you think there's anything we're missing? You're good to move on.

Ben (10:00.557)
No.

Michael Berk (10:01.903)
Sweet. So now we're going to go into the low, medium, high categories. Different organizations and different fields define these differently, but we're going to be using Databricks as leveling principles, which closely align with Google's and generally the FAANG style of leveling. So we're going to have the quote unquote low level being L3 to L4, the medium level L5 to L6, and the high level L7 to L8. And of course, there's, again, a bunch of variation in this, but

This is just what Databricks subscribes to and it's relatively industry standard. So you have graduated from school, you're in your first five-ish years in industry. That's typically where you're going to be seen as an L3 slash 4. What are some dos? What are some don'ts? What should you be trying to do? Well, just sort of thinking out loud, the thing that I have seen really successful L3s and L4s do at Databricks is

bang out code. Basically, if you give them a task and an implementation and it just is done in a few days, that is really awesome to see. And as someone who's potentially more senior, you really value that because you can then delegate, and know that the product is going to be good. What else?

Ben (11:21.506)
Yeah, I mean, that's on the engineering side. That's kind of what those levels are designed for. It's to build your capacity for execution. Like in the first three to six months, somebody's going to have to help you out a lot. You may have done a bunch of coding before, and you may be really good at it. But there's a huge difference between I can

I can build something for a project or for like a hobbyist thing versus I can build this in this corporate environment because there's all this context that you have to know about. how is code written here? What are the style guides and what are the levels of abstraction that people expect? So that there's like the syntax related things that are important and you'll absorb that naturally over time. After your first couple of PRs, you kind of get a feel for it.

And then when you're doing something like integrating with services that run at that company, you need to understand that service and understand that source code. So you have a lot more time that is needed to be invested in a lot more questions that you're asking in order to get up to speed with, with all of that. And it's iterative. You grow over time as you get more and more exposure. Your first couple of projects are smaller, not as complex. And it's just a way of like kicking the tires, getting kind of

exposure to how the system works. Like how do we do stuff? Like what's our process for filing a PR? Do we have some specific way of doing that? How do I run CI locally? How do I run CI remotely? What do I do when I need to fix something that I messed up? Or how do I do deployments? You you work in a big enough company, there's automated systems for that stuff and people that manage that that are not on your team. And

you're on the hook if you broke something to go and fix that. So getting exposure early on to stuff like that. If you make a big enough mistake, like handling that whole process as well.

Michael Berk (13:27.847)
but also really

Michael Berk (13:32.721)
Yeah, I also think a really important thing to get up to speed on is, especially for data scientists, know your data tables. The first year is asking people, where do I find this data point? What should I use for this? Blah, blah, blah. And once you get that under your belt, you can iterate so, so much faster.

Ben (13:40.078)
Mm-hmm.

Ben (13:53.898)
Exactly. But when you're in those roles, you're kind of relying on more senior people to have been the ones that built that data set or knew that they needed to collect this data. And it's not so much that level's responsibility to come up with a whole new pipeline of things that you could use. it's

you really are in that sort of execution mode and tasks and projects are usually assigned to you.

Michael Berk (14:31.559)
Yeah. Thinking back to your experience in the field or at prior roles, specifically for data science and AI, what has been a really good L3 to L4 contribution? And it could have come from you.

Ben (14:48.346)
Usually smaller scale projects that don't involve anything where you would need to talk to another team. Like the data is already there and there's a business need to build a model that generates some predictions based on data that's fairly straightforward. And a really good implementation of that would be something that the code is structured in a maintainable way. It's easy to retrain that thing.

Michael Berk (14:57.661)
Hmm.

Ben (15:18.228)
and make modifications to it as you would need to. And there's no like super complex aspects to getting that to be a deployable entity. So you're not using some crazy esoteric framework that you read some medium blog post about that has 30 people that read it. And there's no other mention of it anywhere. Like don't use tools that

don't talk well with other systems, no matter what is promised by like the capabilities of that thing. Cause a good person in the, early, like extreme early phases of their career, they're trying to like make the best product, like solves the problem in the best, most effective way. But they might not have that context of what does this look like for maintenance? Not just fixing bugs, but like.

Michael Berk (15:54.738)
Hmm.

Ben (16:17.25)
What do we do when we need to completely redo this from scratch or bolt on a bunch of functionality to this that needs interfaces with the rest of the open source community? Are you using some like weird proprietary like file serialization format that in order to deploy this thing, there's no tooling available. So some software engineer and another team has to like build all of that.

that's now tech debt that they have to maintain. learning that about what is just good enough to make something that is stable, can be run stably at the company. That's like a mark of a good L3, L4.

Michael Berk (17:04.784)
Hmm. Yeah, to put it into like, or to take another angle to that, I recall questioning managerial decisions a few times in my career and being like, why aren't you just doing it this way? And me being sort of, for lack of a better word, annoying, I would just be like, this is so clearly the best solution. And there were a couple of times when the manager was like, hey,

Let's slow down and think about this for a little bit. Do you know all of these seven other components that are relevant to this decision? And I was like, whoa, I had never even thought about that. And they were like, yeah, that's why I'm the manager. And I was like, that makes sense. There's often so much context, even one level above, that you're not privy to that hopefully you can just take the word of your more senior counterpart and trust them because

you at these sort L3 and L4 types of levels don't always have the context. You also don't have the institutional knowledge, or as Ben was alluding to, intuition about how ecosystems work. focusing on doing the task and doing it well within the constraints you're provided is really, really good. But Ben, sort of segueing into the next level, you probably don't want to be redesigning massive systems. But how do you start thinking about that? How do you start?

building the skill set so that you are actually able to do that moving on from L3 to L4 all the way up to L5 and L6.

Ben (18:39.982)
So like we do it similar to other big tech companies, which is you're eligible for the next level when you demonstrate you can do the next level. You don't want to put somebody into that position who now has expectations based on that job title or that position that they're in, that they have no understanding of how to do that. That sets that person up for just crippling failure in their career. Cause they're like, Oh, you're, you're a senior engineer now. Like, why don't you know how to design this?

They've never designed anything like that before. That's the worst sort of sink or swim panic situation you can put somebody in. It's much safer to be like, hey, I've done this 35 times before in the last two years. This is your first time doing this. I'm going to assign this to you and you're going to check in with me before we send it out to anybody else. And then we'll work on this together to make sure that you create the best possible thing.

for this, like with the design or with the complex implementation, you'd be like the private PR reviewer, maybe even before they submit a PR. Sit and do live coding where you're like, hey, share your screen. Let's look at your code. Let's make sure that we're thinking through this the right way for the implementation. And that sort of thing is really valuable to that person who's ready to move up to that next level, but they need to find that friend.

If it's the tech lead who has really good context on that type of work that's being done, see if they have time. It's great if they do. If they don't, they should be finding somebody who can mentor you and work with you on that project. Or you just pair up with somebody more senior when they're working on something and they're delegating tasks to you, but involving you in every aspect of that project. That's the only way I've seen that work out well.

I have seen the sink or swim thing before and it's so rare for it to work out well. either get, you're either going to get a really misguided and bad project delivered at the end and a stressed out person who was doing it. Or maybe they weren't stressed out. They just didn't know how bad it was. And they thought that they were doing a great job, but nobody was checking in with what they were doing. Or you're going to get like a truly amazing.

Ben (21:08.29)
delivery of something and somebody who's so burnt out that they're ready to just either quit the company or quit the profession. So like this sucked. Like this took six months of my life. This was so stressful. I was working weekends just because they have never done it before. So they have all this like self teaching that they have to do. It's the worst possible way to like introduce somebody to something that they've never done before.

Michael Berk (21:16.562)
Mm-hmm.

Ben (21:38.968)
And I see it happen all the time. Not where I work now. We do not do that. But at previous companies, I've seen other teams do that. And I was always the person that was like, why are you throwing your people into the bus like this? They're like, they'll figure it out. Yeah, but they're going to quit. You know that, right?

Michael Berk (22:00.317)
Hmm.

Ben (22:01.75)
If you're so strapped for people, request an additional head count so you can get a senior person in here who can help mentor these people.

Michael Berk (22:11.601)
Yeah. So at Databricks, it's the same promotion philosophy where you have to be doing the level above for n number of months. Ben, what's your take on the duration to know that the person can do the next level? Like, if they do it for a week, is it good enough? If they do it for seven years, is it good enough? Like, what is the sample size that's required to know that they'll succeed?

Ben (22:34.414)
I can tell you what ours is on our side. Minimum is nine months. Typical is a year and a half of demonstrating that you're at that next level.

Michael Berk (22:44.209)
What?

Why that duration?

Ben (22:49.838)
depending on it's, it's longer durations, the higher you go, but there's only so many calendar days in a year. Right. So if, if we say it like, let's say one of the, the junior engineers on the team was like, Hey, I'm really interested in, in being promoted to senior engineer. Like this next year or something.

Then you start assigning them tasks that are at that level. Like, okay, we have this major project that we have a requirements doc, like what this feature needs to be. but it's very vague intentionally. So, go work on the entire design, like the engineering design for this, and then share that document and then go and build it and get it merged and get it deployed.

That whole process for a senior engineer level project is usually a quarter in length, so three months. But that's going to be focused on just that particular task. And you could be building something that's like, this is a new series of REST APIs.

Ben (24:08.704)
where our customers would be interfacing with this new system that does this thing, right? So that work is more, okay, you're designing client APIs. You're making sure that your interface to the backend systems is as efficient as possible. You're able to crud this data. It goes and does this thing. All of that is associated with almost like pure backend engineering.

That's just one project. That's not enough to determine like how is the expectation at that next level is you're not just a one trick pony. Like this one part of, of this discipline, you should be able to do a bunch of different things. That's not like, you have to, you have to go and pick up some front end projects. That doesn't happen. unless somebody wants to do that and they'll express that. so you would find something that would be adjacent to that.

as the next project. And you're really determining can somebody pivot from what this one project, this big thing that they just did into something that is very different, requires different levels of precision on what they're designing and building and making sure that they're adaptable to that as well. And usually you're at three or four projects that are very big, very complex. It's not like,

I built this feature and shipped this PR that's like 800 lines of code. It's more like, okay, for this project, I've got 35 PRs, each of which is a thousand lines of code that needs to be shipped. And they're not all in the same like code-based domain. They're like different systems that I'm interacting with. And I have to talk to these other teams and make sure that they're on board with what I'm modifying our product with.

Michael Berk (26:07.729)
Right. Yeah, to add a little bit of flavor, if you come from a data science or ML background, at least the way that I think about this is, think about a normal distribution. The amount of confounders on the quality of your work are going to roughly follow some sort of distribution like a normal distribution. And just by luck of the draw, you might have a really hard project that has a bunch of challenges throughout, and that's on one side of the distribution.

Conversely, you might have a project that is just everything is going right, the use case is right in your wheelhouse, there are no bugs, and everything is just going to go smooth. And the reason that you should be in that, like you want a large enough sample size to see if you're actually qualified for the next level, is to handle the variance in that distribution. So you just need sample size. You just need reps. And the reason, like as someone who is

historically tried to get promoted faster than, like at least relative to my tenure. I've been frustrated by that. And I've been like, why the heck, like I did it once. I can probably do it again. Why won't you just promote me like in my head? And the rationale is just that there isn't enough sample size to know that that one project was you getting lucky or you actually being excellent. So nine months makes a lot of sense for different

Ben (27:30.178)
Mm-hmm.

Michael Berk (27:35.505)
types of jobs, might take different durations though. Like maybe you have a very high frequency job where you can get that signal in three to six months. Conversely, if you ship on a very long project timeline, it might take years. So it's very subject to that. And at least that's the rationale that I have understood this to be.

Ben (27:53.696)
Yeah. And there's also another time factor associated with it, which is the cyclical nature of a team's dynamic over time. So if, if you have a short time period, you're like, I rocked it out. August, September, and October this year, I'm ready for the next level. You're your lead and your manager probably like great job. That's awesome. Let's see how you do over the holiday stand down period.

And let's see how you deal with what we're dealing with right now, which is lead up to our big company announcement thing at Data and AI Summit. Things become chaotic. There's a lot more pressure. You still have to deliver that thing, that next level project that you've signed on for, but then the maintenance burden for other things. People are testing things more and trying to, people are just building more features that interact with your team's code base.

So you have to make sacrifices in your own projects execution. You can't just ignore the rest of the organization and go heads down and just, I'm working on my feature. You got to help people out who are asking questions and you got to help debug things that went wrong and fix things. So there's a different dynamic at periods of the year where you may be having just a more stressful work life.

for an extended period of time and management wants to see how you behave during that time. It's not like, this person's just, they're not good. We need to get rid of them. It's more like they just need to experience this a little bit more and come up with their own ways. Maybe it's through mentoring and like discussing ideas of how to deal with that. Or they need to be an advocate for themselves a little bit more. They may need to communicate more about like, hey,

my project slipping because of these other, you know, impacting, confounding terms that are coming in. and I need to let everybody know that we're going to be delayed. And that's something that's expected at a higher level is to just communicate that and let everybody know like, Hey, this might not happen when we want it to because of this. Whereas a junior person would not even communicate that they would either.

Michael Berk (30:00.381)
Mm-hmm.

Ben (30:16.82)
work really long hours trying to get everything done, stressing themselves out, or they would just miss the delivery without telling anybody.

Michael Berk (30:28.571)
Yeah, often in these higher levels, once you get more context and more quote unquote wisdom, the answer is a reframe. Sometimes the answer is let's not do this. Sometimes the answer is let's do it a different way. But typically with L3 slash L4, speaking from experience, you're often very focused on just solutioning based on the constraints given and you simply don't have the context to reframe. So it's a very different type of thinking and problem solving.

So going back to our list of sort of the medium level of L5 to L6, it seems like we need to be supporting junior people to pre-review their code. We need to be leading these projects and doing some of the design. But we also want to be careful to not try to really influence team direction and sort of lead multiple systems. Like, where's that line between medium and high in terms of

how much you actually lead an initiative.

Ben (31:30.2)
For us medium, you are the leader of that initiative. Like that is the expected role that you're in. You're there to build a new part of the product. You're there to implement something that customers are asking for, like design it, implement it, ship it, respond to feedback, fix it, whatever you need to do. That's very different than the role of those higher levels. So.

Michael Berk (31:33.874)
Got it.

Ben (31:58.478)
The way I look at it is, uh, L3, L4 spends probably 90 % of their time, hands on keyboard, gronking out code, just implementation after implementation, getting really good at that. And if they're, if they have a really good appetite and a hunger for the next level, they're going to be more like, I want to be, I want to manage my own project. And this, then now you're stepping down from a typical workday.

no longer 90 % coding, maybe you're 60 % of the time coding. The rest of it's like doing design docs and sitting in meetings, discussing with people on other teams about what are the implications of what you're building or will this work with your system? And also diving into how are we going to run this new, like how are we going to run CI for this? And do we need, like what system will we use and what makes sense?

and doing things like metrology, setting up monitoring for this product. Like how do we know if people are using this and they're liking it? Or interviewing your actual users. Video call with them and say like, hey, can you try this out? What do you like? What do you not like? And then distilling that information in a way that can help inform your next layer of fixes or improvements to the product.

Michael Berk (33:26.769)
Right. So it's more about sourcing the problems and defining success criteria.

Ben (33:35.704)
Sourcing problems, that's more the higher level of engineer. Mid-level is more, we know there's a problem or it's something that needs to get built and we can give it to somebody who can just run with it. They'll get it done, start to finish.

Michael Berk (33:38.683)
Right, yeah, sorry. That's what I was meaning.

Michael Berk (33:48.733)
Mm-hmm.

Michael Berk (33:53.445)
And then knowing how to break up basically this large project into components, working through them efficiently, and then potentially delegating to L3 L4. Got it. OK, that makes sense. Thinking back on your career, have you collaborated with an L5 or L6, or as an L5 or L6, done something that you think is a standout or a really good example of what a good contribution should look like?

Ben (34:02.594)
Mm-hmm.

Ben (34:20.322)
I mean, think a really good way of handling that is making sure that upfront, you were very thorough in your design about what it is that you're proposing, not just from an implementation perspective, more importantly, from a product perspective. Did we think about how people are going to use this? And this applies to whether you're a business to business company like ours.

where our users are other companies that need to use our platform to do their job. And to internal use cases, I like previous jobs I've worked at, I'm building a series of models or some solution that no human outside the walls of this company is ever going to use this or interface with this. But this is going to power a part of our product or is going to power our business in some way. So I have internal customers.

And making sure that that is done before I write a single line of code so that I have context on what the constraints are of what we're trying to do. Like, what does this actually need to do? What is the minimum amount of stuff that we need to build to solve this problem? And that's my goal at all times is like, what is the minimum amount of work? And then from there, you can say, okay, I've identified the minimum amount of things.

but here's some cool things that we could do in addition that might be useful, but not work on those until they're asked for. But it helps me when it, going through that process of understanding what we could potentially do in the future, that informs the design and the implementation.

So if there's, if there's nothing in your could haves that is actually useful or the minimum product is just the solution of what it is. Like we need something that can forecast our sales, by product line or something. Okay. that sounds like that's the minimum thing that we need to do is we need data that projects out to this time horizon.

Ben (36:35.48)
based on these groups. And this is how people would be using it. I know that they would use it this way because I went and asked them, what do you need? How would you would you cut this data in any other way? Do you actually need this on the skew level or do you need this on like product group level or do you need it by locations on the planet, like where we have our stores or where we're selling to? Do you need to group customers up in some way?

Michael Berk (36:58.791)
Mm-hmm.

Ben (37:03.064)
So I'd ask all those questions and get that design written up so that I understand what it is that I'm building.

Michael Berk (37:12.187)
Right.

Ben (37:13.742)
But with the could-haves, that's more like, I'm working on this project that could potentially have these additional 10 features built into it, like cool things that people would have asked me about during our interviews. I told them, that sounds cool. I don't think that's part of the first phase of this, but I'll put that down on my design doc.

But what that helps inform while doing designs and implementations is I'm not going to make some rigid interface that makes it very painful to do those could haves in the future. So you have to think through of like, do I need like a layer of abstraction here? Because we might need to, you know, do another version of this that we could, if we do have that or these other three versions of this thing.

Michael Berk (37:54.599)
Mm-hmm.

Ben (38:12.118)
if I do this level of abstraction, that extra work is going to take a week. But if I didn't do this layer of abstraction, that extra work is going to take two months. So I build it with the abstraction built in.

Michael Berk (38:25.211)
Right. Got it. That makes sense. So you're sort of a master of turning a problem into a scalable solution.

Ben (38:34.764)
I mean, it's a good skill to have. And if you don't have that skill, you need to make sure that the people who are reviewing your implementation, the more senior people than you, that they're good at that. So they can provide you feedback to be like, Hey, you might want to do this differently.

Michael Berk (38:39.001)
you

Michael Berk (38:58.247)
Yeah, that makes sense.

Cool. I'm trying to think of some good projects in my history. But I think the abstract is concrete enough. It's just you're given a problem. You know how to solution. And you know how to delegate and project manage so that it's built end end in the correct way and actually solves the true problem. So there's the.

Ben (39:23.05)
Mm-hmm. And the inevitable time when you build something that doesn't solve the problem, you can rapidly pivot and fix that.

Michael Berk (39:32.007)
Yeah, exactly. Cool. So that's L5 and L6. We mark that as in your 5 to 20 year career mark, but screw that because screw that. Moving on to L7 and L8. So these are typically leads and software, at least at Databricks, it's senior staff and principal, right?

Ben (39:57.549)
Yeah.

Michael Berk (39:58.277)
And then in the field, we call them leads and principals. And then it might change throughout your organization. But this is typically the top of the IC world. And then you might have some distinguished engineers here and there. But these guys and girls are going to be leading your team, figuring out product direction. They're going to be managing the people who manage these projects and more sourcing the problems and figuring out just overall direction of an entire org.

So what are some do's, what are some don'ts?

Ben (40:30.702)
So to go back to the how many hours a day spent coding corollary that I did before, L7 and L8, it's more like 10 % of the day would be running code. Unless you're in research, then you're probably always at 90%. But if you're in a typical product-based engineering organization, they're in a lot of meetings.

They're doing a lot of reviews of complex designs. They're doing like strategic work. Like what should we be doing over the next year? What projects should our organization focus on? And what teams should be involved in building those out? There's also a personnel aspect to that sort of role where they have to know who's in the org, who can do certain things.

But a lot of the focus that they have is more like tightly wound in with the actual business itself. Like what are the strategic initiatives that we should be like focusing on and what are our options for doing that? So they might write some prototypes, like try to get something to work that nobody's even thought of before. And then they take that prototype, hand it off to like a staff engineer or senior engineer and be like, Hey,

go build this for real based on my little weekend prototype thing that I did up. Because I think this is a good idea, or at least start the design process for building this feature. Or they're also talking to peers in other companies that they have relationships with and building either integrations with them or figuring out

Like how are we as an industry gonna be approaching these sorts of problems?

Michael Berk (42:29.073)
Yeah. Out of curiosity, how do you think or what's an efficient way to source industry trends?

Ben (42:40.416)
I mean, the best ways, if you have customers, ask your customers and interview a lot of them. Look at your usage logs. Who's using the APIs the most. Talk to them frequently. Ask like, what are you using this with? How are you using this? What do you like? What do you not like? More importantly, what do you wish was changed? What's the one killer feature that you wish we had? They'll they love saying like telling all of that stuff.

Michael Berk (43:05.021)
Mm-hmm.

Ben (43:10.52)
They thoroughly enjoy those conversations. I do three or four of them a week and you get a absolute gold mine. It's a win-win situation, right? They get to ask questions. like, we're kind of blocked on this thing. Do you have any insight on how we could do this differently? If I was the one that like designed and built that, yeah, I'm going to tell them like, here's a cool thing that you could try instead. So they get something out of that big time, but they also get the ability to.

Michael Berk (43:12.637)
Yeah.

Ben (43:39.534)
tell you what they don't like about your product. And I'm just writing all of that down and saying like, okay, at our next quarterly planning, like, hey, these 17 customers really don't like this thing. We should fix this thing. Let's come up with a solution to make that better. And then you check in with them six months later after it's released. And sometimes they're like, this is awesome. Thank you for building this. This saves so much time for us.

Or sometimes they're like, yeah, thanks, but we actually want these three things as well. They're like, okay, that shouldn't take too much time to do. We'll have it ready in two weeks. Thanks. Thanks for the feedback.

Michael Berk (44:26.085)
Right. Out of curiosity, do you enjoy that process? Okay.

Ben (44:30.412)
Yeah, it's super fun.

Michael Berk (44:34.298)
Interesting. I still like building a lot, so maybe I'm not wise enough to enjoy that. Maybe one day.

Ben (44:43.256)
I mean, I like building as well. mean, being able to put headphones on and crank some music and blast out an implementation. It's just depending on what I'm doing. If it's something that I've done before many, many times, I'm doing it because I just need to get it done and I can do it very efficiently and get this implementation out in a very short period of time.

Michael Berk (44:45.436)
Mm-hmm.

Michael Berk (44:49.713)
Yeah.

Michael Berk (45:11.985)
Mm-hmm.

Ben (45:12.494)
It's not because I'm like some elite coders like so good It's just when you do some something so many times. It just becomes easier and you're like, yeah I know how to create a rest API like created a ton of these things. So it's just very quick But a lot of times the more senior that you get the more ambiguous projects you get or sometimes you get the opportunity to pick up work that

Like you have, the thing that I said at the beginning of this recording, doing in product documentation, right? This isn't actual docs, it's features in the product that you can like click on things and you're optimizing a workflow for somebody to get started really quickly, which we don't have a lot of that in our product right now. We will be building more of that going forward.

Michael Berk (46:00.157)
Mm-hmm.

Ben (46:11.022)
because it's the right thing to do. But I don't have a background in writing React, like at all. I've done data science and backend development in my career, that's it. But the opportunity to like figure that out and learn from our more senior front-end developers, we have fantastic front-end developer embedded in our team, Daniel. Dude is cash money.

Michael Berk (46:39.719)
Thank

Ben (46:41.418)
and know so much about design and implementation in front end. So getting a chance, I saw it as like, I get a chance to learn from this guy about how proper professional front end code is supposed to be done. I see it as an amazing opportunity, even though what I'm doing isn't that exciting. But I've never done it before, and I get to learn from a really good person.

Michael Berk (47:05.18)
Right.

Ben (47:10.316)
So the more senior you get, have opportunities like that, where it's like, Hey, are more junior people, they might be, you might ask them if they want to do it. Usually a more junior person is like, I'm good. Or like, no, I'm not interested in doing that. That might be, they're afraid. Like they don't want to have to burden themselves with learning so many things so quickly. Cause they're probably not bored with what they're doing. They're still in that sort of.

Michael Berk (47:25.575)
Yeah.

Ben (47:40.108)
earlier career phases learning like their back end skills.

But as a more senior person, you're like, yeah, don't need to do the backend stuff all the time. I want to try something new.

Michael Berk (47:55.537)
Yeah, exactly. So that makes a ton of sense. I guess wrapping with this sort of final topic. So we've talked about four-ish levels. What is consistent across all levels? And this can be embodied or like stereotyped as the culture of a team. But what makes this system work and what is required for everyone on the entire team to exhibit?

Ben (48:23.064)
to collaborate and that takes the form of junior people asking when they don't know, senior people answering when they know. When nobody knows, you all think together. When everybody knows, you make sure that you're getting effective review and you don't become complacent. And then when somebody needs a rubber duck, be available.

You have no idea how many times we have one-on-one meetings among people in the team where somebody just seems like they're stuck thinking through something or they don't know like the right approach. And we'll get on a call. I'll ask maybe three or four questions and provide zero answers and they solve their own problem. So that's I'm a rubber duck. I'm like effectively a rubber duck on their desk that they're talking to.

They just needed to talk through it to come up with a solution. So that collaboration in a team is absolutely critical. And plus you end up like building relationships with the people on your, that you work with on a professional level, which is really good. Need to have that communication with them.

Michael Berk (49:45.669)
Agreed. Sweet. Anything else before I wrap?

Ben (49:49.858)
We didn't really cover all the negative aspects of what we were, we were setting out to, but I'd say there was a universal negative aspect, which is letting ego get in the way of you either think you're the greatest thing ever and act like it and are not helpful to other people. Just kind of like judging other people competing. That's probably the most toxic behavior I've seen in, I've never seen it at Databricks in engineering, at least.

Michael Berk (50:00.882)
Hmm.

Ben (50:19.95)
But I've seen it at many other companies in the past and that sort of genius level jerk mentality. I've never actually met one of those people, by the way. I've met a lot of jerks in my career, but anybody who happens to be a complete asshole is actually not smart. They might think that they know more than everybody else or people might have that perception, but

no highly intelligent person behaves that way to other people. It just doesn't happen. What's that? Yeah. So I've always found that sort of moniker to be kind of a...

Michael Berk (50:52.923)
Yeah, sort of by definition. Yeah, sort of by definition. Like, yeah.

Ben (51:05.031)
not something that's

Yeah, that sort of toxic behavior is universal on all levels about that, like, ego getting in the way from the toxic perspective of thinking that you're smarter than everybody else. But there's also an equal risk where if everybody's ego is actually being applied in the inverse of that, where you assume that everybody around you is

just a genius and you start thinking like, am I the dummy here? Am I like the dumbest person in the room? That's a good way to keep humility. And I think everybody should think about that from a perspective of if you're in a like a high performing team and everybody's really good, you should just have the humility to realize that these are all highly intelligent people and their opinions matter. And I should

seek out their opinions on things, involve them in decisions because they're very good at what they do. But you shouldn't get into the toxic form of that, which is just thinking that you're a complete moron, like super bad imposter syndrome. And I've worked in teams where everybody has that feeling, end up getting to know them well enough and you start asking them pointed questions about that. You realize like,

and have to actually tell them and educate them. Like you're not dumb at all. You're phenomenal at what you do. Don't be so hard on yourself. Because it's not good for your psyche to like be in that mode for a long period of time.

Michael Berk (52:56.709)
Yeah, that reminds me, just quick question.

I feel like there are different levels of feedback that you can provide in terms of quality. And I've noticed that when I typically start losing that humility and thinking that someone is quote unquote dumb and dumb is definitely the wrong word, but like,

It's because I am not putting in enough effort to hear what they are struggling with, or they are not putting in enough effort to communicate what they're struggling with. So in your opinion, what's the most efficient amount of communication? Like, can someone send you a Slack with typos that's, I don't know how this should work. What's your thoughts? And then you glance at it during a call, respond back. Or should it be a lot more prescriptive where there's like a design doc?

They send it over, you spend 15 minutes reviewing it end to end and then give them thoughtful feedback. Like, is there a rule of thumb for how seriously you should take these questions?

Ben (54:04.202)
It depends on the context. So if I'm getting a question from somebody that's like on another team and they want to know why an API works the way that it does, I'll set aside 20 minutes to respond to that. Like I'll go into our source code system, give them links explaining how this thing works. Cause you're unblocking somebody by giving them like the full context of what they need to know. Cause if they're asking that question, I kind of

Michael Berk (54:18.012)
Got it.

Michael Berk (54:26.813)
Mm-hmm.

Ben (54:34.562)
can infer that they're going to be needing this other information as well. So it's more from an efficiency standpoint and people appreciate that. It's like, Whoa, you just wrote like three paragraphs of a response to me with all of these code pointers. How did you know that I needed to know all this other stuff too? Cause I was about to ask that as well. So put, put yourself in their shoes, looking at your own product that, that you maintain. But if it's something like, Hey, I want to build this feature.

That's...

sufficiently complex is it cool if I just file a PR? Usually that is responded with, hey could you send over your design doc because of this there's a lot of implications to this what you're proposing and if they're like well I don't have a design doc I was just gonna bang this code out and like we should have a discussion on like what it is that you're building here and what the

Michael Berk (55:32.231)
Mm-hmm.

Ben (55:34.754)
the implications to the products and other APIs are and what the user journey is going to be for using this thing. That's super critical to have that sort of a response. And then you go through a review where you, as the person being asked for assistance, that might take six to 12 hours of your time of like going through a design doc and leaving comments and thinking through it. Or if they have prototype code, go run their code and see what it's like.

Michael Berk (55:54.225)
Right.

Ben (56:04.882)
and have consistent feedback with them over a period of time. And then when they start implementing, review that code and make sure that it aligns to what the design doc agreement was. Does it do everything that we said it was going to do? The other form of feedback is nobody asks for help. They're working on something. They just file a PR and they tag you on it and you look at it and you're like,

Michael Berk (56:17.969)
to.

Ben (56:33.542)
this is not correct. Not like, I don't like the way you wrote this code. It's more like this doesn't do what we're, what it's supposed to do. Or it doesn't work in the, in this fashion. Or there's going to be a bug here or, Hey, where are your tests for this component or this aspect of the code? That's a different sort of feedback. That's asynchronous offline sort of via an official means of providing feedback in like

Michael Berk (56:55.815)
Right.

Ben (57:02.904)
GitHub. And if they want to chat about that, sometimes people will reach out and be like, actually, can we just talk about this? Sure.

Michael Berk (57:03.719)
beer.

Michael Berk (57:12.44)
That makes a ton of sense. OK, cool. Well, I think we got to, at least I have a fat list of notes to summarize. Anything else before we wrap up? Cool.

Today, we spoke about leveling. This is hopefully consistent across a lot of the tech industry. It's definitely consistent across FAANG style companies, Databricks, et cetera. And it should hold true to a lot of data science teams specifically. But it also expands to software, what I do field engineering, and other areas as well. So starting with the first level, typically it's an intern. And you're often still in school or transitioning from a different role.

The dos are you should be looking to learn. A second is you should also be looking to create a tangible project that would give you some sort of a resume piece. And a great way to do both of these is just say yes to everything. Bring energy, bring a can-do attitude. I think you should try to avoid is hiding your lack of skills. If you're stuck, ask for help, because odds are someone has a better idea. Next is L3 to L4.

The way that you can think about this level is you were assigned stuff and your job is to build the thing. So the do's in this scenario is produce. Make sure you just write a bunch of code that works. Start getting robust understanding of the company ecosystems. Often the systems are very complex. So just try to explore and then also try to build relationships within your team to get support for your learnings. And then one of the don'ts is try to redesign systems. I did this like

three months into my first job, and they were like, great idea, go back to writing dbt models. I was like, OK. L5 to L6 is you are given a problem. It could be a one liner or even a little bit more detailed scope, and your job is to build a solution and bring it end to end. So some of the dos is you need to support more junior people and pre-review their code. You need to lead the project and, as we said, own it end to end.

Michael Berk (59:17.969)
And also think really critically about the design. So will this actually solve the business need or the problem statement that has been provided? In this area, you probably also shouldn't look to lead the team direction. That's more of an L7 and L8. So for L7 and L8, your job is to provide value. It's as simple as that. You're given a team and resources, and you quote unquote, provide value to the organization. So some do's is you need to source problems, work with customers.

And also you want to be building prototypes and proposals for your team to explore and flesh out. And unfortunately, if you like to code, you will typically be doing less code.

All right, still going. Tips. If you're ready for the next level, you need to demonstrate that for some amount of time. And the reason is there's just uncertainty in how your products will shape out and how easy or hard they are. And also, there's seasonality within your team. So you need to be doing this for some amount of time. And then the consistencies between all of these levels, typically with a respectful team culture, kind collaboration is super important. So if you're junior,

Make sure you ask, make sure you speak up. And if you're senior, make sure you answer. And finally, don't be an asshole. Anything else?

Ben (01:00:34.254)
Perfect.

Michael Berk (01:00:36.925)
Cool. Until next time, it's been Michael Burke and my co-host. And have a good day, everyone.

Ben (01:00:40.546)
Ben Wilson, we'll catch you next time.