Skip to content

Stop Trying To Schedule A Call With Me

Stop Trying To Schedule A Call With Me

One of the biggest hurdles for me when trying out a new service or product is the inevitable harassment that follows. It always starts innocuously:

“Hey, I saw you were checking out our service. Let me know if you have any questions!”

Fine, whatever. You have documentation, so I’m not going to email you, but I understand that we’re all just doing our jobs.

Then, it escalates.

“Hi, I’m your customer success fun-gineer! Just checking in to make sure you’re having the best possible experience with your trial!”

Chances are, I signed up to see if your tool can do one specific thing. If it doesn’t, I’ve already mentally moved on and forgotten about it. So, when you email me, I’m either actively evaluating whether to buy your product, or I have no idea why you’re reaching out.

And now, I’m stuck on your mailing list forever. I get notifications about all your new releases and launches, which forces me to make a choice every time:

“Obviously, I don’t care about this anymore.”

“But what if they’ve finally added the feature I wanted?”

Since your mailing list is apparently the only place on Earth to find out if Platform A has added Feature X (because putting release notes somewhere accessible is apparently too hard), I have to weigh unsubscribing every time I see one of your marketing emails.

And that’s not even the worst-case scenario. The absolute worst case is when, god forbid, I can actually use your service, but now I’m roped into setting up a “series of calls.”

You can't just let me input a credit card number into a web site. Now I need to form a bunch of interpersonal relationships with strangers over Microsoft Teams.

Let's Jump On A Call

Every SaaS sales team has this classic duo.

First, there’s the salesperson. They’re friendly enough but only half paying attention. Their main focus is inputting data into the CRM. Whether they’re selling plastic wrap or missiles, their approach wouldn’t change much. Their job is to keep us moving steadily toward The Sale.

Then, there’s their counterpart: the “sales engineer,” “customer success engineer,” or whatever bastardized title with the word engineer they’ve decided on this week. This person is one of the few people at the company who has actually read all the documentation. They’re brought in to explain—always with an air of exhaustion—how this is really my new “everything platform.”

“Our platform does everything you could possibly want. We are very secure—maybe too secure. Our engineers are the best in the world. Every release is tested through a 300-point inspection process designed by our CTO, who interned at Google once, so we strongly imply they held a leadership position there.”

I will then endure a series of demos showcasing functionality I’ll never use because I’m only here for one or two specific features. You know this, but the rigid demo template doesn’t allow for flexibility, so we have to slog through the whole thing.

To placate me, the salesperson will inevitably say something like,

“Mat is pretty technical—he probably already knows this.”

As if this mild flattery will somehow make me believe that a lowly nerd like me and a superstar salesperson like you could ever be friends. Instead, my empathy will shift to the sales engineer, whose demo will, without fail, break at the worst possible time. Their look of pure despair will resonate with me deeply.

“Uh, I promise this normally works.”

There, there. I know. It’s all held together with tape and string.

At some point, I’ll ask about compliance and security, prompting you to send over a pile of meaningless certifications. These documents don’t actually prove you did the things outlined in them; they just demonstrate that you could plausibly fake having done them.

We both know this. If I got you drunk, you’d probably tell me horror stories about engineers fixing databases by copying them to their laptops, or how user roles don’t really work and everyone is secretly an admin.

But this is still the dating phase of our relationship, so we’re pretending to be on our best behavior.

“Very impressive SOC-2.”

via GIPHY

Getting Someone To Pay You

We’ve gone through the demos. You’ve tried to bond with me, forming a “team” that will supposedly work together against the people who actually matter and make decisions at my company. Now you want to bring my boss’s boss into the call to pitch them directly.

via GIPHY

Here’s the problem: that person would rather be set on fire than sit through 12 of these pitches a week from various companies. So, naturally, it becomes my job to “put together the proposal.”

This is where things start to fall apart. The salesperson grows increasingly irritated because they could close the deal if they didn’t have to talk to me and could just pitch directly to leadership. Meanwhile, the sales engineer—who, for some reason, is still forced to attend these calls—stares into the middle distance like an orphan in a war zone.

“Look, can we just loop in the leadership on your side and wrap this up?” the salesperson asks, visibly annoyed.

“They pay me so they don’t have to talk to you,” I’ll respond, a line you first thought was a joke but have since realized was an honest admission you refused to hear early in our relationship.

If I really, really care about your product, I’ll contact the 300 people I need on my side to get it approved. This process will take at least a month. Why? Who knows—it just always does. If I work for a Fortune 500 company, it’ll take a minimum of three months, assuming everything goes perfectly.

By this point, I hate myself for ever clicking that cursed link and discovering your product existed. What was supposed to save me time has now turned into a massive project. I start to wonder if I should’ve just reverse-engineered your tool myself.

Eventually, it’s approved. Money is exchanged, and the salesperson disappears forever. Now, I’m handed off to Customer Service—aka a large language model (LLM).

The Honeymoon Is Over

It doesn’t take long to realize that your “limitless, cloud-based platform designed by the best in the business” is, in fact, quite limited. One day, everything works fine. The next, I unknowingly exceed some threshold, and the whole thing collapses in on itself.

I’ll turn to your documentation, which has been meticulously curated to highlight your strengths—because god forbid potential customers see any warnings. Finding no answers, I’ll engage Customer Service. After wasting precious moments of my life with an LLM that links me to the same useless documentation, I’ll finally be allowed to email a real person.

The SLA on that support email will be absurdly long—72 business hours—because I didn’t opt for the Super Enterprise Plan™. Eventually, I’ll get a response explaining that I’ve hit some invisible limit and need to restructure my workflows to avoid it.

As I continue using your product, I’ll develop a growing list of undocumented failure modes:

“If you click those two buttons too quickly, the iFrame throws an error.”

I’ll actually say this to another human being, as if we’re in some cyberpunk dystopia where flying cars randomly explode in the background because they were built by idiots. Despite your stack presumably logging these errors, no one will ever reach out to explain them or help me fix anything.

Account Reps

Then, out of the blue, I’ll hear from my new account rep. They’ll want a call to “discuss how I’m using the product” and “see how they can help.” Don’t be fooled—this isn’t an attempt to gather feedback or fix what’s broken. It’s just another sales pitch.

After listening to my litany of issues and promising to “look into them,” the real purpose of the call emerges: convincing me to buy more features. These “new features” are things that cost you almost nothing but make a huge difference to me—like SSO or API access. Now I’m forced to decide whether to double down on your product or rip it out entirely and move on with my life.

Since it’s not my money, I’ll probably agree to give you more just to get basic functionality that should’ve been included in the first place.

Fond Farewell

Eventually, one of those open-source programmers—the kind who gleefully release free tools and then deal with endless complaints for life—will create something that does what your product does. It’ll have a ridiculous name like CodeSquish, Dojo, or GitCharm.

I’ll hear about it from a peer. When I mention I use your product, they’ll turn to me, eyes wide, and say, “Why don’t you just use CodeSquish?”

Not wanting to admit ignorance, I’ll make up a reason on the spot. Later, in the bathroom, I’ll Google CodeSquish and discover it does everything I need, costs nothing, and is 100x more performant—even though it’s maintained by a single recluse who only emerges from their Vermont farm to push code to their self-hosted git repo.

We’ll try it out. Despite the fact that its only “forum” is a Discord server, it’ll still be miles ahead of your commercial product.

Then comes the breakup. I’ll put it off for as long as possible because we probably signed a contract. Eventually, I’ll tell Finance not to renew it. Suddenly, I’ll get a flurry of attention from your team. You’ll pitch me on why the open-source tool is actually inferior (which we both know isn’t true).

I’ll tell you, “We’ll discuss it on our side.” We won’t. The only people who cared about your product were me and six others. Finally, like the coward I am, I’ll break up with you over email—and then block your domain.


Career Advice for New Tech Workers in 2025

Giving advice is always tricky—especially now, in a world where everything seems to change every week. Recently, I had the chance to chat with some folks who’ve either just graduated or are about to graduate and are looking for jobs in tech. It was an informal, unstructured conversation, which, frankly, was refreshing.

A lot of the exchange surprised me in good ways. But one thing stood out: how little they actually knew about working for a tech company.

Most of what they knew came from one of three places:

1. Corporate blog posts gushing about how amazing life is for employees.

2. LinkedIn (because those who don't work post on LinkedIn about work).

3. Random anecdotes from people they’d bumped into after graduating and starting their first job.

Spoiler alert: Much of this information is either lies, corporate fantasy, or both.

If history is written by the victors, then the narrative about life inside tech companies is written (or at least approved) by the marketing department. It’s polished, rehearsed, and utterly useless for preparing you for the reality of it all. That’s what I’m here to do: share a bit of that reality.

I’ve been fortunate enough to work at both Fortune 500 companies and scrappy startups with 50 people, across the US and Europe. I’m not claiming to know everything (far from it). In fact, I’d strongly encourage others to chime in and add their own insights. The more voices, the better.

That said, I think I’ve been around long enough to offer a perspective worth sharing.

One last thing: this advice is engineering-specific. I haven’t worked in other roles, so while some of this might apply to other fields, don’t hold me accountable if it doesn’t. Consider yourself warned.

Where Should I Apply?

A lot of newcomers gravitate toward companies they’ve heard of—and honestly, that’s not the approach I’d recommend. The bigger and fancier a tech company is, the less their tech stack resembles anything you’ll ever see anywhere else.

Take it from someone who’s watched ex-Googlers and former Facebook folks struggle to understand GitHub: starting at the top isn’t always the blessing it sounds like. (Seriously, just because you worked on a world-class distributed system doesn’t mean you know how to use Postgres.)

Finding your “sweet spot” takes time. For me, it’s companies with 200 to 1,000 employees. That size means they’re big enough to have actual resources but not so bloated with internal politics that all your time is spent in meetings about meetings. Bonus: you might even get to ship something users will see!

Here’s a pro tip: Don’t assume name recognition = better place to work. Plenty of people at Apple hate their jobs. Sometimes, smaller companies will give you way better experience and way fewer existential crises.

And remember: your first job isn’t your forever job. The goal here is just to get something solid on your resume and learn the ropes. That’s it.

Interview

Congratulations! You’ve slogged through a million online applications and finally landed your first interview. Exciting, right? Before you dive in, here are some tips for navigating this bizarre ritual, especially if you’ve never done it before.

  • Interviews ≠ The Job
    • Let’s get this straight: interviews have almost nothing to do with the job you’ll actually be doing. They’re really just opportunities for engineers to ask whatever random questions they think are good “signals.”
    • Someone once said that technical interviews are like “showing you can drive a race car so you can get a job driving a garbage truck.” They weren’t wrong.
  • Protect Your Time
    • Here’s the deal: some companies will waste your time. A lot of it.
    • I’ve been through this circus—take-home tests, calls with unrelated questions, and in-person interviews where no one has even glanced at my earlier work. It’s maddening.
    • Take-Home Assignments: Fine, but they should replace some in-person tests, not stack on top of them.
    • In-Person Interviews: If they insist on multiple rounds, the interviewers better be sharing notes. If not, walk away.
    • Remember: the average interview doesn’t lead to a job. Don’t ditch other opportunities because you’re on round three with a “Big Company.” You’re not as close to an offer as you might think.
  • Watch for the Sunk-Cost Fallacy
    • If you find yourself doing two take-homes, six interviews, and a whiteboard session, ask yourself: Is this really worth it?
    • I’ve ended interview processes midstream when I realized they were wasting my time—and I’ve never regretted it. On the flip side, every time I’ve stuck it out for those marathon processes, the resulting job was…meh. Not worth it.
  • Ask the Hard Questions
    • This is your chance to interview them. Don’t hold back:
      • On-Call Work: Ask to see recent pages. Are they fixing real problems, or are you signing up for a never-ending nightmare?
      • Testing: What’s their test coverage like? Are the tests actually useful, or are they just there to pass “sometimes”?
      • Turnover: What’s the average tenure? If everyone’s left within 18 months, that’s a big, waving red flag.
  •  Embrace the Leetcode Circus
    • I know, I know—Leetcode is frustrating and ridiculous, but there’s no way around it. Companies love to make you grind through live coding problems. Just prepare for it, get through it, and move on.
  • Failure Is Normal
    • Failing an interview means absolutely nothing. It stings, sure, especially after investing so much time. But rejection is just part of the process. Don’t dwell on it.

Common Questions

  • Why are interviews so stupid if they're also really expensive to do?
    • Because interview time is treated like “free time.” Your time, their time—it’s all apparently worthless. Why? Probably something they heard in a TED talk.
  • Should I contribute to an open-source project to improve my resume?
    • No. Companies that rely on open-source rarely contribute themselves, so why should you? Unless you want to be an unpaid idealist, skip it.
  •  I’ve always dreamed of working at [Insert Company]. Should I show my enthusiasm?
    • Absolutely not. Recruiters can smell enthusiasm, and it works against you. For some reason, acting mildly disinterested is the best way to convince a company you’re a great fit. Don’t ask me why—it just works.

Getting Started

One of the biggest mistakes newcomers make in tech is believing that technical decisions are what truly matter. Spoiler: they’re not.

Projects don’t succeed or fail because of technical issues, and teams don’t thrive or collapse based on coding prowess alone. The reality is this: human relationships are the most critical factor in determining your success. Everything else is just noise that can (usually) be worked around or fixed.

Your Manager Is Key

When starting out, the most important relationship you’ll have is with your manager. Unfortunately, management in tech is…well, often terrible.

Most managers fall into two categories:

1. The Engineer Turned Manager: An engineer who got told, “Congrats, you’re a manager now!” without any training.

2. The People Manager™: Someone who claims to be an “expert” at managing people but doesn’t understand (or care about) how software development actually works.

Both types can be problematic, but the former engineer is usually the lesser evil. Great managers do exist, but they’re rare. Teams with good managers tend to have low turnover, so odds are, as a junior, you’re more likely to get stuck with a bad one.

The way you know you have a good manager is they understand the role is one of service. It's not about extracting from you, it's about enabling you to do the thing you know how to do. They do the following stuff:

  • They don't shy away from hard tasks
  • They understand the tasks their team is working on and can effortlessly answer questions about them
  • Without thinking about it you would say they add value to most interactions they are in
  • They have a sense of humor. It's not all grim productivity.

Let’s meet the cast of bad managers you might encounter—and how to survive them.

1800s Factory Tycoon

This manager runs their team like an industrial assembly line and sees engineers as interchangeable cogs. Their dream? Climbing the corporate ladder as quickly as possible.

Signs You Work for a Tycoon

  • Obsession with “Keeping Things Moving”: Complaints or objections? Clearly, someone’s trying to sabotage the conveyor belt.
  • “Everyone Is Replaceable”: They dismiss concepts like institutional knowledge or individual skill levels. An engineer is just someone who “writes code at a computer.”
  • No Onboarding: “Here’s the codebase. It’s self-documenting.” Then they wander off.
  • Fear of Change: Nothing new gets approved unless it meets impossible criteria:
    • Zero disruption to current work.
    • Requires no training.
    • Produces a shiny metric showing immediate improvement.
    • No one else needs to do anything differently.
  • I Am The Star. They're the face of every success and the final word in every debate. You exist to implement their dream and when the dream doesn't match what they imagined it's because you suck.

Tips for Dealing With The Tycoon

  • Stay out of their way.
  • Expect zero career support—build your own network and contacts.
  • Be patient. Tycoons often self-destruct when their lack of results catches up to them. A new manager will eventually step in.

Sad Engineer

This person was a good engineer who got promoted into management…without any guidance. They mean well but often struggle with the non-technical aspects of leadership.

Can’t Stay Out of the Code: They take on coding tasks, but no one on the team feels comfortable critiquing their PRs.

Poor Communication: They’ll multitask during meetings, avoid eye contact, or act distracted—leaving their team feeling undervalued.

Technical Debates > Team Conflicts: Great at discussing system architecture, useless at resolving interpersonal issues.

No Work/Life Balance: They’re often workaholics, unintentionally setting a toxic example for their team.

Tips For Dealing with the SE

  • Be direct. Subtle hints about what you need or dislike will go over their head.
  • Use their technical expertise to your advantage—they love helping with code.
  • Don’t get attached. SEs rarely stick with management roles for long.

Jira as a Religion (JaaR)

The JaaR manager believes in the divine power of process. They dream of turning the chaos of software development into a predictable, assembly-line-like utopia. Spoiler: it never works.

Obsessed with Estimates: They treat software delivery like Amazon package tracking, demanding updates down to the minute.

Can’t Say No: They agree to every request from other teams, leaving their own team drowning in extra work.

The Calendar Always Wins: Quality doesn’t matter; deadlines are sacred. If you ship a mess, that’s fine—as long as it’s on time.

Meetings. Endless Meetings.: Every decision requires a meeting, a slide deck, and 20 attendees. Progress crawls.

Tips for Surviving the JaaR

Find the Real Decision-Makers: JaaRs defer to others. Identify who actually calls the shots and work with them directly.

Play Their Game: Turn everything into a ticket. They love tickets. Detailed ones make them feel productive, even if nothing gets done.

Your Team

The Core Reality of Technical Work

Technical work is often driven by passion. Many engineers enjoy solving problems and building things, even in their free time. However, one universal truth often emerges: organizational busywork expands to fill the available working day. No matter how skilled or motivated your team is, you will face an inevitable struggle against the growing tide of meetings, updates, and bureaucracy.

Every action you and your teammates do is designed to try and delay this harsh reality for as long as possible. Nobody escapes it, eventually you will be crushed by endless amounts of status updates, tickets, syncs and Slack channels. You'll know it's happened when you are commuting home and can't remember anything you actually did that week.

Teams will often pitch one of the following in an attempt to escape the looming black hole of busywork. Don't let yourself get associated with one of these ideas that almost never works out.

Common Losing Concepts in Team Discussions

  1. “If we adopt X, all our problems go away.”
    Tools and technologies can solve some problems but always introduce new challenges. Stay cautious when someone pitches a “silver bullet” solution.
  2. “We’re being left behind!”
    Tech loves fads and you don't have to participate in every one. Don't stress about "well if I don't work with Y technology then nobody will ever hire me". It's not true. Productivity in software development doesn't grow by leaps and bounds year over year regardless of how "fast" you adopt new junk
  3. “We need to tackle the backlog.” Backlogs often consist of:
    1. Important but complex tasks requiring effort and time.
    2. Low-value tasks that remain because no one has questioned their necessity.

If a thing brings a lot of value to users and isn't terribly painful to write, developers will almost always snap it up for the dopamine rush of making it. This means addressing a backlog without critically evaluating its contents is a waste of resources.

4. “We need detailed conventions for everything.”

While consistency is good, overengineering processes can be counterproductive. Practical examples and lightweight guidelines often work better than rigid rules.

5. “Let’s rewrite everything in [new language].”

Rewrites are rarely worth the cost. Evolutionary changes and refactoring are almost always more effective than starting over.

Team Dynamics

The Golden Rule

People can either be nice or good at their jobs, both are equally valuable.

Teams need balance. While “10x engineers” may excel at writing code, they often disrupt team dynamics by overengineering or pursuing unnecessary rewrites. A harmonious team with diverse strengths typically achieves more than one overloaded with “superstars.”

Tips for Thriving on a Team

1. Quietly Grind on the Problem

As a junior developer, expect to spend a lot of time simply reading code and figuring things out. While asking for help is encouraged, much of your growth comes from independently wrestling with problems.

  • Start with small, low-risk changes to learn the codebase and deployment process.
  • Accept that understanding a system takes time, and no explanation can replace hands-on exploration.

2. Understand How Your Team Communicates

Some teams use Slack for everything; others rely on email or tools like GitHub. Learn the preferred methods of communication and actively participate.

3. Create a “How We Make Money” Diagram

Understanding your company’s business model helps you prioritize your work effectively. Map out how the company generates revenue and identify critical systems.

• Focus on less-sensitive parts of the system for experimentation or learning.

• Warn teammates when working on the “make money” areas to avoid unnecessary risks.

4. Plan Before Coding

The more complex a problem, the more time you should spend planning. Collaboration and context are key to successful implementation.

• Discuss proposed changes thoroughly.

• Understand the historical context behind existing decisions.

Assume most of the decisions you are looking at were made by a person as smart or smarter than you and work from there has been a good mental framework when joining a team for me.

Take Care Of Yourself

Tech work can be unpredictable—projects get canceled, layoffs happen, or sometimes a lucky break might land you a new opportunity. Regardless, this is your career, and it’s essential to make sure you’re learning and advancing at each job, because you never know when you might need to move on.

  • All Offices Suck
    • Open-office layouts are a disaster for anyone who values focus, especially for new employees. You’re constantly bombarded by conversations and interruptions, often with no warning. The office environment may look sleek and modern, but it’s rarely conducive to concentration or productivity.
    • If you need to drown out the sound of people talking or noise with headphones, your leadership cares more about how an office looks to a visitor than how it functions. Try to find a quiet spot where you can sit and work on your tasks.
  • Monitor Turnover
    High employee turnover can be one of the most damaging issues for a team. Not only does it drain time and resources through offboarding, interviewing, and training, but it also kills morale and focus.
    • Turnover, through voluntary leavings or layoffs, is one of the most destructive things to your team dynamics and overall morale. Turnover by itself costs about 20% of all the hours invested by a team (offboarding, interviewing, bringing someone new on), but there's a more sinister angle.
      • Teams with high turnover don't care about the future. You'll often get trapped in a death spiral of watching a looming problem grow and grow but unable to get anybody invested because they're already planning their exit.
      • Now high-turnover teams also promote really quickly, so this could be a good opportunity to get some more senior titles on your resume. But be warned that these teams are incredibly chaotic and often are shut down with little warning by upper management.
      • High turnover also says management is shitty at cost-benefit analysis. It takes forever to onboard engineers, especially in niche or high-complexity sectors.
    • Try to find out why people are leaving.
      • Is this "just a job" to them? Fine, let it be that way to you.
      • Do they feel disposable or ignored? That suggests more serious management issues that go up the chain.
      • "Loyalty is for idiots". People naturally want to be loyal to organizations and teams, so if the sentiment is "only a sucker would be loyal to this place", understand you don't likely have a long career here.
  • Corporate Goals Don't Matter
    • A lot of companies assume that whatever their stated high-level goals are somehow matter to you at the bottom. They don't and it's a little crazy to think they would.
    • Managers align more strongly with these high-level goals because that is the goal of their team. They don't matter to you because that's not what drives your happiness. Doing work that feels fulfilling, interesting and positive matters. Seeing the profit numbers go up doesn't do anything for you.
  • Programming Is Lonely
    • It can be hard for people to transition from university to a silent tech office where people rarely speak outside of meetings.
    • Try to make friends across departments. I personally always loved hanging out during breaks with the sales folks, mostly because their entire lives are social contact (and they're often naturally funny people). It's important to escape your group from time to time.

Desired End State

Our goal with all of this is to get ourselves onto a good team. You'll know you are on a good team when you spend most of your time just clearing the highway of problems, such is your pace of progress. People are legitimately happy, even if the subject matter is boring. Some of my favorite teams in my career worked on mind-numbingly mundane things but we just had a great time doing it.

Once you find one of these, my advice is to ride it out for as long as possible. They don't last forever, management will come in and destroy it if given enough time. But these are the groups where you will do the most learning and develop the most valuable connections. These are the people who you will hire (or will hire you) five or ten years after you stop working together. That's how incredible the bond of a high-functioning group is and that's what you need to find.

But it takes awhile. Until you do, you just need to keep experimenting. Don't stay at a job you don't like for more than 2-3 years. Instead take those learnings and move on to the next chance.

Ultimately, your career is about learning, growing, and being part of a team that values you. The road can be long, and it’s okay to experiment with different roles and environments until you find the right fit. Stay focused on what matters to you, take care of yourself, and don’t be afraid to move on if the job isn’t fulfilling your needs.