Over the last several years as we’ve taught and developed new software engineers, we’ve met with dozens of software engineering leaders from across the world. From large international tech corporations in Israel, small tech startups in Austin or Durham, Google, IBM, you name it, we’ve met them and asked them the same question:
“What are you looking for when you hire new software engineers?”
Astonishingly, all of these VP’s of Engineering and CTO’s share a common answer because they share a common problem. They have a hard time finding and retaining top tech talent, but perhaps not in the way you might think. Sure, everyone is looking for an experienced developer that can be a leader and increase their company’s productivity, but there’s something deeper they’re looking for that is actually more difficult to find.
Last year I asked this question to On Freud, WeWork’s VP of Engineering in Israel. If you didn’t know, WeWork is currently valued at $20 billion, and though they primarily operate in physical spaces, their tech platform is quite robust as it manages over 120,000 companies across its 156 offices worldwide.
WeWork’s founder and CEO, Adam Neumann, told us that their engineering department has no budget. The department is allowed to hire any time they find talented developers regardless of the company’s openings.
In our conversation, On went on to explain that despite having the prowess of WeWork’s budget and it’s expanse across New York and Tel Aviv to find top talent, it’s not the actual talent or experience of the developers themselves that he’s most attracted to. In fact, when we spoke last year, he had never fired a junior developer (less experienced engineers) because the juniors that he hires encompass seemingly unteachable behaviors that go beyond experience and knowledge.
For new developers without a Computer Science degree, like you, this is good news! It means that the following behaviors are more important for obtaining a job than any experience, degree or education you might receive. However, these behaviors are difficult to obtain as they require you to be passionate, authentic and humble. Let’s look and think about how we might adopt these behaviors.
This is the one I’ve heard far and above any other - engineering managers want to hire passionate, hungry and curious developers. You’re not satisfied with, “it works”, but you want to dig deeper behind the code and know why it works. Being curious means you feed off the “aha!” moments - you actually enjoy the process of learning and you’re confident that your search (when you have an issue) could result in a unique discovery.
To adopt curiosity, you need to take on a child-like spirit of asking “why” all the time. Not just of code, but of everything. Figure out what makes people, governments, ideologies, infrastructures, and the lawn mower, tick. Embody this, and you’ll be well on your way to set yourself apart as you learn to code.
This piggy-backs really well with the first characteristic. It’s only natural for us to fear failure, especially at this stage. Our confidence as beginners is very fragile and we’re constantly dealing with “imposter syndrome”. One failure could set us spiraling into doubt about this whole coding thing. Not only that, but we’re also fearful to admit just how much we don’t know, even to ourselves.
However, ironically, this is where the real learning happens - on the frontier of curiosity and failure. But what’s the worst that could happen? You break your project? You waste a couple of hours? Not even that, because even if you don’t “figure it out”, surely you’ll learn something. All that to say, there is no logical reason to fear trying new things at this stage. You have nothing to lose and everything to gain. Go for it, dive in, and discover something new.
Perhaps the most consistent advice I received as an engineer from the VP of Engineering at a company I worked for was to take ownership of what I was building. This was really scary to me as a brand-new engineer working in a company with 20 of the city’s best software engineers - yet the VP of Engineering (who was also the co-founder) was urging me to own my code - to write it with confidence in such a way that it could stand side-by-side with the “big- dog” senior engineers. I even had to write my code in such a way that someday those “big-dog” seniors could add to it and make it their own too. When things get tough, remember to be fearless. Everyone has been at this stage before and mistakes are inevitable, but it’s where you learn and grow and everyone knows that.
Developing software projects can be an emotional roller coaster. Have you ever heard the saying “20% of the project takes 80% of the time”? Inevitably you will have an experience where you start a project and knock out 80% of your perceived workload ahead of schedule and in the end, you will run behind because something else ends up taking longer than planned. This is just one example of the emotional roller-coaster.
So this is going to happen, but how are you going to handle it? What will you do in the face of failure? When you need to refactor your code so much that you need to scrap something that took you hours to build, what will do you? Great programmers learn from it and move on. Go for a walk, drink some coffee and get back on the horse.
Lastly, we’ll leave you with a quote from YCombinator founder, Paul Graham:
"Can you cultivate these qualities? I don't know. But you can at least not
repress them. So here is my best shot at a recipe. If it is possible to make yourself into a great hacker, the way to do it may be to make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you'll never allow yourself to do a half-assed job. All the great hackers I know seem to have made that deal, though perhaps none of them had any choice i n the matter."