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.

Why software engineers are grumpy

Dear new developer,

I thought that this post, “The care and feeding of software engineers (or, why engineers are grumpy)”, from 2012 was still relevant today. It’s a long one, so I won’t excerpt all the interesting parts, but this really resonated with me:

Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.

The author explores the metaphor of the house, and how you really should fully define such a structure before you start building it. And yet, sometimes software is “just started” and defined and re-defined as needed changes are discovered

The author doesn’t let software engineers off the hook either:

Software engineers are put into a difficult position every day, but we are not victims even though those of us who are more melodramatic tend to act that way. Part of our grumpiness actually comes from within, with something that for some reason is deeply ingrained in the majority of software engineers. We have a tragic flaw and that flaw is that we overestimate our knowledge and abilities..

In addition to all the complaints engineers have, it also has a few suggestions about ways to help (including appreciate the engineer’s effort and cross functional training). Well worth a read as someone who either works with software engineers or as someone who is one.

Sincerely,

Dan

How to manage one to ones

Dear new developer,

Hopefully you’ll work in a place where you’ll have regular one to ones with your manager. I find these helpful for building a relationship and engaging with your manager and your reports (if any). I even did them with my co-founder when I founded a startup.

These meetings tend to be 30 minutes and on a regular cadence (weekly, biweekly or monthly, typically). If you are face to face, you can have them in the office, but going for a walk or to lunch is a great way to mix it up as well. If you are doing them over video chat due to being in different locations, it’s best to have a great internet connection, a quiet space and video turned on. There are nuances you pick up via someone’s face that you’ll miss if you only have their voice.

The purpose of these meetings is to keep communication lines open for both parties. It also helps both parties get to know each other as people. People generally react poorly to surprises and stress, but building the relationship and communication practices before any of these situations arrive (and they will) will help the team to navigate them.

It’s worth stating that as a new developer, you probably don’t have a lot of influence over many things. In fact, you might not even have a one to one. If you don’t, the first step is to ask for a regular meeting with your supervisor. You can start with a monthly 30 minute meeting, which shouldn’t be impossible to schedule. I’d frame this request in terms that are helpful for the company and your supervisor:

  • I want to understand where we are heading
  • I want to know how I can best help you and the company
  • The insights I gain will help me be more effective in helping the team

If you do have a one to one, you can use it to share knowledge and gain understanding. Here are some tips for making the most out of your one to ones as a new developer.

First, schedule (or ask for) regular meetings at a time that works for both of you. Be cognizant of each other’s schedule (does someone like to get up early or work late? Are you in the same time zone?). Scheduling these back to back can be helpful for a manager. And scheduling them outside of “in the zone” blocks of time can make sure that there’s time for other work to be done.

The fact that the meetings are regular is important. They don’t have to last the entire scheduled time, but the manager should never cancel them, and if they must be rescheduled, do that promptly. (This meeting is very important for you as a new developer, and the manager should treat it that way.) If your manager is stretched too thin or is for whatever reason not treating this like an important meeting, suggest decreasing the frequency.

Regular meetings establish the relationship. If the only time you are meeting with your manager is when there are issues, you need guidance on work to be done, or at your performance review, that relationship won’t have the time to grow.

As the employee, come to a one to one with your agenda. I use a google doc in reverse chronological order, with the current meeting at the top. If you can, share this with your manager. Over the week or weeks between your meetings, add items to this doc. This can include items such as:

  • How should I have handled situation XXX?
  • I’d like to learn more about NoSQL databases; what are the opportunities at this company?
  • I’m struggling with XXX, do you have any suggestions?
  • What are the challenges you see facing our team during project YYY?
  • I heard a rumor that we’re opening a London office; is there anything you can tell me about that?

In general, topics should be about professional challenges, discussions or opportunities. Some chitchat about what you each did over the weekend is good social lubricant, if you both feel that way. (I’ve struggled in the past with connecting to reports, but found that discussing their out of work interests can lead to good conversations and a stronger relationship.)

I like to record action items for myself and the other party right in this google doc (sometimes the action item may be as simple as “bring this up again in three months”). This means that when the next one to one comes around, I can see what we discussed last time and if there was any progress. This doc is also great for preparing for your performance review, sharing with a new supervisor, or even just to see what you’ve done or been concerned about over time.

Another thing that I’ve had to learn over the years is that one to ones are a great place for me as an employee to ask for what I want. It’s awkward for me, because I’m a people pleaser at work, but if I don’t ask for what I want or need from my supervisor, how will they know? Now that doesn’t mean you can ask for the moon, but if you see opportunities in adjacent areas to your current work, ask for them.

If you see technologies that you think would make everyone’s lives easier, ask if you can investigate them. If you see a conference or other educational opportunity, ask if there’s money for you to attend. I remember at my very first job, I was interested in learning about databases and database administration. I asked my supervisor about doing a three month internship in that group, and they let me do so. I learned a lot about the data driven mindset during that time.

What is said in a one to one should be kept private, unless sharing it is discussed and both parties agree. Keep the agenda doc between the two of you. I think this article, “The 1-on-1 Disclosure Framework”,  covers the levels of privacy very well.

Finally, it’s worth acknowledging that there’s a power differential in every one to one, based on the fact that the manager influences and/or controls the employee’s role, salary, and job. This meeting isn’t about being buddies or friends, but rather about building the person to person relationship that will allow both parties to thrive and help the company with its goals.

Sincerely,

Dan

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.

Never stop learning

Dear new developer,

I was at a lunch a few weeks ago and asked some senior engineers and managers what advice they’d give to a new developer. One said: “never stop learning”. I thought this was a perceptive answer and wanted to expand on it. I learn something new every day. I’m going to talk about how to learn and then why people stop learning.

First, how to learn. I think the short answer is “Google”. The internet is an amazing place.

The longer answer is:

  • Think about why you want to learn. Is it for fun? To find a better job? To be better at the job you are at now? A side project that you are interested in? Scratching your own itch with a solution? Because you want to make the world a better place? Having a firm “why” will encourage you when things are difficult.
  • Determine what you want to learn. From the why comes the what. Is it a business  domain? A particular technology? A framework? A certain mindset?
  • Consider how you want to learn it. After what and why comes the how. Do you learn best through videos? Reading? Code tutorials? Blogging? A realistic side project? Reading others’ code? Try each of these if you haven’t and see what gets you excited and what seems to cause knowledge to stick.
  • Execute. That one little word is hard to do. But you need to find the time and the willpower to take the why, what and how and actually do it. As some say, it’s easy to write and hard to do. Start. And when you fail to make as much progress as you’d like, think about the why.

Why do people stop learning? I think there can be any number of reasons:

  • Bored: they simply aren’t interested in learning.
  • Frustrated/blocked: they can’t learn what they want to because of other constraints.
  • Tired: too much else going on and they need their energy for other things.
  • Comfortable: they know what they need to know and are “punching the clock”.
  • Shifting priorities: other things in their life have taken precedence.

All of these make sense. And it’s important to realize that you have a job to live your life, you don’t live your life to succeed at your job.

But, if you are not interested in learning new things, pretty soon technology will pass you by. You can still make a great living, but opportunities will get fewer and fewer, and you may need to shift companies or locations, or give up salary. There are definitely people still writing COBOL, but every year fewer companies need it. There may be people still writing java applets, but I can’t think of any companies that need that particular technology.

Another thing to note is that sometimes a shift in perspective, whether a new job or a new way of looking at your current job, can remove some of the obstacles that prevent you from learning.

So, figure out how you want to learn, and never stop doing it.

Sincerely,

Dan

Confessions of a conference speaker

Dear new developer,

When I was newer to development, I thought that conference speakers were experts in their area, harbored no doubts, and that they knew exactly what they were doing. Speaking about technology seemed scary (until it wasn’t).

I enjoyed this post, “Confessions of a Conference Speaker”, pulling back the veil on the experience of a prolific tech conference speaker–20 talks in 2019. (She also has a post about being a conference attendee.)

I particularly enjoyed this section, titled “The Audience is Rooting for You”:

People come to conferences and attend your talk with the hope of getting value for their time. But that’s what is important to remember. They WANT to have chosen a good talk. They WANT you to succeed!

Being a speaker can be nervewracking for any number of reasons. There is so much prep that goes into it. Not every talk will go perfectly. But it helps to remember that the audience is rooting for you. This is especially true with those live coding mistakes. They’ll enjoy helping out 🙂

And the tips about a tech check and adding your author info on every slide were spot on based on my limited experience.

I can’t recommend public speaking enough for a a way to level up your skills. It can be terrifying, but you’ll learn:

  • how to dig into a topic
  • how to present something in a coherent fashion
  • the confidence of knowing that you (likely) know more than anyone else in the room on this topic
  • the value of connecting to your peers

If you are considering doing a talk, I’d suggest starting at a meetup or a lightning talk at a conference. Read the whole post to get Laurie’s inside view.

Sincerely,

Dan