How to be a 10x engineer: Business value for technologists

This is a guest post from Donnie Berkholz, lightly edited. Enjoy!

Dear new developer,

Since joining an enterprise (the world’s largest business-travel company) a while ago to drive their DevOps transformation, my ongoing mental evolution regarding the value of technology has gone through an almost religious rebirth. I now think in a completely different way than I did 10 years ago about what technology is important and when you need it. If you want to become a 10x engineer, you need a different perspective than just working on things because they seem cool. It’s about working toward the right outcomes, whereas most of us focus on the inputs (what tech you use, how many hours you work).

It all comes down to business value. You need to contribute to one of the core factors of business value, or however incredible the technology is, it just doesn’t make a difference. If you don’t know what that really means, you’re not alone — most of the technologists I know have trouble articulating the business model of their employers.

I think about it as 4 primary factors:

  • Money. This comes in two flavors. First, you’re creating new efficiency, which increases the profit margin. This could either be through lowering the underlying fixed costs of running the business, or decreasing the cost of goods/services sold by saving a little money on every one. Second, you’re increasing sales, which grows overall revenue. In a cost center within a larger enterprise, or in saturated markets, the former is the most common mode of operation because it’s hard to capture new opportunities. In the latter, it’s about growth mode – investing to capture new value, and often assuming you can make it profitable later. This could be framed as “land and expand” or with the assumption that your company will increase the price and margin once it’s gained a sufficient market share to do so with lower risk. Do you understand your company’s business model? Where does the money come from, who are the customers, what are their needs, what is the sales process and cycle, and what are they buying?
  • Speed. Again, there’s a couple of versions of this that overlap. The overall goals are either initial time to market or speed of iteration. Time to market can come at the expense of significant technical debt, while long-term accelerated iteration cycles are about product-market fit. If you know of the Lean Startup approach promoted by Eric Ries, this should sound familiar. From a long-term perspective, iteration cycles require a balanced approach of customer perspective and technical debt. Otherwise, your company can’t deliver value to customers quickly due to accruing interest on its tech debt. In practice, this can drive an approach that involves gradual refactors with the assumption that long-term rewrites (or e.g. strangler pattern) will be required. It’s the classic “design for 10x but rewrite before 100x,” to paraphrase Google’s Jeff Dean.
  • Risk. As before, this essentially boils down to executing on new opportunity or loss to existing opportunity. Dan McKinley has a fantastic post on why you should choose boring technology, because the important risks are in the business model vs the tech. You should only make a small number of bets on new technology when it will really make a difference in your ability to deliver on business value. For existing opportunity, it’s more about risk avoidance. Typical approaches tend to end up in some mainframe application that one nearly retirement-age developer knows but is afraid to touch. However, a more sustainable model is to implement heavy automation if it truly is a business-critical application that justifies the investment. Relatedly, risk avoidance is where security shines. One of my favorite perspectives is Google’s BeyondCorp model, which assumes your perimeter is compromised and acts accordingly.
  • Strategy. Often not immediately visible in the above approaches, investing in strategic growth opportunities is consistently a great path to success in your business. Do you know your company’s strategy? They probably have posters up and meetings about it all the time. Could you say it out loud? Do you know how it maps to concrete actions? Although any individual opportunity may fail, your contribution to executing on the technology behind that opportunity will not go unnoticed. Similarly, if you’re involved in divesting from areas your employer wants to leave as part of its strategy, you have a real but often smaller opportunity to leave your mark upon the work.

Although many other factors have an impact upon business value, those are 4 of the most important ones that can make you consistently successful as a technologist. The key is to understand which ones play into your work, so you can act accordingly in your day-to-day efforts and as part of your career strategy. Are you building software for a cost center, a growth incubator, a risk center, or at a company that cares to invest in speed? Taking full advantage of this approach could make you the 10x engineer you’ve always wanted to be. Best of luck in your journey, and may you spend time where it matters!

Sincerely,

Donnie

Donnie Berkholz has been driving the DevOps transformation at CWT (formerly Carlson Wagonlit Travel) since early 2017. Prior to that, he led a global team at 451 Research providing research and consulting around leading-edge trends in software development and DevOps. His background includes roles at RedMonk — where he focused on DevOps and open source — and well over a decade at Gentoo Linux, where he worked his way up from a developer to lead a group of more than 250. One of his passions is the social side of technology, and he’s led initiatives to turn around unhealthy teams as well as measure and act on open-source community metrics.

He got into tech almost by accident, because his role as a biophysicist got increasingly computational and he decided he wanted to focus on the technology. Prior to tech and science, he did a stint as a journalist. Donnie now combines that diverse skillset in communications, data-driven thinking and technology to drive companies toward differentiation with leading-edge technology.

I’m writing the book I wished I’d read

Dear new developers,

Update July 5, 2020: I now have a launch date and a cover.

You may have noticed the pace of new letters has slowed down a bit. There have been some fantastic guest posts, but there’s only been one new letter per week for a while. There’s a reason for that.

I’m excited to announce that I’m writing a book. It’s the book I wished I’d had when I was beginning my development career.

It’s based on this blog, with ideas, text and guest posts drawn from it. The format is similar: letters covering a variety of topics. However, all the content has been thoroughly reviewed, organized and revised. You’ll also see new letters covering topics left untouched by this blog.

I just shipped off the first half of the book to the publisher. If you want to be in the loop, contact me to be put on the book announcement list.

– Dan

You’re going to put some plates in toasters

Dear new developer,

I saw this insightful tweet:

The whole thread is worth reading, but you get the basic idea. Sometimes you don’t know what you don’t know.

When I think back over the years, I am amazed at how many things I can do without thinking now that would have been baffling to me at the beginning of my career, including technical and non technical knowledge). This list includes:

  • navigate files and directories work
  • examine an HTTP call
  • determine the performance characteristics of an application
  • refactor an application
  • architect a large application
  • run a meeting
  • plan a project
  • exit vi

The road is long. And I still put plates in toasters periodically.

Recently at work, I energetically revised a planning document, adding what I thought was a ton of insight and value. Later I found out that the value I added was actually negative and that I’d done more harm than good to the organization’s goals when adding my thoughts. Man, was that a humbling and learning experience. Actually, that was more like putting a fork in a electrical socket than putting a plate in a toaster.

Much of what I know is at a high level with the idea that I can dive in (using resources like Google or Stackoverflow or a mentor) if I determine a need. Just knowing that something exists means that I can leverage all the great learning resources available if I see a place where it might appy. I also do a lot of pattern matching, where I compare how one system or process worked and see if and how that knowledge applies to a new problem.

So when you find yourself floundering, take a deep breath, forgive yourself, and dig in to learn. Foundational competence is something that you will acquire with time and study. But until you do, you’ll be putting plates in toasters.

Sincerely,

Dan

Learn an IDE

Dear new developer,

Just like you should learn a text editor, you should learn an integrated development environment (aka IDE). This is typically a standalone program focused on one or more programming languages. They range from free to a couple of hundred bucks in pricing.

Using an IDE will give you the following benefits:

  • It will be easier to navigate a project. Typically IDEs have a tree view of the entire project. Especially if you are not familiar with the command line, having this may make it easier for you to see how pieces of the project fit together. If the language supports it, an IDE can provide powerful searching capabilities, allowing you to see where a function, method or class is used.
  • Often these have refactoring support. Refactoring allows you to easily rename variables, functions/methods and files. If the language or IDE support it, references to the renamed entity can be updated as well. This will help make the code more fluid.
  • Debugging and code inspecting capabilities can be very useful. You can walk through code that is running locally and see the state of variables and make function calls. This is especially helpful if you have a test that can drive the code and replicate a bug. You can also, if the language supports it, connect to remote servers. (Many languages have command line debuggers as well, but it’s usually easier for a new developer to use an IDE.)
  • The IDE can provide text manipulation functionality. For instance, if you want to add documentation comments to every method, or an easy way to generate boilerplate methods, IDEs can provide this. It’s often easy to customize to your needs as well.
  • Easier learning the language or framework. If you are not sure of the exact name or syntax of a library call, an IDE can suggest it (often based on you typing a few letters). The documentation is often integrated as well, so you can, for example, see the javadoc by mousing over a method call (in a Java friendly IDE).

Obviously, as you see above, an IDE is very powerful. It’s also very tied to a language and the language’s features. If you are using a dynamic language (PHP, ruby) your IDE will have different capabilities than if you are using a statically typed language (C#, Java). But in either case, mastering your IDE will make it easier to write and debug code on your development computer.

Sincerely,

Dan

How to go through a layoff

Dear new developer,

At some point in your career, you might get laid off. This is different than being fired for performance reasons (which might happen too, unfortunately). First off, I am not a lawyer, so this is based on experience, reading and research, not a law degree.

Please don’t take this as legal advice or anything other than an informative blog post.

So, you get called in for the meeting. Your boss is there. Likely someone from HR is there. They tell you the news that the company has decided to part ways with you.

Your heart sinks. You get a big fat packet of paper. The HR person runs through it quickly and asks if you have any questions. You feel a bit dazed.

Take a deep breath. Realize that no matter how crushing this feels, two things are true:

  • this isn’t personal.
  • you’ll get through this.

Ask any questions you have. Some important questions:

  • when do you have to sign this packet of documents by
  • is there a severance, and if so, how much
  • what about other things that were yours (401k, FSA, HSA)
  • how to say goodbye to your teammates
  • what about other things that are the company’s (computer, books, equipment, etc)
  • who at the company you should contact if you have other questions

Don’t be unprofessional. Don’t get mad.

Don’t try to get your job back (it’s gone, sorry!). Don’t agree to anything other than reviewing the paperwork.

Make sure they have a non work email for you so they can send you additional docs if needed.

By the way, if they have their act together, you won’t have access to your work accounts after the meeting, for better or worse.

You can ask why you are being let go. Don’t be surprised if you don’t get many details.

Email or LinkedIn are good options for saying goodbye. Write a quick note to your former co-workers stating that you enjoyed working with them. You can express regret at leaving, but there’s no sense in badmouthing anyone. You never know if you’ll end up working with these folks again.

After the meeting, take some notes on what happened during the meeting. Use your own computer or a notebook. This will help make sure you understood everything that happened. If you want, add some details about anything leading up to the layoff (some things are more obvious warning signs in retrospect, and you want to remember them in the future).

Before you sign anything, it’s always a good idea to run any agreement by an employment lawyer. Yes, they cost a lot of money ($X00/hr) but they’ve seen these kind of contracts before and are legally obligated to do right by you–unlike the company’s lawyers who wrote up the agreements, who are obligated to look out for the company. At this point it’s “just business”, and you want to protect yourself. Ask the lawyer for their advice (“does this seem reasonable, are there other clauses I should ask for”), but make clear your budget and timeline. (If you don’t know a lawyer, ask for a referral from a friend.) There may be some back and forth with the company over the documents.

After the lawyer has looked any agreements and you’ve had some time to think, you can sign the agreement. Or you don’t, based on their advice and your feelings.

After that take a bit of time to grieve, if you can. Even if the company or job wasn’t the perfect fit for you, it hurts to part ways.

Then, roll up your sleeves and start looking for a new opportunity. Is it time to try contracting? Maybe something else that is risky? Or to reach out to your network and see what is available?

A layoff feels like a defeat. But you’ll get through it.

Sincerely,

Dan

“It never gets easier, you just go faster.”

Dear New Developer,

Congratulations! Let’s take a moment to celebrate the decision you’ve made to launch or redirect your career. What lies ahead is a lot of hard work, satisfaction, the occasional desire to throw your laptop out a window, and a ton of learning. That’s true of most professions, so you’re also in good company.

As a developer, you will solve a thousand puzzles, and then a thousand more. Your brain will stretch and grow. You will dream about databases or pixels or curly braces. I once had a dream where I was walking down a hallway, but the hallway was my code. It was a good dream. I found a bug.

Greg LeMond, a pro cyclist and three-time Tour de France winner, once said something about cycling that I want to share with you: lemond

“It never gets easier, you just go faster.”

In so many ways, that describes a career in software. The puzzles you struggle with today will be easy in a month or a year. You’ll learn new patterns and best practices. Then you’ll take on new, harder challenges. You’ll struggle with those and learn and grow. Then you’ll start the cycle (pun intended) all over again.

Something I’ll add, though, is that you’ll be able to approach later challenges with more experience and confidence. What we bring to our jobs is an accumulation of skills and experience. This isn’t linear. It sometimes goes smoothly, sometimes it’s faster than we imagine possible. Then there are stretches where it feels like we’re clambering around in the dark.

For instance, I was once asked to write a WAP application (think super early mobile apps before smart phones existed). I had absolutely no idea what I was doing and I was mostly left alone on the project. I started by drawing some screens, took a deep breath, and started building. It was really tough going, but so many lessons have stuck with me from that experience. My skills at breaking down challenges and approaching them bit by bit really improved. I became comfortable throwing away code because the first code I wrote was atrocious. Plus, the project was eventually canceled, which was entirely the right business decision. Through that, I learned about evaluating tradeoffs in terms of business value—my time was better spent on higher priority projects.

In my current adventure, nearly 20 years later, I’m once again writing a mobile app and applying all of those lessons. Picking up languages and frameworks that I haven’t used before is far less daunting. Ensuring that I’m working on the most important thing is a constant recalibration, but one that is comfortable now. Working through stumbling blocks one at a time and having patterns for getting through them is second nature.

Just like learning isn’t linear, neither are careers. Your path will be your own. What you are doing today may or may not be what you’re doing in ten years. You might go into any number of other areas in software, or stay the course as a developer. It’s your life and all those choices are equally valid. One of my former colleagues quit to make hand-built microphones; another makes goat cheese in the Catalan Pyrenees. My personal philosophy is that at each opportunity to make a career decision, you should pick the direction that interests you most. Just like you learn faster when you are interested in your subject, you will ship better software (or make better cheese) when you are interested in your job.

There’s much more I’d love to tell you, but this letter is growing long. I’ll add some concise tidbits before I end.

  • You belong here. Try not to doubt that.
  • Get really good at debugging. It’s a skill and you will need it.
  • If you don’t respect your boss, or if they don’t respect you back, go find a new one.
  • Learning is part of your job. Make time for it.
  • Don’t be afraid to put your code in production.
  • Be a good team member. You will accomplish more and learn faster.
  • Ask lots of questions. Someone else probably wants to hear the answer.
  • And finally, have fun! You’ve got this!

I wish you all the luck in the world!

Sincerely,
Rebecca Campbell

Rebecca Campbell said “hello, world” to software development more than 20 years ago. She started as a developer before moving into team management and then senior leadership, and is currently working on co-founding a startup. She blogs sporadically at nerdygirl.com.

You Should Play (A Lot) More

This is a guest blog post from Zach Turner. Enjoy.

Dear New Developer,

Don’t forget to play. I spent the year after undergraduate working and learning. My goal  was to find a job at a company and eventually I succeeded. However my passion dwindled because it was always put second to finding a salaried position. As a result, my desire to play with and learn about new technologies simply because they are interesting has dwindled and my enjoyment of my job has suffered.

Allow yourself to approach the world as a kid again. Buy an electronics kit and only do
the first example experiment. Learn Hello World in 30 different languages. Start a passion project without worrying about finishing it. If you do finish it, try rewriting it in a new language. Think about a tool (software) that you would like to use, no matter how small or silly, and make it. There is so much pressure to know the newest and most popular languages and frameworks, and have a clean GitHub repo full of complete, relevant, and useful projects. That is especially appealing if you’re looking for a job. Yes, you should have a couple projects that are showcase worthy and speak to your desire to competently code. You should also be able to speak to your desire to learn and solve problems.

At the end of the day code is just a tool. No one faults a carpenter for having multiple hammers. I mean have you ever seen the garage of carpenter or maker, they are usually a glorious mess of projects in various states. Play and don’t fear clutter. Clean as you go and organize if you must. I’d rather have the GitHub of Doc Brown over Patrick Bateman any day. You can be a competent, intelligent adult and still play. If you don’t want work to become a chore, you must play.

From,
Zach Turner

During the day Zach Turner is a software engineer at Culture Foundry, a full service digital agency. At night he is a maker of things useful, useless, and everywhere in between.

Maintain work life balance

Dear new developer,

Make sure you maintain your work life balance.

You’ll never know everything. You shouldn’t try. But even if you accept that, there may still be a temptation to work work work. Why?

  • You want to “prove yourself”. You want to over-index in your first few months. Working extra is an easy way to be more productive, for a while.
  • You want to move up. This engineer did the grind:

At night, even if I had went out with coworkers, I would go home and get back to work. I spent a lot of weekends staring at my computer screen while my friends frolicked (yes, I just said frolicked) at Dolores Park.

  • You believe in the mission of what you are doing. Especially when you are a part owner of a company, it can be fun to work on making that company better and better.
  • Building stuff is fun.
  • Uniquely, when you are contracting, you get paid for every hour you work. If you combine that with the feast or famine flow of work that usually accompanies contracting, it can be hard to stop working when the work is there. (Been there, done that.)

Some extra work, some of the time, isn’t a bad thing. Especially if you are learning or if you enjoy it.

However, you need to make sure you set some boundaries. Companies won’t do that (though a good manager will). One of my best bosses once said “work is a marathon not a sprint” and you need to treat it like that. That means as tempting as it is to overclock and work extra, you should save this for special occasions, if at all.

What can you do instead?

So many options: Call up a friend. Go do something fun. Find a hobby (that is not related to computers). Travel. Visit family. Get outside. Get inside. Read a book. Read a magazine. Volunteer.

And, more importantly, decide for yourself how much time and effort you want to spend on work as compared to the other things in life (this can change over time, by the way). And then communicate those boundaries both explicitly and implicitly.

You can be explicit by presenting choices to your manager: “I’d love to work on project X, but last week I understood the priority to be project Y, and I just don’t have time to do both of them well. What should I do?” (This is an example of the “yes, but” way to say no.) You can also ask about this at the job interview. (Yes, that is scary and shouldn’t be your first question, but it’s important to know.)

You can communicate boundaries implicitly by not answering emails or chat messages out of hours, leaving promptly at the end of the day, and respecting the work/life balance choices of your team mates.

Just like you need to manage your career because no one else will, you need to manage your work life balance, because no one else will.

Sincerely,

Dan

This post was inspired by a comment from JB. on the Denver Devs Slack.

The best career advice I’ve ever gotten

This is a guest blog post, lightly edited, from Josh Doody. Enjoy.

Dear new developer,

Let’s talk about jobs.

My first job

I was 25, and I wanted to move my career along as quickly as possible. I had my first real job, and had gotten three raises and a promotion in only two and a half years, nudging my salary up 12% from when I started. I was feeling pretty good.

Then two things happened that changed my career’s trajectory. First, my boss told me that striving for big raises and promotions would get me nowhere. “The way things work around here,” he said, “is you might get a big raise one year, or even two raises, but they’ll eventually work out so that you’re right back at the average. It’s hard to get ahead or fall behind.” He meant that I might be on top now, but eventually I’d regress to the mean. My boss had been working at the company for 30 years, so he knew what he was talking about. Ouch.

Second, I had been begging for a new challenge and just hadn’t gotten one. I had been looking for ways to stay interested, but got more and more bored, so I asked my boss for a new challenge. He eventually offered me a new opportunity: the same work I had been doing, but in a crummier location. I asked if we could keep looking.

A couple of months later, my boss came to me with yet another opportunity: I would move to a different building and redraw schematics for a 20-year-old piece of test equipment. I could hardly believe it, but he’d actually found a worse position than the one I’d already turned down.

But he made it clear that I couldn’t keep saying no to these opportunities—I was being too picky, and it was making both him and me look bad—so I reluctantly accepted the position.

I moved from a building where I had tons of friends and a 10-minute commute to a building where I had no friends and a 40-minute commute. The clock was ticking on my time at that first job.

Looking for something new

I started looking for a new job for two reasons: first, I needed to get out of there; but second, I wanted to know if I was over-valuing my abilities. I was young but self-aware enough to realize that one very plausible explanation for my frustration was that I just wasn’t very good at what I was doing. Maybe my boss was in the uncomfortable position of having a really ambitious, but really ineffective employee on his hands. Maybe he had done everything he could to pacify me without putting me on an important project that I would just screw up.

Around this time, a friend reached out asking if I knew any web developers looking for work. I told him that I did know someone…me! I had a little bit of web development experience and after we talked, he suggested I might be a good fit for his startup’s client services team. I interviewed with the company’s CCO and he offered me a job as a Project Manager. I had also been interviewing for a managerial position in a different city and, although I didn’t get that job, those two opportunities reassured me that I was a valuable enough employee to take seriously. I happily took the Project Manager job at the start-up.

Before I could start my new job, I had to wrap things up at my old job. Ironically, my manager on my temporary project (redrawing old schematics) had been the best boss I’d worked for my whole time there. On one of my last days, as we were looking over some schematics, he gave me the best career advice I’d ever gotten:

Josh, your first job is where you get your first job. Your second job is where you get experience. Your third job is where you get paid.

My second job

My second job meant a career change from electrical engineering to project management. I took a small pay cut, but that was completely reasonable considering I had no client-facing experience. I went on to work there for five years, scratching and clawing my way to a slightly higher salary than I’d been making as an engineer.

Of course, the money wasn’t what I was after—I wanted experience, and I found it by pursuing unusual opportunities, including a “special project” that ended up being crushed after nine months and getting me laid off. But they soon hired me back to work in a different capacity, which again provided great experience for slightly less pay. This position marked my second pay cut since starting my career, and I was making exactly the same salary I’d made as a test engineer, five years earlier. But by then, I had amazing experience and was in a position to move nowhere but up.

After five years in my second job, I finished up my MBA, which I’d been pursuing on the weekends. I decided to quit and take some time off to travel, relax and recharge.

My third job

After my hiatus, an old colleague from the start-up reached out from a different company: “You looking for work?” I was, and my experience landed me my third job, where I would make almost 30% more money than I had been making when I quit the start-up eight months earlier. Just like my sage manager said, my third job was where I got paid.

I’m glad I heard that advice during my first job, because it allowed me keep putting in time when things got tough. I knew that getting paid was inevitable if I continued to do good work and gain experience. That advice allowed me to stop obsessing over raises and promotions and start focusing on trying new things and building my resume so that when I did encounter a lucrative opportunity, I would be ready.

Sincerely,

Josh

Previously published on JoshDoody.com

Josh Doody is a salary negotiation coach who helps experienced software developers negotiate job offers from big tech companies like Google and Amazon. He also wrote Fearless Salary Negotiation: A step-by-step guide to getting paid what you’re worth to help software developers navigate job interviews and salary discussions to earn more throughout their careers.

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.