If you’ve ever had a conversation about tech, software, hiring, retention, diversity, being a junior, supporting juniors, etc. etc. there’s a 95% chance that I’ve told you to go on Twitter and follow Sarah Mei immediately. Hey, you! Reader! Go follow Sarah Mei on Twitter immediately!

The reason is because she has some of the most accurate and concrete ideas for how to make life better for junior developers, particularly women and people who aren’t traditionally encouraged to enter tech. Through Sarah, I recently came across Lydia Guarino’s latest series of tweets about where junior devs fit.

It’s geared toward bootcamp grads, but most of the advice in there is generally applicable to anyone who is searching for their first job. This, in particular:

Passion and curiosity do not translate well in resume format. Passion and curiosity are the top traits you have to offer as a junior dev.

Full disclosure, I am not a hiring manager. I don’t get to make important decisions about hiring or recruitment. But, I have had many, many conversations with people who are trying to get into tech. It was obvious to me after exchanging many emails, pair-programming with them, and spending some time getting to know them that they are really excited about programming, and they’d be an asset to any dev team that was lucky enough to snag them.

Sadly, that’s not really how most technical interviews work. You get a few phone calls, maybe a pairing exercise, and some in-person interviews if you progress past the first few stages. Most people never become more than words on paper, in the eyes of the hiring manager.

So, how can aspiring junior devs convince someone on the other side that they really are as passionate as they say?

Don’t let an email be your first point of contact with a company that you want to work for

Loads of companies in London are involved with at least one community. Usually, that community is related in some way to the tech that they use – if you apply there, you’ll probably need to learn something about that tech stack anyway for the technical interview. Find out what those events and meetups are, go to them, and have at least one face-to-face conversation with a developer who works there. Basically, do some light stalking… 😅

Here’s a short list off the top of my head of companies that I know to sponsor cool meetups:

• Ruby Hack Night: Yammer
• Clojure Dojo: uSwitch, Thoughtworks
• Front End London: Made By Many
• London PaaS User Group: Pivotal
• London Software Craftsmanship Community: Pivotal, TIM Group, Codurance
• Node Girls: Stack Overflow
• Extreme Programmers London: Unruly
• 8th Light University: 8th Light 😁
• Women Who Code: Expedia, Twitter, Google, and loads more
• Ladies Of Code: Twitter, Founders & Coders

And for some shameless self-promotion…

• codebar: Shutl, Pivotal, Thoughtworks, CompareTheMarket, LostMyName, Twitter, eBay, Paypal, M&S Digital, Deliveroo, Cloudflare, New Bamboo/Thoughtbot, and loads more

If that company doesn’t host meetups, the next best thing you can do is to try to put yourself in the same room as them by going to conferences. Look up conferences related to the stack they use, and see if they’re sponsoring. Even if you just say hello and introduce yourself, the people who go to conferences are likely the same people who are excited about their work and their company. They’re great evangelists, and if they remember you in a positive light, they’ll be your strongest advocates.

So, what might a “memorable conversation” look like?

Have strong opinions, even if they’re “wrong”

The vim-vs-emacs debate is so old that it’s basically a trope in tech communities now. I think the reason that it’s such a popular debate is because nobody actually cares that much – but it’s fun to have a high-spirited debate with no stakes.

You don’t need to have a opinion on the text editor holy wars (but honestly, many people would probably be tickled if you do have one). Instead, think about the technical things that matter to you as a software developer. Do you care about…

• creating beautiful user interfaces?
• writing clean, readable code?
• finding the most efficient way to solve problems?
• building small, modularised classes?
• adhering religiously to the SOLID principles?
• test-driving all your code?
• your build tools?
• functional purity?
• test frameworks – RSpec vs Minitest?
• your favourite web framework? Do you like out-of-the-box solutions like Rails/Django/Ember, or do you prefer to roll your own apps in Cuba/Sinatra/Flask/Hapi/etc.?

I’ll give an example. I once had a conversation with a friend who is an experienced developer, and somehow, the topic of RSpec came up. I remember saying something along the lines of, “I think everyone should have to learn to test-drive their code. With RSpec. And in Ruby. Because the quality of the error messages and the feedback loops you can get from RSpec are so good, they’re a teaching tool in themselves.”

He responded, “I would hire you. You have strong opinions. I find that people, especially juniors, who can defend their own opinions turn out to be good developers.”

The short-term reason is that hiring a junior who goes along with whatever the senior devs say is basically the same thing as getting a puppy that unconditionally loves everyone and whatever they say. Which is awesome, but puppies don’t challenge assumptions, raise concerns, and push back against business requirements, when the quality and/or feasibility of a project is compromised. The established dynamics of a team sometimes require someone new to do that.

It took me a while to work past my fear of stating a “wrong” opinion. I like lots of things that other people don’t like, and occasionally mock outright. I like jQuery, for example 😉 The thing is, particularly with JavaScript libraries, there is basically no consensus on anything. Even if you’re the only person in a group who likes jQuery, as long as you can speak to a positive experience you’ve had, it’s better to have some opinion than to stand there silently, nodding along. In fact, the detractors will probably teach you some new things about your favorite (or least favorite) framework – this is lost if there’s no debate.

Of course, be open to having your mind changed – you’re networking, not running for the Republican presidential nomination. On that note…

Don’t think of it as “networking”

I’m pretty sure that I am allergic to the word “networking”. It takes a lot these days to get me to go to something branded as a networking event. I don’t like it because it makes conversations feel so… transactional.

So, if you’re like me, it’s totally OK to avoid “networking” events altogether and just go to events that you think are cool and interesting. Think about it instead as making new friends and acquaintances. You might hit them up for a job one day, you might not. But if you meet someone that you connect with, you should still invest in that relationship.

Follow the people you meet on Twitter, interact them once in a while, email/text/tweet them when you discover a really awesome event or conference that they should go to, and make a point of staying in touch, even if you’re not actively looking for a new role. Some companies have “always hiring” policies, so that exceptional candidates don’t get passed up. If you’re excited about working for a company, even if it’s not right now, you should equally have an “always inquiring” mindset.

Start contributing to open source and mentoring other people who are still learning

Community involvement is really important. If you do nothing else, do this, because your actions speak so, so much louder than your words (and your CV). If you’re uncomfortable sending pull requests to strangers, then find a local community and start mentoring. If you’ve been programming for one month, there is something you can teach to someone who has been programming for one week. It will solidify your knowledge and help you to become more technically prepared.

And frankly, this is one of the best things you can talk about in an interview. You are untested, with no reputation (yet) – there are very few heuristics to go on. But the person interviewing you will likely have heard of at least one of Code Club, Code Dojo, Code Newbies, Railsbridge, Clojurebridge, Node Girls, Rails Girls, Django Girls, codebar, etc etc. All of our brains take shortcuts when it comes to complicated tasks like assessing whether someone would be a good hire, so give yourself the best odds to let the interviewer make some mental shortcuts that portray you positively.

And if it doesn’t work? Well, if I mention open source and community involvement in an interview and there is no reaction or negative reaction from the interviewers, then that’s not a company that I want to work for. All modern software is made standing on the shoulders of giants and with heavy reliance on open source and the communities that raise all the boats with the tide.

In my opinion, there’s no better way to “prove” that you are passionate about something. People don’t give up their free time to teach and mentor other people, unless they care about the subject matter, the community, or both. In either case, that’s a junior developer that I want on my team.