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.
freakingrectangle.wordpress.com
Sounds like Jacob Kaplan-Moss isn’t the only hiring manager who’s keen on the reverse code review:
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:
Click through for the details and how to put this in to practice.
So what?
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.
Douglas Vaghetti:
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.
Andrew Stetsenko:
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.
Rauno Metsa:
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:
Liana Leahy tells Amal and KBall all about her journey from software engineer to product manager. Along the way we learn what a PM does, how to be great at it, how to know if it’s for you, why the role is in such demand these days, and much more. - It’s UNIX, I know this!
Avdi Grimm kicks off a new series of posts (that I’m quite excited about) on the various parts that go into a “banana stand” business by deftly wielding a classic Arrested Development gag and telling the tale of how he got his stand started:
I’m a software developer by trade. I’ve slung code either as an employee or as an independent consultant for over two decades. But around ten years ago, I started selling e-books about programming. At the time it was a way to recoup the time and energy I had sunk into researching conference talks, as well as a way to expand on the topics of those talks.
E-books expanded to screencasts, and then to courses. I found myself with a diversified product income that sometimes rivaled or even exceeded what I could expect from a developer’s salary.
As a result, gaps between gigs haven’t felt like “unemployment” for a long time. Instead, they are opportunities to work on my education business. Recently, a major gig I’d been looking forward to fell through at the last second. Once I worked through the disappointment, I was like: “welp, there’s always money in the banana stand!”
The first component of your banana stand: a mailing list
Ashley Willis and Ela Krief join Natalie to discuss the ins and outs of management. They discuss what makes a good manager, common mistakes managers make, how to communicate effectively, dealing with conflict, and much more.
With the constant demands of work and life we often don’t take much time to ensure that we’re maintaining ourselves. In this third episode of the maintenance series, Kris is joined by co-host Natalie, along with Ian Lopshire to discuss the ways in which we can maintain ourselves in this busy and chaotic world.
The business context for a rent versus buy dichotomy was first introduced to me by Adam a few years back. It has since then proven very useful as a tool for thinking about the relationship people have to their jobs/companies.
In this post, Cate Huston does an excellent job laying it all out, including which things are generally rented, and which things are generally bought.
Thinking about career decisions this way, you can consider different tradeoffs and options that work best for you at any given time… My question is: are you making those choices mindfully? And do they work for the life and career you want?
This week we’re joined by Gergely Orosz and we’re talking about the insane tech hiring market we’re in right now. Gergely was on the show a year ago talking about growing as a software engineer and his book The Tech Resume Inside Out. Now he’s laser focused on Substack with actionable advice for engineering managers and engineers, with a focus on big tech and high-growth startups. On today’s show we dig into his recent coverage of “the perfect storm” that’s causing this insane tech hiring market.
Wise words from Rach Smith:
What I’ve learnt through experience is that the number of languages I’ve learned or the specific frameworks I’ve gained experience with matters very little. What actually matters is my ability to up-skill quickly and effectively. My success so far has nothing to do with the fact I know React instead of Vue, or have experience with AWS and not Azure. What has contributed to my success is the willingness to learn new tools as the need arises.
I’ve often wondered this as well. My conclusion, after not thinking too deeply about the issue, was that it’s a combination of the difficulty in match making and poor tooling. (There are many startups trying to solve those problems, but it doesn’t seem like anybody has cracked the nut yet).
There’s lots of wisdom in this post by Curt Corginia:
A wise, mature person would treat the software engineer interview process as a pure learning experience. He, or she, would enjoy learning about companies out there for the sake of research, interacting with key players, and mastering the art of whiteboarding. It would just be like a fun game.
I don’t think of it like that, but a mature person would. Do what I say, not what I do.
Ivan Velichko:
I compiled this thread on Twitter, and all of a sudden, it got quite some attention. So here, I’ll try to elaborate on the topic a bit more. Maybe it would be helpful for someone trying to make a career decision or just improve general understanding of the most hyped titles in the industry.
Titles come and go, and it’s worth knowing which ones are coming and which ones are going. This article is a good place to catch up if you haven’t been tracking. Oh, and there’s a pod for that too. 😉
Alex Koutmos:
If you follow my blog, you have probably noticed that my articles usually revolve around some deep technical problems and how to go about solving these problems using the amazing Elixir programming language. These posts usually discuss the technical merits surrounding Elixir and the Erlang virtual machine, but rarely touch on the “human” aspects of Elixir.
The goal of today’s post will be to address some of the non-technical aspects of the Elixir programming language and talk about the profound impact they can have on your engineers and your business. I’ll start off by addressing one of the most common concerns I come across when it comes to Elixir - that being that “It is hard to find Elixir developers”.
An excellent goal for a blog post. I’d love to see more like this for each and every sub-community in the software world.
Miguel Carranza from RevenueCat lays out why he and his co-founder decided to provide equal compensation for the same role regardless of location. Here’s the bullet points of their reasoning:
Read his post for the details along with some downsides of this approach.
