This is a guest post from Matt Schellhas. Enjoy.
Dear new developer,
I personally look for some of the same things as my peers:
- Is your resume/LinkedIn fine? It doesn’t need to be awesome. You don’t have a ton of experience to show, so please don’t try and oversell your experience — that just makes it clear that you don’t know how much you don’t know. Just avoid typos, unprofessionalism, messiness. No unforced errors.
- What languages do you know? A computer science degree is great, but most of your competition has CS degrees. What do you actually know? How did you learn it? What can we ask about in an interview? If it’s unclear what you know, we’re liable to assume that you don’t know anything (since we get some of those candidates too).
- Can you write code? It’s all well and good to show promise and to know your algorithms & data structures. But if you can’t write code, I won’t hire you to write code. Portfolios are okay, though they are so common now that they’re not a good signal. Your github is okay, but unless it’s very clear that you didn’t just follow a tutorial, that isn’t good signal either. Plus github and portfolios push this whole idea that “you need to code in your spare time to be good”, which favors the privileged folks with ample spare time/energy. So I check for this in the interview. Can you write some loops without StackOverflow? Do you actually know the basics of your best programming language? Nothing complex, but it still excludes a lot of beginners (and non-beginners).
There’s also some things that I look for that aren’t very common. I do this because in my experience, these things correlate well with your success as a professional software engineer. Other hiring managers have different experiences, so have different beliefs. All the more reason to apply to a wide variety of roles.
First, some things that I don’t look for that somehow end up on resumes and in interviews anyways:
- I do not care if you are a “fast learner”. Everyone puts this on their resume, regardless of its truthfulness. Remember that you’re no longer competing against the best students in your school. You’re competing against the best students in every school. Depending on the role, you might be competing against the best students from every school over the past forty years. I don’t mean to dissuade you, but to remind you that I get a lot of applicants who learn quickly and even more who say they do. If you really are a fast learner, show me what you’ve learned. Show me how well you’ve learned it.
- I do not hire “hard workers”. I get a lot of applicants that focus on how hard they’re willing to work. They talk about the extra hours they put in during their internship or at a summer job. Your ability to tolerate suffering is not the appealing trait you think it is. As a manager, you’re telling me that you will set a bad example for others, probably have poor time management skills, and will maybe burnout when faced with adversity. Don’t do it. Focus on dependability, or reliability, or willingness to adapt. Show me that you’re interested in being a good teammate.
- I do not care how passionate you are about programming or my company or the industry we’re in. Look, a good portion of your job is not going to be writing code. I’ll do my damnedest to make writing code a big portion of the job, but there will be meetings. There will be debugging. There will be testing. There will be a lot of talking to people. There will be bureaucracy and other stuff that isn’t very fun. The code you write as an entry level engineer is probably not going to make a huge impact for our customers or for the world. It is still a job. In my experience, that passion doesn’t last. You need to show me that you can find enough motivation or pride or professionalism to sustainably do all of the job, not just the parts you are passionate about.
But there are also two things I look for because they correlate well with software engineers’ success (at all levels):
- Signs of self-awareness. As a software engineer, most of your day is going to be alone — particularly now that distributed work is more common. Your lead is not going to spend hours a day with you. Your manager is not going to spend hours a day with you. Your peers are probably not going to be great at providing you feedback or coaching. Maybe your lead and your manager will be bad at it too. A little bit of self-awareness and introspection will go a long way in helping you grow as a professional. It makes my job easier because you already know some of the things we’re going to talk about. Self-awareness is a fundamental dependency for building a good, sustainable work ethic since you’re aware enough to know at least a little about what motivates you and what “too much” feels like. And it’s something that you don’t need any professional experience to exhibit.
- Understanding of implications. This is the big one. More than any other skill or trait or strength I’ve encountered, the ability to follow implications is what best correlates with software engineering success. Does this candidate understand that “if a then b”? It’s even more important for beginners, since it is nigh impossible to teach. And it is an essential skill for software engineering. All of the tradeoffs for program design require programmers to understand the implications of those tradeoffs. What the consequences are will come with experience, but you won’t get that if you can’t see how a tradeoff leads to various effects. Debugging becomes drastically harder when you don’t understand what could lead to the symptoms you’re seeing. Making code changes is far more dangerous when you can’t imagine what sort of implications this change has on the wider system. Writing quality code is unlikely to happen when your brain can’t easily understand how that code impacts customers who will use it and programmers that will maintain it. This is why “show the impact of your work” is part of the common advice for more experienced engineer resumes. At any level, I look for it in interviews. Do you understand the consequences of a design? Can you accurately understand the implications of a tradeoff? As a new grad, it doesn’t need to be great! I don’t expect that you’ll understand all of the nuances involved. I don’t expect that it’ll be lightning fast, or even that your inferences are accurate. Those will come with time. Those we can teach.
— Matt
This post was originally published here.
Matt Schellhas is top notch software engineer with experience leading teams. He is currently a senior software engineering manager at Pex.
Letters To A New Developer 