Recruiters are busy. With thousands of engineers being laid off from Twitter, Amazon, and Meta, recruiters have boatloads of candidates to choose from. It’s normal for over 200 people to apply for each software development position. A recruiter has the tough task of getting through all the resumes and deciding the small set of people to call in for an interview.
The process looks like this: Before manually reviewing resumes, the recruiter feeds the big “stack” of resumes into a program that checks for keywords. For an iOS developer job, they might select keywords like Swift, Objective-C, software, programming, test, design, iOS, UIKit, performance, reliability, and SQL. Resumes with more keywords get pushed to the top, and resumes with few keywords are automatically rejected.
Then the recruiter does a quick pass through the huge stack. Here, the recruiter spends just 10 seconds looking at each resume to categorize them,
Let me repeat that: the recruiter only has 10 seconds to scan your resume.
Based on this scan, the recruiter puts your resume in the “yes”, “no”, or “maybe” pile. The people in the “yes” pile proceed to the next phase, either a deeper read, a phone screen, or maybe even an on-site whiteboard interview.
To stand out from the crowd, you need to make your resume easy to understand. Every word ought to have a purpose. The initial scan ought to give the reader a concise summary of your experience and skills and how they match the job description.
So if you’re looking for a job, do a quick scan through your resume or ask a friend to review it. What is the gist that they get? Is it accurate? And how would you improve it?
PS You may be thinking, “It’s really hard to make a memorable impression with a resume.” And I’d say, “You’re right.” If possible, meet some recruiters and managers at a career fair, or ask people in your personal network. You might be surprised at what opportunities are just around the corner.
If you want an engineer to act on a bug report, it needs to be easy to understand. Most importantly, the recipient needs to know how to reproduce the issue.
The worst bug reports look like this:
Weather query doesn't work
That’s it, no context. It’s impossible to understand what’s going on.
The best bug reports clearly state:
How reproduce the issue (“To Reproduce”)
The expected user experience (“Expected Behavior”)
What actually happened (“Actual Behavior”)
Take this fictional example about the Google Assistant and asking for the weather on the app’s main page (“chat UI”).
Title: Weather forecast ignores user location
1. Open the app
2. Sign in to your account (or already be signed in)
3. Ensure that "use location" setting is turned ON
4. Type "weather tomorrow" in the query box
5. Tap "Send"
Chat UI shows weather forecast at user's location
Chat UI shows weather forecast in Santa Cruz, CA *regardless of user location*
This report is easy to understand and as a high chance of being acted on by a developer. It has step by step instructions on how to reproduce the issue. Receiving a report like this won’t be seen as a complaint–rather, this is a legitimate bug that needs to be fixed.
Bonus points: To encourage reporters to provide structured information, create a default template for your bug reports.
Welcome to Mushroom Kingdom, Inc. Why don’t I introduce you to some of our software engineers?
Mario is a full stack developer. He has the talent of a rock star, but he’s humble. Everyone turns to him when the project runs into trouble, and Mario always saves the day. He has good relationships with his teammates, doesn’t slack off, follows all of the company’s best practices, and somehow still has good work life balance. His favorite programming language is Java.
Luigi sits next to Mario, his brother. He suffers from severe impostor syndrome despite being a solid developer. Luigi is always second in line when it comes to picking features, and he secretly resents Mario for hogging the spotlight. Luigi only writes tests because his TL told him to, not because he wants to write quality code.
Peach is the team’s manager. She had a great career as a software engineer and has since graduated to become a professional meeting attender. Every once in awhile, she gets to write some code and everyone agrees that it’s top-notch. Peach is a very empathetic leader and she always acts in the best interest of the team. Her one fatal flaw is that she often gets dragged into conflict with her rival, Bowser.
Bowser is a mean manager. He demands perfection, starting yesterday. He hides bugs and sets unreasonable expectations. If a test gets in the way of a new feature, Bowser deletes it without question. He has a backlog of 37 different design documents that will never be reviewed. He hates Peach and Mario–since they always do good work together, Bowser looks bad.
Wario is a maverick. No one is sure why he was hired. Everyone knows he arrives at the office late because he annoyingly revs his motorcycle in the parking lot. Wario regularly insults his teammates, misses deadlines, and delivers buggy code. He refuses to write comments. He claims his “my code is correct without a test” even when it’s demonstrably false. One time, he broke the office toilet and refused to admit it was his fault.
Waluigi is an interesting character. Everyone admits that he’s competent and important, but no one knows exactly what he works on these days. He’s a gregarious guy who likes to party, submits code at odd hours, and somehow hits every deadline that falls on a prime number. His favorite programming language is Haskell. Each of Waluigi’s features has exactly two bugs at any given time. Waluigi thinks that he’s Luigi’s biggest rival, but Luigi doesn’t seem to notice him. Strangely, Waluigi refuses to write unit tests, yet he single-handedly rewrote the company’s integration test framework last year, and will brag about it to anyone who asks.
Daisy is the tech lead of a forgotten internal infrastructure team. Her favorite programming language is Python. She quietly sits in the background and keeps the show running. Every year, she has to remind management why her team exists and they shouldn’t fire her. They look at the flashy numbers from Peach’s team and order Daisy to report the same metrics, even though it doesn’t make sense for an internal service. No one realizes that development would grind to a halt without Daisy and her team.
Mentoring other software engineers is one of my favorite parts of my job.
Every software engineer ought to have an unbiased mentor to go to for career questions. Early in your career, you’re always the one asking questions. As you gain experience, you’ll be called on by other engineers.
So what do you do? I’ve talked with a few software jedis and padawans in my years as a software developer. Here are three things that mentors must do to ensure their mentees are successful.
Talking to a mentee is not a time to show off your knowledge. Before you can help your mentee, you must listen to them.
I remember talking with a highly experienced software engineer. I sat down and he started writing down a detailed a career plan, and went on a long, random tangent about how “buying a house is the best investment” that involved the engineer begging the bank to not take his house away. All the while, I didn’t say a single word.
He never asked me what I wanted out of my career. Suffice to say, I did not go to him for career advice again.
If you want to be good mentor, you have to listen. You have to understand what the mentee is looking for. Sometimes they want advice. Sometimes they need help making a decision. Sometimes they know what they must do, and they just want to feel sure about their direction.
#2 Don’t directly tell the mentee the answer
Your first instinct might be to directly answer your mentee’s questions. Don’t immediately tell them an answer. The goal here is to lead the mentee to an answer by teaching them how to solve problems on their own.
One pitfall is that the first answer you think is often not the answer that solves their problem. Or even worse, the problem that the mentee thinks they have is not the problem they actually have.
Some time ago, a mentee (let’s call her Leia) came to me for productivity tips. Leia thought she was slacking off in the past month and needed to compensate. When I asked her more, she admitted she was afraid she wasn’t making enough progress at her new job. When we drilled deeper, I discovered Leia was making sufficient progress, but she felt she had nothing to show her manager yet. Therefore, Leia felt she wasn’t living up to her self-imposed, unreasonable expectations, and she felt she was a bad person. Once Leia said this out loud, she realized what was wrong.
At the start of our conversation, Leia didn’t realize that she didn’t need productivity tips. Talking through her thought process was what she needed to get to the answer–to see she was not a bad person, and she was already making good progress at her new job.
#3 Ask Questions
Usually, younger folks come to a more experienced engineer with a question. Sometimes, the questioner must become the questionee.
Asking good questions is interesting art. Each query should let the mentee answer in their own words and talk through their thought process, step by step. It’s a conversation, not an interrogation.
One time, a mentee (let’s call him Anakin) had a tricky situation with his manager. I had an idea about what I would do in that situation, but I wanted to ask for some more details first.
“What should I do?” Anakin asked.
“What have you tried so far?” I replied.
“Well… nothing,” Anakin whined. “I don’t know what to do.”
“What are some things you could try?” I asked.
Eventually, Anakin came up with a number of options for resolving the situation. He picked one and improved his relationship with his manager. I didn’t tell Anakin a single thing. As we met over the next 6 months, Anakin had fewer and fewer questions for me, and he didn’t have to wait for our next conversation to solve his career problems.
In other words, the best mentors teach you how to solve problems without consulting an mentor at all.
If you want to become a mentor, just wait. When the teacher is ready, the student appears.
Your name is Chad, and you are a brogrammer at Big Tech Co.
You start the day by slamming a protein shake. You throw on your usual uniform: a company t-shirt, shorts, sandals, and dark sunglasses. Your biceps bulge under your short sleeves.
Your Tesla pulls into the office outside San Jose at 11am. You hand your keys to the valet and head towards the nearest coffee bar.
As soon as you step inside, your co-worker, Jimmy, sees you.
“Oh, umm, excuse me, Chad,” says Jimmy without making eye contact. “If you could just approve–“
“My dude!” you say cheerfully. “I’m so sorry about your design doc. I’ve been working from Bali the last two weeks.”
“Umm, I didn’t realize that,” says Jimmy, meekly. “Sorry.”
“I’ll get to it as soon as possible,” you say, as you stand in line for a fair trade medium roast from Guatemala. Jimmy nods sheepishly and sips a tasteless latte from the automatic coffee machine down the hallway.
You take your cappuccino and casually stroll over to team standup. Everyone glares at you for being late. Your manager assigns you a difficult task for the week. You chuckle. He thinks it’s difficult, but you have an idea.
You get back to your desk and adjust it to the highest setting so everyone can see who’s the real boss. You code up the solution in an hour.
Jimmy taps you on the shoulder.
“Hey bro,” you smile. “What’s shaking?”
Jimmy takes a breath. “Uhh, can you review my design doc now?”
“Sure,” you say. Then you phone chimes. “Hold up. The cafes just opened for lunch. Want to head over to Charlotte’s? They’re serving filet mignon today.”
The two of you walk over to Charlotte’s Cafe, a 10 minute journey each way. You overhear two other engineers passionately debating an esoteric algorithm at the next table. You do not know anything about algorithms, nor do you need to.
“Oh right my dude!” You exclaim slowly. You pull up Jimmy’s design doc. Then your phone chimes.
“Right after this meeting,” you remark. Jimmy nods. He understands. You grab your laptop and head over to the meeting room.
It’s your weekly 1:1 with your manager. You have a routine check-in. Then you ask about performance reviews, and what your expecting rating is.
“I can’t guarantee anything,” your manager says. “but I think you could get the second-higest rating in the rubric.”
“Bro, I deserve the highest rating,” you assert. You open a doc of all your achievements that map specifically to Big Tech Co’s performance review rubric.
Your manager looks it over and nods. “Chad, you deserve the top rating. I’ll bring this to calibration.”
“Don’t mention it,” you grin. “By the way, I’m going to reduce latency by 10% next week.”
“I understand. I won’t give you any extra bugs next week. Our new director is really big on engineering excellence.”
“I know,” you say. Your phone chimes. “I gotta run.”
“Meeting with our intern?” your manager asks.
“Nope. The director,” you say, and stroll over to the next building.
The rest of your afternoon passes by in a blur.
Your solution to the difficult problem causes tests to fail, so you quietly disable the tests and submit the commit. The tests were flaky anyways. Your change goes out to 100 million users later that afternoon.
You read an e-mail from the product owner. They have a dumb feature request. You shoot it down. They understand.
You crack open a cold one. Someone from HR walks by but they know who you are.
You take a break to go to the gym. You do 100 squats, 100 bench presses, and 100 sit ups. Then you start your workout.
You review another commit. You push back on the author because you suspect it will increase compile time. The author actually agrees with you. They understand.
You send an e-mail to the team proposing to use a new dependency injection system. Everyone agrees. The migration begins immediately and will finish in three days.
Then you remember Jimmy’s design doc. You pull it up on your fourth monitor. Then, your phone chimes. Another meeting.
“Right after this,” you think to yourself.
It’s time to meet the new intern.
You find the intern at her desk. She’s a pretty, young blonde from Stanford. You’re her mentor. You take a pleasant walk outside together and tell her about Big Tech Co. You give the intern some of the tips that make you a successful brogrammer. She’s a good co-worker. You think of yourself as her big brother.
Your phone chimes again. This time, it’s an urgent, ominous sound.
“Elevated error rate in cell yj” the alert reads. Surprised, you cut your meeting short and rush back into the office.
Your manager is frantic. “Can you fix this?” he asks.
“Of course, bro,” you calmly wave him off. “Go do some sprint planning and I’ll tell you when it’s fixed.”
You open your computer. The red line on the dashboard is going up. Sweat rolls down your forehead. Your mind forms an idea about what to do, but you’re not entirely sure. Your fingers dance across the keyboard in a mad whirl. You built this system. You know it better than anyone. And yet, you wonder if you can actually fix it this time. This bug is different from anything you’ve ever seen before.
Finally, you find the root cause. You roll back your commit from earlier. The error rate swiftly returns to normal.
“Chad, you’re our hero!” everyone cheers. They uncork a bottle of champagne and serve cake meant for someone else’s birthday. You spend the last hour of work celebrating your big win. Even the director swings by to congratulate you, and she’s the most impressed of all.
At 3pm, your phone chimes.
“Sorry guys, I gotta go,” you say. Everyone gives you one last high five on your way back to the parking lot.
Jimmy catches up to you on your way out.
“Hey Chad, uhh, about my design doc…” he mumbles.
“Oh dude, sorry. I’ve had a hectic day. I’ll get to it tomorrow,” you reply.
Jimmy nods quickly, understandingly. The valet pulls up with your Tesla, whose battery has been fully charged.
“Chad?” Asks the valet. You nod. You get into your car.
“See ya next week,” you say to Jimmy.
“Next week?” Asks Jimmy incredulously.
“Yeah, my girlfriend and I are going to Costa Rica. I’ll be reachable by e-mail.”