The things you don't know

When you start a career in a new field, you see the immensity of it. Let me tell you straight away: the more you learn, the greater the things you know you don't know are.

There are three categories like this one:

• The things you know you know:
  • This one grows in parallel with what you learn. It's the concepts you understand, the techniques you find; one could argue that this is the experience that you have.
• The things you know you don't know:
  • In my opinion, this is the one that grows the most with experience. It makes you know how to formulate a complex concept; how to look for it and how to solve it.
• The things you don't know you don't know:
  • This is the most dangerous one. This is the difference between being able to write complex software or re-writing everything every once in awhile because you misjudged a key concept/feature.

When I started in Software Engineering, I was obsessed with the first category. I was sure that being a good developer meant knowing all the things.

~5 years down the road, it appears that I was wrong. Being focused on the first category means that you just see what you know compared to everything else, and it can be scary at times, especially if you start by yourself. This poster on Stack Exchange must be in this situation:

I'm trying to improve my knowledge by studying algorithms, but it is a long and painful process. I find algorithms difficult and at the rate I am learning a decade will have passed before I will master the material in the book.

Yep. And that's ok. Being a programmer, as any other trade I guess, it's not about mastering the field from day one.

How to kick start your career:

The IT team at Drawbotics has been involved in the belgian Ruby community for a few months now, through the Ruby Belgium association, working toward helping motivated newcomers.
We met freshly out-of-school young women and men, who wanted to gain this analytical and technical approach. We've seen people with more experience in other fields, looking for a career shift, or just wanting to know how thing are happening behind the curtain.
We answered technical questions, but gave a lot of personal advice on the side as well. Since rely on our experience for technical advice, we do the same when the question was asked "How did you become a developer?"

Our answers in the IT team are numerous.
One thing remains and we base our recruitment on it: You've got to build things

Our job offers to join the team are for Frontend Engineers & Software Engineers. We don't mean engineer as the degree on your diploma, we mean it as a way of thinking and a way of working. We like to solve problems, and we expect our future team members to share this state of mind.

This is why our recruitment process is project based. We hire without whiteboard because it's not representative of the position (though Sandjiv has been spending extensive amounts of time in front of a whiteboard to solve architecture issues, but that's another story 😉). What we do here is solve puzzles. We find smart and lasting solutions to problems, we build features and implement them in our architecture, trying to be efficient on the way. We engineer the future of the tools on which the company relies on more and more. So we ask you to show us that you can do it, or learn it if you're applying for an internship position.

What to build?

How we proceed is simple: we look for things you built, and at the problem you solved.
My personal preference goes toward real world problems that you might have encountered, the famous "Scratching your own itch." It means that you have at least one "client": yourself.

But it doesn't stop there. If you don't know what to build, just pick the first service you use daily. Would it be Twitter, Reddit or something else. Choose the features you want to implement, and implement them, nothing more. Remember that the important thing is to release the app, not falling into the how to never complete anything pit. The advantage of building such services is the extent of potential features you get. You can think of twitter as a simple app, but it gets interesting when you start to implement the "View X new tweets" feature, basically enabling web sockets from your server to your client.

What's next?

Then, once you have something to show off, you apply. And with perseverance and hard work, you'll get the job. I'm not saying it's easy, far from that. What I'm saying is that it is accessible.

Personal insight on targeting a company:

One last piece of advice, make sure to target companies where mentoring juniors and interns is key in the process. This is the difference between a great learning curve and a lot of solitude of smart coping/pasting.
Here at Drawbotics, we try to match every intern or junior with a more senior person. It could mean that an intern is matched with a junior who in turn is matched to a senior. That way, everyone is learning how to ask, and also how to answer questions.
It's a win-win-win.

First and foremost, keep pushing. Never feel undermined by the amount of things you don't know, remember these as your next to-do list: Check those boxes, one after the other.