Category: career

As a software engineer in this market, you can land a job anywhere you please. Right?

I’ve been thinking a lot about hiring engineers lately. As I’m currently director of engineering at a medium-sized organization, I’m always on the lookout for good software engineers to woo and hire. Moreover, our company is planning to ramp up its hiring effort in the near future. It will be daunting, because the market for engineers is hot, and we’ll be facing a lot of competition from other companies that are also hiring. So that basically means that I’ll be hiring any decent engineer that comes my way, right?

Not a chance.

I’ve been on the other side on the equation, as an engineer. And I know the mentality. My skills are valuable… nay, they’re hot! Any company I’d decide to sign up with would be lucky to have me! I could walk into pretty much any company I pick and leave with a job offer!

As a hiring manager, I can tell you that that’s not true. I don’t know you. My team doesn’t know you. And during the interviewing process, we will have a limited time to get to know you. Everyone you’ve ever worked with might agree that you’re the best engineer they’ve ever come across, but you are–unfortunately–back to square one when it comes to me and my team.

Here’s another secret: with most hiring teams, when it comes to assessing your viability as a candidate, it’s not all about your technical skills. It’s not even mostly about your technical skills. Don’t believe me? The next time a candidate comes into your organization for an on-site, ask the interviewers what their main decision factors were, yay or nay. While there is generally a technical baseline that candidates must meet, the decisions almost always come down to things like:

• Personality
• Potential fit within the team
• Ability to learn and adapt
• Eagerness about the company and what it’s doing

In Building Great Software Engineering Teams, Josh Tyler describes asking his engineering team to outline their most important qualities in a candidate. While the answers varied across team members, among the top answers were that the candidate:

• can teach the team something
• loves programming and technology
• is pleasant to be around

Nowhere at the top of the list was anything about being able to write out algorithms on a whiteboard.

Why should you care?

You’ve been to plenty of interviews in your career, and you’ve landed good jobs. If you were to lose your job in today (particularly if you’re living in one of the many hot engineering markets), you could probably land a job within a week or two. You’re doing fine in your interviews, so why change anything?

Well, let me let you in on another secret: hiring is not binary. Candidates are not simply grouped into yes‘s and no‘s. There are, of course, candidates that we don’t outright want to hire. Other candidates that aren’t quite at the moment, but we might consider in the future. There are of course candidates that we would like to hire.

And then there are the candidates that we need to hire.

You, of course, want to be in that last category. Because here’s yet another secret: once you’ve landed in that category, you’re in control of the hiring process. You’re much more likely to command whatever it is that you’re looking for. A higher salary. More equity. A signing bonus. Lenience in your starting date. Extra vacation. Even a higher role within the organization (which presumably, would carry higher financial incentives).

Once you’ve landed in that category, you’re in control of the hiring process.

In other words, there is a huge difference between a team’s grudging agreement to make you an offer, and a team’s insistence that it must do whatever it takes to get you onboard.

Also, consider your career trajectory. Many engineers enjoy good, comfortable careers having never risen about the level of Senior Engineer. But to get much beyond that level, non-technical skills become much more important. Competition becomes tighter, and we hiring managers become more picky.

So what should you do?

In preparing for interviews, most candidates focus on honing their technical skills. That is, of course, not a bad idea. After all, you will be assessed on them… in part. But you should focus equal time, if not more, on being able to sell yourself as a person to the interviewing team. You might have memorized how to reversed a linked list. But will you be able to convey your enthusiasm for programming? Are you prepared to demonstrate your ability to learn? Will you be able to teach your interviewers something?

Your interviewing preparation should start with one premise: You are interviewing the company just as much as they are interviewing you.

We place too much emphasis on the notion that interviews are all about the candidate attempting to prove him or herself to the interviewers, in hopes of receiving a job offer. But the inverse is also true. If you’re worth your salt as a software engineer, then you should be just as picky as they are. You should insist that the company sell itself to you.

If you adopt that mindset, everything else will start falling into place.

Be choosy about whom you interview with

In fact, this mindset should come into play before you begin talking to any companies. It should guide your decision as to which companies you’re even willing to talk to. Look for companies that are doing things that excite you. If you’re contacted by a recruiter, do some research on the company that they’re pitching. Does their work sound interesting to you? Is it an industry you know anything about, or care about, at all? Find out what technologies the company is using. Do you have any special expertise or interest in those technologies?

In other words, how much of an intersection is there between the company and what you want to be doing?

If there is little intersection, then you’ll find yourself at a disadvantage in talking with these companies. They also, clearly, might not be the right companies for you to join in the first place. Conversely, if there is a lot of overlap, you’ve potentially found a company that you would enjoy working at, and for which you’d be better positioned to prove yourself.

Think of phone screens as conversations

You’ve found a company that is doing things that excite you. You’ve set up your first interview. More than likely this will be a so-called phone screen, maybe with a recruiter or perhaps with an hiring manager.

What usually happens in these screens? The interviewer asks you questions, and you answer them, right? What if, instead, you asked them the questions? Not for the whole conversation, of course; certainly the interviewers have things that they want to know of you. But your answers should segue into questions for them.

For example, if you’re a Java programmer, you might be asked the latest version of Java you’ve used. Your answer should go beyond simply stating the version number. Talk about some of the features introduced in that version. If you were involved with moving standardizing your organization on that version, tell them about that. Moreover, ask them what version they are on. If it’s not the latest version, why haven’t they upgraded? If it is the latest version, why did they upgrade?

Ask your interviewers meaningful questions

Most interviewers will reserve some time–usually at the beginning of the session or at the end–for questions. This time is is generally very short, so you should ensure two things:

1. you don’t squander the time asking trite questions, and
2. you ask questions throughout the session

Don’t ask trite questions

I can’t tell you how many candidates have asked me “what’s your tech stack?” This question tells me a couple of things about the candidate.

First, that they’re not willing to apply much thought or creativity when it comes to solving a problem (the problem, in this case, being what question to ask me). Second, that they couldn’t be bothered to do the minimal amount of research that it would’ve taken to answer that question on their own.

It may be that you truly want to talk about the company’s tech stack, if there is something noteworthy that ties to your own experience or interests. Here are some better ways to broach the subject:

• “I noticed that you use Go as well as Node.js. I’ve mixed both of them in projects as well. What are the use cases here for each of them?”

or

• “I’ve heard that RxJava is used here. That’s exciting to me, since I’ve been using it on some of my own projects at home. Why was it adopted here?”

Remember, this is your chance to convey your overall love of technology and excitement at the prospect of working for the company.

Ask questions throughout the session

Interviewing sessions are usually short. With any given interviewer, you’ll likely have somewhere between thirty to ninety minutes to make an impression. During this time, the interviewer will, naturally, do most of the question-asking. And of course, you should answer all of the questions directly and fully. Ducking questions and avoiding what they’re asking never comes across well.

But remember, you are also learning about them during that period of time. So after answering a question, consider pivoting to ask them a similar question. For example, if you’re asked about your experience with building microservices, you might end your answer by asking things like, “How did this company get started building microservices?” or “How are you handling errors that occur during event consumption?”

This is an effective way to show that you are interested in what the company is doing, and to tie your interests and experience to what the company needs in a candidate.

Learn something

Most interviewers also want to be sure that you’re willing and able to learn things. This starts with asking good questions, and continues with attentive listening to the answers to those questions. Repeat back to your interviewers what you’ve been told, paraphrased, to show that you’ve understood.

I took an improv comedy class once. Comedians that perform improv sketches (so I was told, anyway) rely on the notion of “Yes, and”. This refers to how the comedians interact with each other. One comedian will start acting out a certain topic. The next comedian will join in and say (figuratively if not literally) “yes, and…” and continue the first comedians line of thought.

While I wouldn’t suggest breaking into comedy during an interview, I highly recommend adopting this mentality. Listen to what your interviewer has to say, demonstrate that you’ve heard them, and then build on what they’ve said.

For example…

Them: “Our company has been deploying ReST services for awhile, but we’ve started running into problems when we need to modify our APIs.”

You: “Yes, it’s easy to run into issues when making API changes to services that are out in production. I’ve found that the ‘expand and contract’ pattern  can help with this…”

In this way, you’ve learned a bit about the company (don’t forget, you’re there to interview them too!), you’ve shown that you’ve listened and learned, and you’ve set yourself up for your next objective…

Teach them something

Most interviewers are also looking for candidates that they themselves, in turn, can learn from. So make it a point to teach something to each of your interviewers.

This can happen as a natural extension of asking intelligent questions. Per the example in the previous question, you might ask your interviewer how its company handles errors during event consumption between microservices. Depending on your interviewer’s answer, you’ve got a pretty good opportunity to tell them how you have solved the problem in the past, and make suggestions as to how they might approach the problem.

Of course, a typical engineering interview session will involve the interviewer asking a technical question, handing you a dry-erase marker, and pointing you to a whiteboard. Often you’ll hear advice that you should keep talking through your solution. This is sound advice. But if you’re focused on merely talking, it’s easy to digress into muttering to yourself.

Instead, picture yourself as the teacher–you are, after all, standing at a whiteboard with a pen and an attentive audience! Talk to your interviewer as if you’re explaining to them how to solve the problem. This shift in attitude will ensure that you’re talking to them, and will help you project a level of confidence and authority.

It’s a different mindset, and takes practice

Thinking of an interview as a conversation that you help steer… well, that takes a while to get used to. But it’s the mindset that will help convey that you’re the engineer that companies not just want–but need–to hire.

Most of us chose software engineering as a career because we love what we do. Few other fields can reliably give us the satisfaction that writing software does. But there comes a time when you as an engineer will need to decide whether you’ll be content with a career as an individual contributor, or whether you want to advance in your role, taking on more responsibilities and more interesting challenges (and, or course, making more money).

If you plan to stick with simply writing code until you retire, then this article is probably not for you. But if you’re reaching the point where you want to expand your career beyond the individual contributor level, then read on.

Face it: you need to market yourself

Many of us (myself included) have become spoiled by today’s job market. Software engineers–even mediocre ones–tend to be in high demand. But the fact is, plenty of companies can still afford to be picky about who they hire, particularly when it comes to technical leadership roles. In order to compete for the best roles at the best companies, we need to make ourselves more valuable. But being more valuable is not not enough. As they say, perception is everything. So we need to do something that most of us aren’t comfortable with: marketing ourselves. In other words, we need not only to be the most valuable, but also to convince our future employers that we are.

Below are some ideas about how to go beyond simply writing code for a living. All of these ideas have two distinct advantages. First, they show the rest of the world that you know what you’re talking about. That you are thoughtful about what you do, and that you can articulate your knowledge. In other words, they make you appear more valuable.

Second, they force you to sharpen your skills. They ensure that you’ve considered different points of view and are still certain that yours is the best. They help you stretch your skills beyond writing code, improving your research and communication skills. Many of them also open the door to networking with folks who are well-entrenched in the industry. In other words, they make you become more valuable.

Writing

Start a blog

You’ve probably already written a lot about programming. Maybe you’ve contributed to your company’s wiki page. Or you’ve replied to questions on StackOverflow. Maybe you’ve written notes to help yourself remember how to solve a particularly vexing issue. Or you’ve written an email to another engineer explaining a particular programming topic.

There is no reason why you can’t apply those same skills and write some articles. For starters, you can create your own blog. There is some overhead to creating a blog, but not much. If you have already have an account with a cloud provider like AWS, then firing up a new instance to host a WordPress site is trivial. Even easier is to simply set up an account with a site like Blogger. Any time you figure out something interesting, blog about it.

You will of course want to spend a bit more time on a publicly-facing article than you would otherwise. Proofread it more carefully. Let it set for a day or two and re-read it to make sure it makes sense, and edit it as necessary. Maybe have a trusted friend or colleague look it over as well.

Once you’ve posted it, you’ll want to market it. Depending on the topic you write about, you may simply get traffic directly from organic online searches. Beyond that, you’ll want to be sure to that you’re linking to your articles from anywhere else that you have an online presence: Twitter, LinkedIn, etc.

Publish articles on other sites

Once you’ve sharpened your writing skills, you can try publishing your articles on existing online engineering publications. You might think that articles on the likes of JavaWorld and DZone are penned by professional writers, but that’s not the case. In fact, most articles on these sites are written by software engineers like you, and most of these publications allow you to submit articles.

Getting an article published in such a publication is a little (but not much) more work than writing for your own blog. For starters, there’s no guarantee that your writing will be accepted. You’ll want to be even more scrupulous with your writing if you choose this route. Different publications will have different guidelines that you’ll need to follow. Some require you to first submit a proposal before even submitting your writing at all. But they provide a large built-in audience, and carry with them a certain amount of prestige.

Another option is to get yourself involved in engineering communities that interest you. Show enough interest and expertise, and you may be invited to contribute. As an example, I became interested in the Vert.x framework, so I began participating in its discussion forums, and occasionally tweeted about it. After one tweet about how quickly my colleague and I were able to use the framework, I was asked by a Zero Turnaround evangelist–who was also active in the Vert.x community–to write an article about my experience.

Write a book

Depending on your area of expertise, and what ideas you might have, writing a book can also be an option. It’s a time-consuming effort, for sure, but one that can pay off in spades in terms of establishing yourself as a subject matter expert. These days, you have a couple of options:

• Sell your idea to a publisher like O’Reilley or Manning
• Self-publish your book

Working with a publisher

Granted, you’ll generally want to start with a novel concept; most publishers will already have authors lined up for How to Program with Java 12, for example. But you’ll be surprised at how easy it is to pitch a niche topic. I was once in a conversation with a publisher from Manning, when he asked me about any topics that I thought would make a good book. As a Java developer who had recently spent time learning Objective-C (this being before Swift came along) I mentioned that Objective-C for Java Developers would have made my life easier. A few days later the publisher contacted me and asked if I’d like to write that book.

While I didn’t wind up writing that book (I did receive a contract from the publisher, but decided to focus my energy on the startup company I’d just joined) in retrospect I often wish that I had. While I’m certain I would’ve made little direct money, I’ve heard from other tech authors about the boosts that they’ve seen in their career. They garner more respect from other people, and in general find it easier to do what they want with their careers, be it getting the job they really want, speaking or publishing more, commanding more money, etc. And along the way, they’ve sharpened their skills and researched their area of expertise far more than they would’ve otherwise.

Working with a publisher has its drawbacks. For example, most publishers have a style in which they want their books written. You’ll work closely with editors, iterating and rewriting. While this will typically result in a much better-written text, it can be time consuming at, at times, frustrating, as you’ll be forced to relinquish much of your creative control to someone else. Typically, while publishers will often offer you a monetary advance as you’re writing your book, you’ll wind up make a small fraction for each book sale.

Self-Publishing

By contrast, it’s become quite easy these days to write and publish your own book. Publishing platforms like LeanPub allow you to focus on writing your book the way you want to write it. They handle the mechanics for you: formatting and publishing, promotion, payments, etc. Most also make it simple to integrate with publishers of physical books (such as Amazon’s CreateSpace). And you’ll be able to keep a much larger percentage of each book sale. Plus, while a publisher can turn your idea down, no one will prevent you from self-publishing.

Of course, when it comes to actually writing the book, you’re on your own. You’ll have no editor guiding you through the writing process (which can be a positive as well as a negative). You’ll be forced to create, and stick with, your own writing schedule (again, this can be a pro or a con). The differences can be summed up like so:

• Guarantee: First and foremost, self-publishing guarantees that you’ll be able to write about what you want to write about. Established publishers might turn you and your idea down.
• Prestige: While both options go a long way towards marketing yourself, there is a certain amount of added prestige when working with an established publisher.
• Control: When self-publishing, you retain control. You write what you want, according to your own schedule. Publishers will insist that you work with an editor, and that you follow their timeline.
• Monetary: Neither option is likely to make you rich–at least, not directly–so this should not be your primary motivation. With that said, self-publishing allows you to keep a higher percentage of books sold, while working with a publisher generally garners you an up-front advance. Also, while a publisher will keep more money per book, they are likely to be able to increase the overall number of books sold.

Speaking

Speaking is another great way to market yourself and hone your skills. If you haven’t done much speaking before, it can be intimidating to just step in front of hundreds of strangers and start talking. However, there are a number of baby steps that you can take.

Speak at your own company

A great way to build speaking skills and confidence is to start with a small, friendly audience. Assuming you work at a company with other people (engineers or otherwise), giving a technical presentation is a great way to get into public speaking. You first question might be What should I talk about? My advice is to pick from one of the following:

1. A topic that no one else in the company knows much about, but is important for people to understand.
2. A topic that other people in the company may be familiar with, but that you in particular excel at

For item #1 above, often you’ll find interesting topics at the at the periphery of programming that have been neglected at your company. Maybe no one knows how to write a good integration test. Or maybe monitoring and tracing might be something your company hasn’t gotten to yet. Take it upon yourself to research and learn the topic, well enough that you can explain it to your colleagues.

For item #2, is there anything for which your colleagues regularly rely on you? This could be anything from git, to specific frameworks, to patterns and best practices. Be sure to outline your talk first. Don’t plan to just wing it. At the same time, don’t fully script your talk. Give yourself permission to ad lib a little bit, and to adjust a bit (say, go deeper into one particular topic, or to pull back on–or even skip entirely–other topics) if you feel that you need to.

Find a meet up to speak at

Engineering meet ups have become extremely common lately. The problem is, lots of engineers want to attend meet ups, but few want to speak. As a result, organizers are often searching for presenters. You can use that to your advantage.

If you haven’t already, find a few good local meet ups to attend (in and of itself, it’s a great way to network and to explore stuff that you don’t typically work with). Get to know the organizers. Then, once you’ve gotten a few talks down at your own company, you can volunteer to present at one of their meet ups. Odds are they’ll be thrilled to take you up on your offer. What should you talk about at a meet up? I’ve been to some great meet ups that have fallen under the following categories:

1. Deep dives into commonly-used technologies
2. Introductions to new/emerging technologies
3. Novel or interesting applications of a given technology

Ordinarily, talks falling under the first category are best given by those most familiar with the technologies. Since they are commonly-used, then almost by definition, the audience will be filled with folks that already know a fair amount about the given technology. For example, I’ve been to a talk about RxJava, given by the team from Netflix that ported the reactiveX framework from .Net to Java. I’ve also attended a talk about Hazelcast… from one of the main Hazelcast developers.

The second category, however, is a different story. If you’ve become familiar with a new technology that has yet to gain widespread use, then you’re uniquely positioned to provide an overview of a technology that few people are using. A year or so ago, for example, I attended an interesting talk about Kotlin given by members of an Android engineering team. The team had no special association with Kotlin itself, other than having adopted the language awhile back. Yet their presentation was well-attended and well-received.

If you’ve made interesting use of a certain technology, then you also have a great opportunity to present. Another interesting talk I’d gone to was given by an engineer whose team had used the Vert.x framework to create a novel in-memory CQRS product.

Conferences

If you’ve attended tech conferences, it can seem as though only engineers who are top in their field are invited to speak. But that’s simply not true. Even more than meet up organizers, conference organizers need to flesh out their conferences with a variety of speakers.

When submitting a conference proposal, however, the topic you plan to discuss becomes very important. While not everyone who speaks is an industry leader, chances are that organizers will be more particular about who presents general topics. Come up with a good niche topic, however, and you’ve got a good chance of being invited to speak. In other words, a talk on What’s new in Spring Framework 6 will likely go to an actual Spring committer. But a talk like, say, Rendering Serverside Graphics Using Websockets and LWJGL, would be open game.

How would you submit a talk? Generally, conferences have a Call For Papers (CFP), which is a period of time in which they are soliciting ideas for sessions. Check the websites of the conferences you want to target for the dates of their CFPs. You’ll find a lot of advice online about how to craft a submission, but common tips include:

• Submit early in the process
• Pay attention to your session’s title and make sure it’s both accurate and enticing
• Don’t pitch a session that attempts to sell a product
• Be sure you thoroughly understand–and follow–the speaker guidelines

Since I just joined a new company as a senior software engineer, I thought I’d write a few posts about my experiences, while they’re still fresh. This particular one is aimed at companies and hiring managers intent on hiring new employees like me. It’s advice, if you will, about how help candidates and new hires feel welcome in the company.

These points may be specific to my particular hiring scenario. But I think they’re general enough–and surprisingly common enough–that they’re worth pointing out. It’s also worth pointing out that there is still plenty that I liked about the company enough to join them (and to continue working there). Still, the whole process had room for improvement, and I figured hey, why not let other people learn from my experience?

Inside jokes during the interview

Try to keep them to a minimum. During the series of onsite interviews I had at this particular company, it seemed that every time my current interviewer ran across a coworker (during tours of the office, say, or when transitioning from one interviewer to another) the two would trade barbs of the “you’re lame” / “no, YOU’RE lame!” variety.

So what’s wrong with a little levity like that? Don’t get me wrong; I’d much rather work with people who have senses of humor, and who like having fun. But sitting in uncomfortable silence during these exchanges, with no real opportunity to join in (have you ever tried to join in on someone else’s inside joke, particularly when you don’t know the people sharing the joke? Don’t.) hardly instilled a sense that this was a team that was welcoming to new members.

Now that I’m a part of the company, I still cringe when I see new interviewees in the office, standing there awkwardly as their interviewer trades barbs with another employee.

In sum: candidates generally feel awkward already, and already know that they’re outsiders. You don’t need to reinforce that point.

Are your new hires people or numbers?

I joined the company as it was experiencing a large amount of growth. For the prior ten years it had remained a fairly small start-up, and only recently had started hiring aggressively. This was a fact which, it seemed, many of the old-timers loved to talk about.

For starters, every departmental meeting began with the observations like “wow, there’s a lot more people here than there were last week!” and “do you guys remember when we used to have our company all-hands in that little conference room?” It’s possible that comments like that were intended to impress upon what a great, exciting time it was to be at the company. But, at least for those of us who couldn’t remember that little conference room, it didn’t feel that way.

Instead, what we heard was that the old-timers were the ones who were the core of the company, the ones that mattered. The rest of us, we were just along for the ride on their coattails. And maybe that’s a valid point. But I know that as an employee, I’m most motivated when I believe, rightly or wrongly, that I’m an integral part of the company.

My new manager also decided that I was going to be the first new hire for which he wouldn’t send out a welcome email about me to the rest of the department. There were getting to be just too many people, he said, for these emails to be sent out. Most employees probably don’t even read them anymore. Well, maybe so. But would the token effort to show that you’re trying to integrate me into the rest of the company been so tough?

In sum: help new employees feel like they’re a part of the company, rather than doing the opposite.