sef.kloninger.com (Posts about Management)

A Good Interview Question

Sef Kloninger — Tue, 07 Oct 2025 22:00:00 GMT

I liked the question that I got when interviewing at YouTube in 2015. At Google then we'd have an interview panel of four or five people, each assigned to cover a different area. Billy Biggs was the TL on my panel asked to evaluate "architecture." For a manager candidate that mostly meant evaluating technical cluefulness (someone else had me do some simple programming).

Billy's question: Discuss what would cause a Python interpreter to crash. Not a program written in Python, but the interpreter itself.

I remember this leading to a fun, rambling, back-and-forth discussion of the ways computers can fail. There are so many! Every level of the stack can fail in interesting ways: storage, RAM, memory management, networking. How would a bit flip in a TLB manifest? How does TCP/IP detect and handle ordering? collisions?

We also covered a bunch of engineering and process questions. How is the interpreter itself implemented, in what language and by whom? What would the quality processes be like for a product like that, especially given Python is presumably a really large open source project? How would you manage this? How important to quality is the role of the BDFL?

And then that lead to a some more interesting higher-level discussions about the actual costs and benefits of addressing failures like these in the field. When should programs hard-fail versus detect and recover? How would you staff an engineering team to find and chase down errors? What's the user impact to a failure like this?

One of my favorite things about this question is most likely it was something they'd actually seen right in their backyard. In 2015 significant parts of YouTube was written in Python (that's likely not the case anymore, I don't know). Crashes like these must have come up in the field. Not only are real-world problems relatively easy to ask, but they have the added benefit of showing the candidate the kinds of issues that the team actually deals with. It's also a well-shaped question: open ended, no right/wrong answers.

I got the job.

Learn From Experiments

Sef Kloninger — Tue, 23 Sep 2025 18:00:00 GMT

What's the value of an experiment or a prototype?

There are all kinds of ways to have impact. A feature can improve user experience; a hardening project can reduce risk of a production outage; refactoring or test coverage can improve velocity or make software easier and safer to maintain. And good engineers care a lot about impact. While it's not the only thing that matters (the "how" is important too), if you start with impact, you'll generally do well.

An engineer's job to put ideas into practice, to make things. But sometimes we're not sure what to make. Or we think we know, but aren't sure it'll work. The best way to figure that out is often running a set of experiments, or maybe building a prototype (an n=1 experiment).

But crucially, an experiment doesn't have value itself. An experiment is successful only if we've learned something. The intent of the test rig or prototype isn't to live on. Indeed, knowing that we plan to throw it away is part of what makes it fast and cheap to build, and it shouldn't have all the trappings of production-quality software, like test coverage and code reviews.

So how do we ensure that value gets delivered? When you work in a team or a company people turn over. It's not just enough to do the experiment, you need to write it up and share your results. To produce a good writeup, you should:

Figure out the hypothesis(es) you're testing. Often this is in the form of one or more questions. For prototypes, it might be a boolean, i.e. we can build X that will work. But even then, consider what "done" means. Stating your hypothesis in terms of a metric is often easiest. NB I find the goal/driver/guardrail framework from Thanks Diane's book helpful, Trustworthy Online Controlled Experiments.
State your assumptions and method. This is where you usually get the most feedback. Note that this usually isn't a project plan, as your reviewers usually don't care how long it takes or what happens when.
Seek feedback from your peers. Publish the doc stating the method to have smart people poke holes in your plan and make sure what you're measuring will actually address the hypothesis. And then when the experiment is done, get it reviewed by someone senior to ensure that your work supports your conclusion. This also spreads knowledge about this work (both that you're doing it, and the results) so the overall organization benefits.

The artifact produced has many benefits. It's useful for you as you discuss follow-on work; it's useful come performance evaluation time. But most importantly, it benefits the organization. Contemporary and future peers can learn from this work.

You'll benefit from taking the time to write it up, the reviewers learn from reading, and it'll live on past your time with the team.

Sponsoring

Sef Kloninger — Sun, 30 Mar 2025 20:00:00 GMT

Sponsorship is using your position and influence to help someone get ahead. It's similar in many ways to mentorship, the topic of my last post. But sponsorship is a bit tricker. Most people understand mentorship and have good feelings about it. Sponsorship is a bit less familiar and might even feel a bit unseemly — at least it used to feel that way to me.

Although I'd heard the concept before, a talk Carla Harris gave at Google in 2022 made an impression on me and brought it to the forefront. (She has a 2019 TED Talk that hits a lot of the same points). She spoke about the value of sponsorship, both on the receiving end early in her career and now as a sponsor herself. More than just her description, what I most appreciated was her candor. It gave me a permission structure to use this concept myself. I started using it with junior engineers when thinking about their careers; I thought about it myself when debugging how some decision played out. It also helped me to think of it less judgmentally. Now I see it as being thoughtful and pragmatic about how decisions are made.

So what it it? Sponsoring is similar to mentoring in that it's an investment in someone, but the mechanism is different. Mentoring is a commitment to problem-solve issues as they come up, teach skills, and serve as a sounding board, amongst other things. Sponsoring is more strategic. The sponsor is committing to understand the sponsored's goals and strengths, and (here's the important part) help them get ahead. The time commitment isn't as large, but the actual commitment is greater. Assuming they see eye-to-eye, the sponsor commits to putting their reputation on the line to help the their person achieve their goals. Some examples would be vouching for the sponsored during a staffing conversations or seeking out and advocating for them when opportunities comes up.

In some ways, sponsorship acknowledges and even co-opts the "you have to know somebody" way that the world actually works. Underrepresented groups can benefit from sponsorship as a way to wedge into existing power structures. If that describes you, consider asking for someone to explicitly sponsor you; if you're in a traditionally privileged group, consider sponsoring someone who isn't so much. My Google peer Rachel observed: "women are often over-mentored and under-sponsored."

Maybe You're Going Up For Promotion

With this in mind, let's apply this to promotions.

Try as we might to bring rigor and de-bias these decisions, they are complicated and are made by real-world humans. Organizations rely on their senior people to bring their experience, knowledge, and judgment to bear.

Consider how the promotion decision will be made for your case. One key question is who'll be in the room? This isn't just who is invited and who will attend, but more who will be influential in the discussion and decision making process, and for what kinds of questions. Not everyone has an equal voice.

Say you're an engineer going up for promotion to senior engineer. Then likely a senior tech lead (not necessarily your tech lead!) will be asked to speak to the quality of your work (e.g. good code, considered alternatives, future-proofing). A senior manager will likely be asked to assess how well you worked with others and made good decisions. And these are just two of the factors — there will be many others depending on your role and level. You need to work down the rubric and think through who'll be asked to attest to each area as it comes up. Who will be asked to speak to concerns when they're raised ("was that really that hard?")?

Sometimes you might know who the key person will be, but often you won't. Enlist your manager or other senior leaders to think it through with you. Game plan the decision out.

And then assess their level of support. This may be something you can do yourself (if you have a relationship already) or maybe you'll need your manager's help. But somehow you need to ask them, as candidly as you can, "If asked about X, what will you say?" It can sometimes be hard to get an honest answer, so you may need to push a little. Reassure them you'd much rather know now if you have their support or not and you're not going to hold it against them.

If you don't have their support yet, that's OK. Think about work you can do to change that over time.

Day-To-Day Decisions

Not all decisions are as high-stakes as promotions. Leaders make decisions all the time, like whom to trust to lead a project or run a meeting. I like to think about these small-but-important decisions too in the context of sponsorship. Is your manager your sponsor? What about your TL?

Thanks to Josh Loftus, Maren Stever, Jane Manning, and Rachel Grey for their reviews.

Mentoring

Sef Kloninger — Sun, 07 Jul 2024 20:00:00 GMT

So you're looking for a mentor, that's great! I've benefitted a lot from mentors in my career. It'll be a valuable experience for both you and your mentor. This post has my tips for finding a good mentor, asking them, and maintaining a good ongoing relationship.

Choosing

These are my three go-to rules for finding a mentor. They've held up across many companies and years.

1. Your mentor should be someone you admire. The best choice is usually someone the same career path as you, but further along by some years. They don't have to be so much more senior, it could just be the next step, but they've shown that they're willing and able to take on more responsibility and how to do it at your company. Ideally they're someone interesting, inspirational, and relateable.

Another type of mentoring relationship is when you're looking to make a change — say from Engineer to Engineering Manager, or Engineering Manager to Product Manager. Then you're looking for someone who made the switch. I find they're often the most eager to talk about how and why they did it.

2. Organizationally close-by is OK, but they shouldn't be one of your leaders. I've gotten the most out of mentors outside my chain of command. That way, I never had to worry about choosing my words (or topics) carefully. I could problem solve or just vent. Sometimes the person you need to discuss is your own boss.

3. Rapport is super important. Maybe the most important thing of all. Your meetings can't feel like a chore for either of you. Even if you've gotten along fine in the past, maybe you'll hit it off in this new relationship, maybe now.

How can you find the right person if it's not obvious who to ask? Use your network, talk to people, ask for referrals. Big companies often have mentoring programs for matchmaking.

Asking

While your mentor will benefit a bit, you'll be the one getting the most out of this deal. So it's up to you to ask. Understand that they're likely busy, so say how much you'd appreciate some of their time. Make sure they know it's OK to say no.

I recommend asking for a trial run to start with: "Let's do three or four meetings and then re-evaluate." That way you can make sure that it's clicking, see the "rapport" criteria above. If it's not feeling great on both sides then it's best to try again with someone else, no harm no foul.

Being A Good Mentee

So you've found someone, great. Here's some things you should do during probation and onward.

1. Respect their time. Be prompt. Work around their schedule and in a way that works best for them (30 min? over a meal?).

2. Come prepared with a topic or two, keep a backlog. It can be something specific, like problem solving a particular situation or relationship. Or it could be getting just-in-time feedback on a draft email or document. Or it could be open-ended, e.g. "if you could advise your former self 10 years ago, what would you have said?"

3. Check in from time to time. Make sure this is still working out for them: the style of meeting, duration, etc.

4. Find an appropriate way to thank them. Nothing big but it's important to show that you appreciate their time. For example at my current employer (Google) we have a system to give shout-outs to peers that come up at performance review time.

Finally, find a way to pay it forward. Introduce mentors and mentees; volunteer in your company's matchmaking service; find people who appear to stranded and offer to help them out. Sending this post might be a fine icebreaker.

Bring Me {Problems,Solutions} Bosses

Sef Kloninger — Sat, 16 Dec 2023 23:00:00 GMT

Some bosses want you to bring them problems. They like to unscramble Rubik's cubes and are happy to work through it with you. Sure it's great if you have a proposal or recommendation, but be prepared to show your homework.

Other bosses want you to bring them solutions. If you bring them a problem, you'll get annoyance and "what do you want me to do about it?"

Most bosses have exceptions by domain. A common pattern there is the bring-me-problems boss who is also a techie -- they'll want to dig in planning, say, but prefer you to solve messy people conflicts yourself.

I've worked with both and each has their virtues. When you have a new boss, figure out their style and adjust.

Why Is That Feature Taking So Long?

Sef Kloninger — Fri, 25 Jan 2013 09:24:48 GMT

I've observed a recurring source of tension: building things fast vs. do it the right way. Usually you're not lucky enough that you can do both. This post explains a bit why we (engineers) care so much about building things right. Even when things are overdue and our stakeholders (end-users, biz folks, product management) are pushing to just get it done.

You can describe the two poles here in pejorative terms. Fast is slapdash, quick and dirty, bad software. The right way is really just ivory-tower over-engineered turd polishing. Is that fix really so important that we shouldn't ship it? Do you really need to refactor that now?

I see three things driving engineers to build it right.

Wrong is insidious. A story: early on in Class2Go every page began with a fetch of some basic page data. If there was an error on lookup we would throw a 404. Not only is "not found" the wrong message, but it also isn't helpful. It covers up all kinds of other problems, in a way that is really difficult to debug.But for an engineer, these programming messes are broken windows. Not only do they cheapen the project, they encourage others to take bad shortcuts. Heck, if they can't be bothered to handle exceptions correctly, then why should I?
Wrong is the express train to support hell. Unless you leave the company or project, you'll be called upon to support your own crappy code. That is certain. And there is almost nothing worse than being dragged back to debug some old code that you never meant to become production, and is now breaking the world.
Wrong hurts your reputation as an engineer. People see you taking shortcuts and infer that you are a sloppy programmer. And really they aren't wrong to do so. One habit of really good engineers is they don't leave a wake of messes behind them. They are able to do things (mostly) right even when they are moving fast.

This last point is really the key one. Amongst engineers your reputation is your hard currency. It affects what projects you're invited to work on and what companies you'll be asked to join. Most importantly, good engineers only want to work with other good engineers, and they won't seek out someone sloppy. So I assume that any code I write will be looked at by a potential colleague or employer. This is especially true when working on an open-source project.

This doesn't mean you have to go slow -- indeed, on my current project, Class2Go, we get a lot done every week. What it does mean is that sometimes I'd rather not do something than do something I know will come out poorly.

So, product manager waiting on a feature. What to do if you're waiting on an engineer and you think it's taking too damn long? The tactic **not** to use: tell them this won't matter and to just ship it. That will just piss him off. Better: get your senior engineer to convince the junior one why it's good enough to ship and reason about what really needs to get done. Exception: if the engineer you're waiting on is your senior engineer, then trust her judgment and wait.

And finally, to you product managers and biz folks who push. You are right do do so. That's all that matters to the customers, all matters at the end of the day. Keep it up.

Two Things At Once

Sef Kloninger — Tue, 05 Jun 2012 20:50:39 GMT

Engineering management is about solving problems and removing obstacles. You always have more problems than time and resources to solve them. How can you stay on top of it all?

A trick I learned from Julia Austin (my boss at Akamai some years back) was force yourself to always solve two problems at once. Before jumping on today's problem, figure out something else you can fix at the same time.

Say you have a retention problem. Engineering department scuttlebutt is that people are burned out with maintenance projects. But you are also concerned about your low bus number. I had these two problems once, and my answer was to actively shuffle engineers around onto other projects. Not quite musical chairs, but close. It worked. The engineers liked the variety, and I gave my top performers first dibs on projects, which they appreciated. There was a short-term productivity hit, but it was worth the benefits from cross-pollination and engineer happiness.

Another real-life example. I had a remote office that felt disconnected and needed some knowledge-sharing love. I had to send someone over for a few weeks. I initially planned on sending my go-to senior person, but they had had been before and to them an international trip was a chore. Instead I had an up-and-coming engineer who I wanted to invest in. This trip was a stretch for her, but I did some coaching and she did great. Plus she saw it as a perq and appreciated the responsibility.

This technique has driven a couple good behaviors for me as an engineering manager. I try to take a minute before jumping in with a solution to see what else I can do while I'm at it. It also has helped me to keep a useful (and secret) worry list and to consult it from time to time. That list is a useful way for important but not urgent problems to get mindshare. Reviewing that list became part of my Sunday evening get-ready-for-the-week routine.

FizzBuzz Questions for Engineering Managers

Sef Kloninger — Wed, 23 May 2012 17:06:59 GMT

You probably wouldn't hire an engineer that you hadn't seen code. But people tend to hire engineering managers without seeing them manage. I contend that's a big oversight: you should see them manage on their feet, at least a little. But how?

I'm thinking along the lines of the "FizzBuzz" class of questions. I believe they got some fame with this article in 2007, and Google seems to support this. Anyway, they are simple programming problems that should be no-brainers for any decent engineer. But they are useful exactly because of the surprisingly large number of candidates who flame out on them. By some accounts, as high as 50%.

So what we want are something similar for engineering managers: practical questions that can be done within the constraints of an interview. Here are a few that have been useful for me.

Role Playing

Instead of asking them how they would do something, just ask them to do that thing in front of you. Role playing can be awkward if you've never done it before, but give it a try. Once you get over the hump and try it, it can be fun. Here are three good scenarios I've used.

"I'm a product manager. Customer Foo (say, one of our biggest customers) wants a feature right before the release is to go out. You're the VP of Engineering. You feel like this will destabilize your release. How do you say no?" Sometimes it can be fun to play out the natural follow-up, when they go over your head to the CEO.
"I'm a slacking employee. I have the skills, but for some reason I haven't been productive lately. It's our weekly one-on-one time -- what do you say?"
"You have to lay someone off. How do you prepare? What do you say?"

If they have follow up questions, or dispute the premise, then play it out. Usually those end up being the most insightful and fun interviews. Also, one warning: questions like these can take you far down the rabbit hole and use up the whole hour if you're not careful. Remember that its your time. You should cut them off and switch to the next question, abruptly if need be, to get to everything you need to cover.

Nuts and Bolts

Ask candidates about the mechanics of how they do their job and you can get insight into their experience and values. What tools (wikis, bug tracking, source control, continuous testing) do they use? Do they run team meetings or daily standups? If so, how do these go?

What you're looking for are thoughtful answers. Anyone who has used these tools a lot should have opinions about the them. If they don't then they don't care (bad) or they haven't done the work (bad). Are they negative about everything? Are they flexible?

Motivation

For me this often is the clincher. Why did you get into engineering management in the first place? Why are you doing it now? I won't say what I consider to be good answers, since this varies a lot and should be pretty personal. Again, what you're looking for is a thoughtful answer.

This can be most useful for turning up red-flag responses. You don't want the person who did it for power ("I wanted to boss people around") or ambition ("I wanted to make more money") or just fell into it. Trust your gut for answers that don't sound genuine and ask probing follow-ups.

I find questions like these can lead to more insightful conversations and get the candidate off-script faster than the typical resume walkthrough.

Why Quit? Because They Have Bigger Monitors

Sef Kloninger — Thu, 17 May 2012 23:01:44 GMT

Good engineers are attracted to places with a strong engineering culture. But how can you see what the culture is really like from the outside? Here are my two quick-and-dirty indicators.

First a word about what I mean by an engineering culture. It means engineers are valued and important. Some implications:

How are decisions made? In an engineering culture, technical people have input into what gets built, when, and by whom. Not signoff, but a real say.
Is there respect for the craft of making software? Coding is still creative work that requires the right time and space. Some projets are tough to predict how long they will take, and that's needs to be OK.
Infrastructure. How hard is it for the people who know (engineers, managers) to justify to their bosses when work is needed on non-feature driven stuff? This could be in the runtime system (like scaling work on the message queue) or back office (like build systems or version control).

Unfortunately, teasing this out in an interview can be tricky unless you have someone you really know and trust on the inside.

How big are the monitors?

A story from a prior company. I was an engineering manager that had a retention problem. One of the engineers on my team quit to go to a smaller, hipper company. This was from my exit interview:

Me: why are you leaving?
Him: because they have bigger monitors.
Me: (incredulous) are you kidding? we can get you a bigger monitor.
Him: it's not just me -- everyone has big monitors.
Me: why is that so important?
Him: because it shows how much they value my time. The extra money to cram that many more pixels into my retina must be worth it to them.

And now I understand that this is totally true. Places that value their people consider equipment expenses small compared to the productivity (and happiness) of their people. The best engineers are given the best tools to do their jobs. Big monitors are a very visible sign of this.

Can people choose their own email addresses?

Non-engineers sometimes don't appreciate how important an email address is. It's your identity on line. A strict naming convention (first name last initial, or worse, last name first initial) indicates place that values conformity over engineer happiness. Worse, its a great way to make their people feel like cogs or "human resources," not the cool individuals that they are.

(Aside: let's do away with the term Human Resources. It's horrible.)

This one is important for me personally since I have a weird first name. If you don't let me be sef@company.com then you get major demerits in my book. And no, clunky alias tricks, like a mailing list with one member in it, doesn't count. It's what you see on your shell prompt that matters; it's what whoami returns that matters.

One final word: this isn't a slam on you hardworking IT guys and gals who keep important things running and have to enforce the rules you're given. Instead, I'm speaking to the bad policies (usually stemming from bad cultures) that can put you into bad positions. If you are at such a place, hunker down and pray for daylight.

"I Absorb Uncertainty"

Sef Kloninger — Thu, 03 May 2012 19:41:28 GMT

It was my first day at Akamai. They were still small enough that the all new employees had group lunch with the CEO, George Conrades.

For those who don't know him, George is flat out impressive. Partially that comes from being smart, thoughtful, and well spoken. But it also comes from being comfortable in big jobs. Prior to Akamai, George was CEO of BBN and GM of IBM United States, part of his thirty year career at IBM.

Someone asked George what he did as CEO, and George unpacked his stock answer. Something about products, people, and finances.

The new hire followed up: "No, George, what do you actually do?" It was a pointed question, and a bit smart-alecky. But it was also genuine, and George took it seriously. His answer stuck with me.

"I absorb uncertainty," George said.

He explained: If you get this many bright people together you're bound to have differences of opinion. Those can escalate into a real disagreement. Soon it gets heated and feelings and reputations are at stake. When this happens, the CEO's job is to hear and follow the discussion, know when forward progress isn't being made, and then make a decision. And then communicate that decision clearly so everyone can move on.

Making a decision absorbs uncertainty. Uncertainty disempowers your people and paralyzes your organization. A good CEO doesn't let that happen.

Now that's a good leader. Thanks, George.

PS - Googling around for this phrase, I see others might have used it too. One is Vittorio Cassoni, reported by Esther Dyson (video). But in my book, credit goes to GHC.