In this episode, we will be exploring interviewing as a Software Engineer. Tips, tricks, and gotchas, as well as potentially some interviewing horror stories and red flags to avoid at all costs. We’re joined by Emma Draper, Engineering Manager at the New York Times based in Arizona, and Kate Jonas, goes by Jonas, Technical Enablement Manager at Datadog based in Denver.
A lot of ink has been spilt over the years trying to elucidate the divide between junior and senior. Miłosz Piechocki makes the distinction this way:
Junior Engineers care about writing Software. They value code quality, employ best practices, try to adopt cutting-edge technologies. They invest a lot of time into learning new technologies. To them, the ultimate goal is to create elegant, performant, maintainable software.
Senior Engineers care about building Systems. To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.
He goes on to describe how hard it is to build Systems and lists activities that are part of that process.
Struggling through the tech job interview process? We feel you! On this episode, Amal, Nick & Amelia get together to discuss the various ways the interview process disappoints, share their own interview stories, and suggest ways we can improve the process for everyone.
Don’t stress, we all break production. These are the tips I wished I had. Not which framework to learn, or how to ace that programming interview (all useful!), but what to expect when you land your first software job.
This framework allows software engineering managers to have meaningful conversations with their direct reports around the expectations of each position and how to plan for the next level in their career ladder.
This year marks 15 years since FizzBuzz was popularised as an interview tool for developers. I’m a big fan and have watched over 100 candidates try their hand at my version of the task. In today’s blog post I’d like to take a moment to celebrate what makes FizzBuzz so helpful, discuss some common patterns I’ve observed in the many attempts I’ve witnessed, and finally explore some tweaks that can be deployed to keep the challenge fresh.
Tom’s version of FizzBuzz is a pair programming task that follows strict TDD:
In proper pair programming style, the candidate is encouraged to discuss their approach with the interviewer. Likewise, they are free to use any online reference materials if they forget a method name or some syntax.
In this post he shares 3 common variants of the challenge including one that requires a pair of Azure Functions?!
James Hawkins, after being on a team that’s interviewed over 725 people:
It’s normal for candidates not to ask harder questions about our company, so they usually miss out on a chance to (i) de-risk our company’s performance and (ii) to increase the chances they’ll like working here.
Does the company have product-market fit? How much runway does the company have? Does their spending look within reason? What’s the culture like? And more tough questions that you really should be asking before accepting that offer.
Wise words from Andy Brice:
When I was a child I assumed that all the adults running the world knew what they were doing. Now that I am an adult, I am under no such illusions…
I’m going to let you in on a little secret. Most of us who are running businesses had no real idea what they were doing when they started, and still struggle with decisions now.
I tell people this all the time when they ask me for advice. I’ll still give them my advice. But it comes with the disclaimer that I really have no idea what I’m doing. 😆
This week Lee Robinson joins us to talk about his journey as a DevRel. We talk about what it means to be a DevRel, what orgs they fall under, how he runs his team at Vercel, Lee’s three pillars of DevRel: education, community, and product, we compare the old days of DevRel vs now, and of course what makes a DevRel a good DevRel.
I love when software engineers share their career/life choices and the reasoning behind them so others can benefit from their perspective, like this one on bucket filling:
Somebody once described balance to me as three buckets filled with water. One for career, a second for physical health, and a third for social and family life. At any point, one bucket might be running low. But as long as the overall water level is high enough, things should be fine.
Scott’s choice to join a startup seems odd given his reason for leaving Google, but:
So: am I happier? Undoubtedly yes.
I work more hours. I’m more likely to be working in the evening or on the weekend now. But what I do makes a difference that I can see. Progress feels 10x faster.
Most surprising is that I have more energy. It’s easier to find motivation to get back in the gym. I have more energy in social situations.
Working more hours sounds like tipping the work/life balance in the wrong direction, but excitement about your work certainly changes the calculus. He’s happier now, so that’s great!
Some years back I applied to join IBM’s grad scheme, there was a peculiar stage to the process I’ve not seen elsewhere. It was during the onsite day, where a batch of 20 or so applicants were put through various tests in an IBM office. They called it the “group test”; around 8 of us were led to a room and asked to solve a puzzle together.
You can probably see where this story is headed… (see also)
Eric Jang was recently on the job market (finally landing at [Halodi Robotics])(https://halodi.com/) and in this post he shares his process and view of the job market today. He also has some insights on where it’s headed. In brief:
In the future, every successful tech company will use their data moats to build some variant of an Artificial General Intelligence.
When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice. Because of this, I have found that some methods work better than others to discover talent.
… instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:
The advantages in brief:
- Reading probes the most fundamental skills
- Reading code is way more efficient than writing.
- Reading puts candidates at ease compared to writing code.
Click through for the details and how to put this in to practice.
Well, that is the single largest expense we have. If we want to optimize anything in our discipline we should look at this part first. We talk often about how we build systems, but how often do you talk about how you spend the “figuring out” time? If we do not talk about it, it’s not explicit. If it’s not explicit, it does not get optimized.
In addition to the author’s suggested solution to this problem allow me to add: developer retention! Nobody has more to figure out in a system than the people who just joined the team. Cut down on that (via better compensation, workplace satisfaction, etc.) and you cut way down on that oh so expensive “figuring out” time.
For many software folk, we prefer our networking to have TCP handshakes, not literal (or even virtual) handshakes. If that’s you, this guide might help you get over the hump:
Here’s the truth: you can get what you need from these events without being awkward or creepy. Whether that’s job leads or important connections, there is a well-defined, time-tested way to accomplish this. It will push your limits, but it won’t leave you feeling gross inside. And the more you do it, the better you’ll get at it.
It is a good time to be in tech right now: soaring salaries, daily LinkedIn recruiter spam, people bootcamping their way into career switches to tech, remote work allowing you to work for a major tech company making triple digit salaries from the beach. It really feels like every single company is trying to recruit programmers nowadays, and doing whatever they can to get them.
I’m certainly happy with the current state of affairs, but I can’t help but wonder: How does it end?
Will supply go up via a mass influx of people switching careers? Will demand go down via AI and newly created no-code/low-code alternatives? Time will tell. But for now, some food for thought.
Dave Ceddia shares his go-to list of questions that he (literally) printed and brought with him to interviews for that final 5-ish minutes at the end when you get a chance to ask your own questions. It does come with a small disclaimer, though:
This was years ago by the way, long before COVID, when pretty much every interview was in-person. The shock factor of pulling out 2 pages of questions wouldn’t translate so well to Zoom, haha. But still: if time runs out, you can mention that you still have a bunch of questions, and could please email them afterward.
This week we’re joined by Jacob Kaplan-Moss and we’re talking about his extensive writing on work sample tests. These tests are an exercise, a simulation, or a small slice of real day-to-day work that candidates will perform as part of their job. Over the years, as an engineering leader, Jacob has become a practicing expert in effectively hiring engineers — today he shares a wealth of knowledge on the subject.
Relocation to a foreign country for work can be very exciting and lead to unique opportunities that couldn’t be accessed in your home country. At the same time, it’s a real challenge - I know it firsthand… Hopefully, this handbook will give you the necessary guidance. Topics covered include resume preparation, job search, salary negotiation, relocation packages, and more.
Ben Kuhn is a big fan of one-on-one meeting between managers and their direct reports to discuss whatever the report wants. So, he suggested his partner try them with him to improver her graduate program experience.
In the end, they succeeded far beyond my expectations: Eve thinks our one-on-ones sped up her dissertation by about a year.
Before making a move into product management, make the most of your technical career. The stories and experiences you gather as a developer will help you. But let’s say you’ve been in the software development field for a number of years, and you’re looking for your next challenge. Here’s a list of “You know you’re a PM if…” statements to help you decide if this career is right for you.
I’m a developer and I love to write code. I enjoy watching my brain come up with creative solutions for complex problems.
So, I often find myself with a blog post that’s ready to be submitted to Hacker News, or a tweet that’s ready to be sent, but postponing it.
Sound familiar? If so, read the story to learn how he got over it and started benefiting from his new-found confidence.
Jacob Kaplan-Moss, who has been writing a lot about good interview questions and how to hire well:
Work sample tests are an exercise, a simulation, a small slice of real day-to-day work that we ask candidates to perform. They’re practical, hands-on, and very close or even identical to actual tasks the person would perform if hired. They’re also small, constrained, and simplified enough to be fair to include in a job selection process.
To give you a more concrete idea of what I’m talking about, here are several examples of work sample tests I’ve used…
And just in case you think he’s prescribing whiteboarding…
However, work sample tests are also a minefield: the space is littered with silly practices like whiteboarding, FizzBuzz, Leetcode, and “reverse a linked list”-style bullshit. The point of this series is to separate these silly practices from the good ones and to give you a framework and several examples to use in your hiring rounds.
Cate Huston with another great career-related post. Click through for explainers of each these 5 signs and a bonus 6th (meta) sign:
- You’re not learning (and you want to be).
- You’re learning coping mechanisms rather than skills.
- You feel morally conflicted about hiring.
- Your job is affecting your confidence.
- Your job is affecting you physically.