Preparing for a recruiting event

This is a guest post from Jeff Beard, lightly edited. Enjoy.

Dear New Developer,

Preparing for a university job fair or similar recruiting event is very important if you want to make an impression that results in a phone screen.

A hiring manager and their recruiters receive an enormous number of contacts and resumes from a variety of channels so you have to be able to stand out from the crowd in a very short amount of time, often measured in seconds.

However, when you are at a recruiting event you have a unique opportunity to make an impression since you will get to talk directly to a recruiter or even a hiring manager. So you need to be fully prepared to exploit that short window of opportunity.

Here are a few important things to prepare in order to make the most of that moment:

  • Resume
  • The Introduction
  • The Conversation
  • Appearance

Resume

A resume is something of a pitch deck that you use to get attention and tell your story. It’s also a notepad and reminder for a recruiter or hiring manager to go back to in order to find you in the huge pile of resumes they collect. Or, sadly, to figure out what goes into the recycle bin now versus later (it’s no joke: a desk covered with hundreds of resumes requires triage.)

To begin with, make sure that you have complete basic information such as address, phone, email, GPA, and graduation date (for students) at the top of your resume.

There are a few important attributes that a hiring manager is looking for and that you want to show with your resume:

  • Motivated
  • Passionate
  • Skilled
  • Adaptable
  • Collaborative
  • Articulate

Since you are early in your career you won’t have as much work experience so you should make projects the centerpiece of your resume. In fact, even later in your career, a highly informative discussion can be had around projects that reveal the attributes noted above. For any project on your resume you should be able to speak to:

  • The purpose of the project
  • Why it was important
  • Did you work on a team
  • How did the team self-organize
  • How you overcame challenges
  • What was the outcome
  • Why you liked the project

Importantly, what a good hiring manager is looking for is intrinsic motivation. We want folks that are naturally excited about the domain they are looking to enter for their career.

So put your favorite project at the top of the list and drive the conversation to that project if you can. The person you are talking to needs to see what lights you up and there is native passion for your favorite project that you need to let shine through.The project description should be brief and to the point, with a focus on the “what”, “why”, and the outcome. A project description doesn’t need to be burdened with the tech used unless it adds to the overall narrative.

Projects don’t have to be school class projects or work experience. They can be side hustles, Open Source, personal interest, or Hackathon projects.

If you haven’t done a lot of projects, take the initiative to find a couple of projects to work on. If you are in school or in your first job and it’s not producing projects that engage you, seek them out or invent them yourself. This will be reflected in your resume and will send a signal that you are curious, passionate about the domain, and look beyond what you are doing day to day for interesting problems to solve.

One final bit of advice on resumes, is that you can have more than one resume for different audiences. For example if you are equally interested in DevOps and software development, craft two different resumes that highlight projects and work experience in each category. You can also optimize resumes for different industries to highlight aspects of your experience or interests that cast you in a good light for that market.

The Introduction

The introduction is a critical face to face interaction that is your opportunity to form a connection with a potential hiring manager or recruiter. There is an incredibly short window of opportunity to impress the person which means you need to say a few impactful words, delivered with confidence.

When you approach the company representative, reach out to shake hands while you say hello and start your introduction. People receive signals from a handshake so don’t go soft and don’t be aggressive. Just a firm, confident handshake will do the trick. Practice with friends.

I personally will listen for about a minute before I interrupt and direct the conversation to, say, the resume in a candidate’s hand but it’s important to have a story that is concise, to the point, and well rehearsed.

The introduction should contain your name, your college program and graduation date (if appropriate), what you are passionate about, what role you are looking for, what your interest is in the company, and why you would be successful. It’s a brief statement of intent and a value proposition signal. You should practice saying it out loud often enough that you can deliver it with a practiced confidence, energy and restrained enthusiasm while looking the person straight in the eye.

Don’t make assumptions about the person you are talking to; ask them what their role is at the company. If they are technical, this is an opportunity to signal your depth. If they are not, you can tailor the conversation accordingly.

Also don’t launch into a description of every item on your resume; exercise restraint and stay focused on a concise introduction that will lead into a conversation.

Finally, like resumes, you can have more than one introduction crafted for different audiences.

The Conversation

Your introduction will lead into a very short, general conversation which you also need to be prepared for. If the introduction is the hook, then this conversation is closing the deal on a phone screen. (Note you are not closing the deal on a job or an interview, that’s later. You just want a second look which is what the phone screen is.)

You get it by handing the recruiter or hiring manager your resume to scan and ask their questions. Have a ready answer for everything on your resume including any questions about whether or not things went bad on a project or an obviously short tenure at one of your jobs.

You should also seek to align your interests with what the company does which requires research.

At most career fairs there is a list of companies available ahead of time so you can research them and target the companies that do work that best aligns with your interests. If you aren’t sure about what your passions are or it’s hard to figure out what the company does, be prepared to put that out there right away. Some of the most awkward moments are when someone tries to improvise what they think my company does. Don’t improvise, do the research. It’s easy, and pays dividends.

Just identify a few things that the company does to show interest and then ask about other things the company does and what market they operate in. What’s important is that you show that you are interested and motivated enough to do the research. This also helps with the common question you may get: “why do you want to work for Willard’s Widgets?” If you’ve done the research you’ll have a good idea of whether you can honestly say that whatever they do is super interesting and you’ve love to help the company be successful.

Other questions you can ask are “what is the culture like?”, “tell me about an exciting initiative at the company”, and as you wrap up the conversation you could ask “when can I expect to hear back?”

To get extra credit educate yourself on the industry that the company operates in. If you can speak intelligently about the major trends in a market and tie it to what a company does, you are instantly distinguished from your peers. Very few early career candidates pay much attention to the business side of things but it’s important to understand the industry you work in, especially as you mature in your career.

Appearance

No need to wear a suit; it’s not the norm for our industry except for executives (and even then there are a lot of hoodies and t-shirts in the wild). But don’t wear pajamas with bunny slippers either. Casual clothes that are clean and not shredded, a folder full of printed resumes, and a cell phone are what you need when you step up to the table to confidently deliver that well-practiced introduction.

If you are comfortable with it, you can add something colorful, or otherwise visibly interesting or memorable, to your outfit that makes you stand out from the blue jeans/black leggings and t-shirt crowd. Don’t be silly or obnoxious, just wear or add something visual and unique to your outfit or just make it more colorful in general. It provides something else for the hiring manager or recruiter to associate with a good conversation when they’re digging through a pile of resumes, trying to decide who to call.

Finally, job fairs can be taxing so make sure you take breaks and have access to snacks and drinks to power you through the event and keep up your energy levels.

Sincerely,

Jeff

Jeff Beard is a director of software development at Oracle Data Cloud. He would also like to acknowledge Caitlin Hickey and Mridula Natrajan for their help editing this post.

You know more than you think

This is a guest post from Cara Borenstein. Enjoy.

Dear new developer,

A couple of years ago, I started my first job in Silicon Valley. I was a junior software engineer at a fast-moving company and I was so excited to have the opportunity to learn. I worked hard. I looked up terms I wasn’t familiar with. I was constantly asking “how?” – “how do I do this?”, “how does this work?” I was shipping code and learning fast.

Only after a number of months, did I realize I was doing something wrong and letting my team down.

It came to my team’s attention that we had chosen the wrong type of core technology for one of our main projects. The team leaders wanted to understand why we had chosen this technology.

I had no idea why we had chosen this technology because I had never asked. Had I asked, we would’ve realized pretty quickly that this technology wasn’t a good choice for our system. But I was confident that my senior teammate always knew the right choices to make.

I didn’t think I knew enough to ask. I had what’s commonly referred to as “imposter syndrome”.

My failure to ask why wasn’t just a missed learning opportunity for me. It resulted in my team making an expensive mistake of choosing a wrong technology.

Now I can see that I did know enough to ask why and it was my responsibility to do so. The same goes for you, new developer.

Software engineering is a lot about tradeoffs – choosing one software design over another. Design trade-offs are often not completely clear cut and they warrant a discussion. You don’t need to have decades of experience to be able to understand the choices you and your team make. You just need to do your part to make sure your team has these discussions.

When you ask your teammates why you push them to explain their thought processes. This helps your team to more thoroughly evaluate different options and to eventually arrive at better decisions.

Moreover, these whys create some of the best documentation for future engineers that join the team. If the thought process behind a choice wasn’t obvious to you, it will likely be confusing to many future team members too.

How to ask “why”

Here are some tips that have worked well for me.

First, make sure that you are asking “why” with a mindset of learning and understanding, not blaming. This will shape how you phrase your question. For example, you can start your question with “I’d like to understand why we…” or “I’m unclear as to why we…”.

Then identify one person who is likely best to discuss “why” with. More often than not, you’ll want to start by asking one senior engineer on your team or your technical lead. After speaking with them, if there’s further discussion or changes needed, you can bring this to the rest of your team together.

To initiate your question, bring it up informally without an expectation of immediately discussing it. This can be in an informal conversation, at your team’s daily standup, or in a Slack message. For example, you might ask – “Hey teammate, I’m confused as to why we’re… Do you have time later today or tomorrow to go over it?” With this approach, you can communicate your question while being respectful of your teammate’s time.

How to document “why”

Now that you’ve asked “why,” you may have driven some changes in your team’s plans, but you definitely have learned something interesting. Write it down! This is some of the most useful documentation your team can have.

When writing down why be sure to include

  • your question
  • a summary of what you discovered
  • any constraints that impacted your team’s choice
  • any other options your team considered and the pros/cons
  • any action items for your team given what you learned

Ask your teammate to review your written “why” to make sure you didn’t miss anything and are on the same page. Once it’s approved, share it with the entire team.

If your team currently uses a wiki or shared drive solution for documentation, you can

  • create a “start with why” folder
  • write a new document for each “why” within this folder
  • add a hypertext link to this document from each software doc that’s impacted

Start asking “why”

So, new developer, asking “why” will help you learn faster and help your team make better choices. And writing down “why” will provide your team with useful documentation for future work. So get started now. Start asking “why.”

Sincerely,

Cara

Cara Borenstein is a founder at Bytebase – a collaboration tool for lightweight knowledge sharing. If you’re interested in a faster way to capture and organize your “why” learnings, you can try out what we’re building at Bytebase.

Be Adaptable and Authentic

This is a guest post from Morgan Whaley, lightly edited. Enjoy.

Dear new developer,

Honestly my #1 piece of career or technical advice to new developers is:

Be adaptable and authentic.

I don’t think there is any one magic bullet to helping someone “break into” a job, or business, or new city. Humans are all different and the beauty of diversity in industry and environments is when everyone truly brings themselves and overrides the homogenization that we accuse modern cities and tech of becoming.

If something isn’t working, there’s “no harm, no foul” in changing approaches, or taking a break, or simply admitting something isn’t working.

I see a lot of people who treat that first job like it’s a task they gotta beat into submission and they tie so much self-worth to it. Which is completely understandable… but the more you resist a situation and don’t remain open to possibilities, the more you are going to run into brick walls.

Morgan

PS Also, LEAVE YOUR HOUSE AND GO TALK TO PEOPLE FACE TO FACE OH MY GOD PLEASE IT’LL BE OK.

Morgan Whaley is a Senior Prototype Architect at Charter Communications.

It is never too late to start learning how to code

This is a guest post from Jenna Quindica. Enjoy.

Dear New Developer,

I didn’t learn how to program until I was 18; in fact, I didn’t know about computer science the concept until I was 18. It is never too late to start learning how to code.

In the beginning I struggled the most with navigating acronyms, words, and phrases I’d never heard of. I vaguely knew what a server was, but I didn’t know what a command line was, let alone what you do with one. File extensions that weren’t Microsoft Word, Excel, or PowerPoint confused me. The closest I got to computer science as a kid was clearing my Chrome browser history. My Neopets password was five alpha characters, and I was devastated when my account got hacked.

I didn’t start to enjoy programming until I knew how my piece fit into the rest of the picture. Find a friend who can teach you the vocabulary so that you can better understand the ecosystem.

Warmly,
Jenna

Jenna Quindica is a software engineer at First Round, a seed-stage venture capital firm. She dropped out of her computer science major at Cornell University to work at four early-stage startups. She lives in the San Francisco Bay Area.

How to Develop Expert Intuition

This is a guest post from Kim Schlesinger. Enjoy.

Dear New Developer,

I know you worked hard to get where you are. You are self-taught, you earned a degree in computer science, or you graduated from a coding bootcamp, and your hard work helped you master the skills required to be a ‘junior’ developer. (I prefer the term early-career developer, but I’ll use the terms junior and senior developer in this blog post.)

Whether you are still searching for your first dev gig, or you’ve been at your first job for a while, you’re probably wondering what it will take for you to be a senior developer. There are lots of factors that contribute to being a ‘senior’, but the most important one is time.

It takes time to become a senior engineer because you are developing what behavioral economist Daniel Kahneman calls ‘Expert Intuition.’ Expert intuition is knowing how the story ends because you’ve read the book many times before. Expert intuition means that you can see a technical problem and you just know how it can be solved. Expert intuition is the difference between a junior and senior developer.

Kahneman says that the ingredients for this kind of expertise are

A Regular World + Many Opportunities to Learn + Frequent Feedback = Expert Intuition

Let’s take a look at what these things look like for a new developer.

A Regular World

A regular world is where there are a set of rules you can learn. For a new developer, that means a job where you can observe and begin to navigate your company’s culture. It also means having an opportunity to write code with a few programming languages, frameworks and approaches to deploying software. Even if your company’s culture isn’t great, or you’re not writing code in the language you prefer, your early experiences will help you figure out what you do and don’t like in a company, and if you’d like to specialize in a specific part of the software creation process, or remain a generalist.

If you’re still searching for a job, you can create a regular world by setting aside time each week to work through exercises on a learning path like Exercism, contributing pull requests to open source projects or civic hacking projects through Code for America and networking and applying for jobs.

Many Opportunities to Learn

As a new developer, your most obvious opportunity to learn is to write code and work on technical projects. Definitely do that, and know that another way to learn is to observe engineers that are more senior than you.

Pick one colleague you admire, and notice how they learn new concepts or technologies, how they ask questions in meetings, and what they do on a project before they start writing code. Ask to pair with this person, take them out to coffee and ask them what technologies they’re curious about, and how they approach writing code. As soon as you identify some of their signature behaviors, start to emulate them.

If you’re still looking for a job, find a streamer you like and copy their behaviors. I’m a fan of Coding Garden with CJ and Suz Hinton.

It’ll take time for you to make these behaviors your own, but being intentional with how your craft your developer habits and mindsets is a faster path to becoming a senior engineer than other, more conventional, learning opportunities.

Frequent Feedback

The final element that will help you develop your expert intuition is getting frequent feedback. You can get feedback from other developers through code reviews, you can get feedback on your technical and non-technical performance through regular 1:1s with your manager, and you can reflect and improve on your performance by keeping an end of the day journal where write down what you learned and how you felt during the day.

It Takes Time

In June of 2018, I took a job as an apprentice Site Reliability Engineer. Before that, I was a full-time educator, and part time JavaScript developer. I assumed it would take me a few months to figure out how my new company operated, and 6 or so months to get a grasp of cloud computing in AWS and Google Cloud Platform, Docker, Kubernetes, and the wide variety Continuous Integration/Continuous Deployment platforms.

I’m a year and a half into the job, and although I am more skilled than when I started, there is still so much for me to learn and do. Moving from web development to site reliability engineering is a big transition, and I underestimated hard it would be. I’ve made peace with the fact that it will take me years before I will be an expert. New developer, you’re starting a new career, and it takes years to grow into your professional self. It takes time, so be patient, and remember the ingredients for developing expert intuition.

Sincerely,

Kim

Kim Schlesinger is a Site Reliability Engineer at Fairwinds Ops. Prior to Fairwinds, she co-founded diversity, and was an Instructor, Developer, and Curriculum Designer for the Web Development Program at Galvanize, a codeschool based in Denver, Colorado.
In her spare time, Kim is a CrossFit athlete and the Head of Education and Content for Develop Denver, a 2-day conference for developers, designers, strategists and tech leaders.

Start the conversation

This is a guest post from Tae Kim. Enjoy.

Heyo!

So you’ve entered the world of… development? Software engineering? Programming? Coding? So many words for the same thing! I usually stick with “Software Engineering” for the resume because that sounds the fanciest, and fancy === money. But when my friends or family ask, I say that I do “computer stuff”. That usually works.

You’re probably thinking, “wow… what lame advice”. But you’ll see. You’ll see…

So about me! I’m Tae. At the time of writing this letter to my fantastic reader (YOU!), I’ve been developing for about 6 and a half years. I work at Airbnb in Silicon Valley. (If you haven’t seen the show yet (Silicon Valley on HBO), I highly recommend it. First season was the best, but you gotta watch ‘em all.) I primarily work in the Frontend realm, typing my 1’s and 0’s in Javascript and React. If you are still playing with jQuery… stop that and learn React. Trust.

But enough about me-self! Today I’m going to give you my one piece of advice. The one thing that I do that makes me successful at my job. It’s not coding really really fast. Nor is it knowing how to implement Quick Sort in O(n log n) time. It could be that my JIRA velocity is off the charts – but it’s not. No no no. It’s something far more crazy. Something far more insaneeee! It’s this…

When I’m at a good stopping point from my work, I step away from my desk, walk over to a random teammate (sometimes a random person), and ask, “Heyo, whatcha working on?”. Bat shit crazy right?!?

Well, the responses vary from person to person.

You sometimes get a short answer like “Oh, just fixing this bug. *turns back to monitor and puts on headphones*”. That’s totally OK, they are probably in the zone and you should slowly walk away. Try not to judge them too hard. *whispers asshole under breathe*

Other times, they have something super rad to show off like “Yo! I just fixed this crazy bug in IE. Check it out!”. These responses are awesome because you can dig in and learn something new. That same bug will show up in your work, it’s just a matter of time.

Then there are times when they say, “Yo… I have to fix this bug but have no idea what to do :sadface:”. That’s a great time to sit down and pair on a hard problem. Maybe you don’t know the answer, but you can be there for both support and as a Rubber Ducky (google: rubber ducky programming). Don’t be afraid to pull in other people around you and have a group brain sesh too, those are the best! #teamwork

These types of responses aren’t actually why I give this advice though. Learning and helping is great, don’t get me wrong! But this action is more than that.

You are being a teammate. You are building relationships. You are creating culture.

I know I know. How can a single question create culture? That’s nonsense!!! And I agree. But it’s a great start. It’s the doorway if you will. Once you enter, you then gotta walk the hall, turn into the dining room, sit down, and start eating. No really, grab a meal with your teammates too.

Sorry if that didn’t make any sense. I do that sometimes.

What I’m trying to say is that if you are genuinely interested in your teammates, they’ll recognize this. They will appreciate this. It’ll lead to way more than a simple IE bug fix. Hell, it might even lead to a new best friend!

I don’t think we join a company to sit at our desks alone, heads down, without wanting to speak to anyone. I think we’re just not comfortable making the first move.

But if someone begins the conversation, we’re very willing to reciprocate.

So start the conversation! Get people interacting! That’s what culture is. That’s what a fun work environment is. Ping pong tables? Those aren’t culture. Those are doorways to get culture (I know, the damn doorway metaphor again).

Airbnb has a slogan of “Belong Anywhere”. At first, I thought it was some cheesy line that our CEO preached. But I get it now. Especially in the world of developers, where it’s so easy to get sucked into your computer. It’s very easy to become siloed.

Nobody wants to go home thinking “Man, I don’t really have friends at work” or “Aw shucks, nobody said hi to me today”. That would suck.

Instead, what if they went home thinking “Oh man, I’m really glad I got to work with <insert your name here> today” or “Wow, I really love my team”. That would rock.

So be that spark. Create that culture. Because you are fucking awesome.

Tae

P.S. Say “Good morning” and “Good night” when you come in and leave. It’s better that way. Trust.

Tae Kim does computer things at AirBNB.

Cultivate the Skill of Undivided Attention, or “Deep Work”

This is a guest post from Josh Thompson. Enjoy.

Dear New Developer,

You know that there’s a chasm between your skill level and that of the mythical “senior software developer”.

If you build a list of topics you encounter on your job that, if learned to a deep enough level, would put you on the same level as a senior developer, you’ll end up even more demoralized than before compiling that list.

No need to assemble this list yourself! I’ve done it for you.

Here’s the list of topics that I’d need to dedicate significant time to, in order to close the gap between me and the senior developers on our team, that I’ve encountered in my last two days of work:

  • Breaking complex unknowns into simpler unknowns that can be further split into individual tickets
  • Adding tests to complex, legacy code, to guide further refactoring of said code.
  • Using `grep` to comb through server logs to diagnose a hard-to-identify-and-reproduce problem
  • Provisioning new servers
  • Building bash scripts to automate complex workflows
  • Digging into gem source code to can shed gem dependencies while maintaining certain features
  • Understanding indexing well enough to see that certain queries that we thought were using indexes were not, and fix this oversight index on the fly, without causing any blips in availability

Each of these line-items has many books written about the topic.

It seems like you could fill a bookshelf with books that address knowledge senior developers have available to them inside their own heads.

It takes me long enough to work through a single book, so imagining a bookshelf of extra-curricular reading is quite daunting.

It might feel daunting for you, too.

Leading vs. lagging indicators

The above list of skills is a lagging indicator of the underlying knowledge. We should not target improving lagging indicators, we should improve leading indicators.

Josh, what is this ‘lagging and leading indicator’ stuff?

Great question!

A lagging indicator is “evidence that something has already happened.”

If you got an A on a test, that is evidence that you learned the material.

A leading indicator is “evidence that something will likely happen”.

If you want to get an A on a test, you should study in a similar way as others who have gotten an A on that test. Maybe you need ten high-quality hours of study to get an A, so “number of high-quality study hours” would be a leading indicator of your grade.

We no longer take tests (phew. I hated taking tests.) but we get mini-tests of our knowledge, daily. We’re paid to solve problems, which often require learning new things.

Rather than focusing on a list of things other developers have learned, and targeting that list, I humbly propose that a leading indicator of acquiring this kind of knowledge is “hours per week spent in a state of intentional deep work”.

The above list of topics are lagging indicators of a high degree of technical knowledge. Someone acquires the knowledge, then, and only then, can demonstrate that they have it.

Leading indicators are “predictive”, in that if you can identify correctly those indicators, you can predict the outcome of the issue at hand.

In this case, the issue at hand is “become significantly more experienced in the domain of software development”.

I propose that a leading indicator of someone gaining these skills is the amount of time they spend in a state of deep work.

I’d encourage you to read Deep Work: Rules for Focused Success in a Distracted World. The author makes a case for deep work being a key role in the success of “knowledge workers” (which includes many types of work, including, of course, software development.)

If you’d rather not read the book, here’s the gist, from this summary of the book:

  1. In order to produce the absolute best stuff you’re capable of, you need to commit to deep work.
  2. The ability to quickly master hard things and the ability to produce at an elite level, in terms of both quality and speed, are two core abilities for thriving in today’s economy.
  3. “To learn hard things quickly, you must focus intensely without distraction.”
  4. “Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright you can generate meaning in the daily efforts of your professional life.”
  5. “The key to developing a deep work habit is to move beyond good intentions and add routines and rituals to your working life designed to minimize the amount of your limited willpower necessary to transition into and maintain a state of unbroken concentration.”

Imagine two equally knowledgeable early-career software developers. They have the exact same skills on January 1, 2020. If the first software developer spends four hours a week doing deep work, while the second software developer spends fifteen hours a week doing deep work, their trajectories will be quite different, and that second developer will quickly gain technical knowledge and proficiencies.

So, if you’re an early-career software developer, track the time you spend doing deep work. That has you focusing on a leading indicator of growing in your skills.

At that point, you’ll benefit from Peter Drucker’s assessment:

What is measured, improves.

You’ll track how many hours you spend doing deep work, and by tracking it, you’ll do more and more of it.

In conclusion

Do more deep work, and over a year or two years, your skills will grow much faster than those doing less deep work. Eventually, you might find that you’re doing the work of a senior developer!

Good luck!

-Josh

Josh looks forward to being a senior developer some day. He’s only a few years into his career in the software development industry, but enjoys getting to bring knowledge and skills from his prior careers into his current role. He lives in (and works remotely from) Golden, CO, with his wife and loves to rock climb and read books, and can often be spotted in Denver-area climbing gyms or local crags.