Computering, or making computers do things in exchange for money, can be a surprisingly hard field to break into as an outsider. There's lots of jargon, tool holy wars, flamewars about the "right" way to do things and a whole host of overhead that can make it feel difficult or impossible when starting from scratch. I'm a college dropout, I know what it's like to be turned down over and over because of the lack of that blessed square paper. In this post I hope to give some general advice based on what has and hasn't worked for me over the years.
Hopefully this can help you too.
When you are breaking into the industry, there is a huge initial "brand" issue. You're nobody. This is both a very good thing and a very bad thing. It's a very good thing because you have a clean slate to start from. It's also a very bad thing because you have nothing to refer to yourself with.
Part of establishing a brand for yourself in this day and age is to make a website
(like the one you are probably reading this off of right now). This website can
be powered by anything. GitHub Pages with the
domain works, but it's probably a better idea to make your website backend from scratch.
Your website should include at least the following things:
If you feel comfortable doing so, I'd also suggest putting your resume on this site too. Even if it's just got your foodservice jobs or education history (including your high school diploma if need be).
This website can then be used as a landing page for other things in the future too. It's your space on the internet. You get to decide what's up there or not.
This has been the single biggest thing to help me grow professionally. I regularly put articles on my blog, sometimes not even about technology topics. Even if you are writing about your take on something people have already written about, it's still good practice. Your early posts are going to be rough. It's normal to not be an expert when starting out in a new skill.
This helps you stand out in the interview process. I've actually managed to skip interviews with companies purely because of the contents of my blog. One of them had the interviewer almost word for word say the following:
I've read your blog, you don't need to prove technical understanding to me.
It was one of the most awestruck feelings I've ever had in the hiring process.
Starting out you are going to not be very skilled in anything. One good way you can help yourself get good at things is to go out into communities and ask for help understanding things. As you get involved in communities, naturally you will end up finding people who are giving a lot of advice about things. Don't be afraid to ask people for more details.
Get involved in niche communities (like unpopular Linux distros) and help them out, even if it's just doing spellcheck over the documentation. This kind of stuff really makes you stand out and people will remember it.
Formal mentorship is a very hard thing to try and define. It's probably better to surround yourself with experts in various niche topics rather than looking for that one magic mentor. Mentorship can be a very time consuming thing on the expert's side. Be thankful for what you can get and try and give back by helping other people too.
Seriously though, don't be afraid to email or DM people for more information about topics that don't make sense in group chats. I have found that people really appreciate that kind of stuff, even if they don't immediately have the time to respond in detail.
Repository hosting sites like GitHub and Gitlab allow you to show potential employers exactly what you can do by example. Put your code up on them, even if you think it's "bad" or the solution could have been implemented better by someone more technically skilled. The best way to get experience in this industry is by doing. The best way to do things is to just do them and then let other people see the results.
Your first programs will be inelegant, but that's okay.
Your first repositories will be bloated or inefficient, but that's okay.
Nobody expects perfection out of the gate, and honestly even for skilled experts perfection is probably too high of a bar. We're human. We make mistakes. Our job is to turn the results of these mistakes into the products and services that people rely on.
Many companies put job requirements as soft guidelines, not hard ones. It's easy to see requirements for jobs like this:
Applicants must have:
- 1 year managing a distributed Flopnax system
- Experience using Rilkef across multiple regions
- Ropjar, HTML/CSS
and feel really disheartened. That "must" there seldom actually is a hard requirement. Many companies will be willing to hire someone for a junior level. You can learn the skills you miss as a natural part of doing your job. There's support structures at nearly every company for things like this. You don't need to be perfect out of the gate.
This one is a bit of a weird one to give advice for. Each company ends up having their own interviewing style, and even then individual interviewers have their own views on how to do it. My advice here is trying to be as generic as possible.
If you say you know how to use a language, brush up on that language. If you say you know how to use a tool, be able to explain that what that tool does and why people should care about it to someone.
Don't misrepresent your skills on your resume either. It's similar to lying. It's also a good idea to go back and prune out skills you don't feel as fresh with over time.
It's tempting to put on a persona or try to present yourself as larger than life. Resist this temptation. They want to see you, not a caricature of yourself. It's scary to do interviews at times. It feels like you are being judged. It's not personal. Everything in interviews is aimed at making the best decision for the company.
Also, don't be afraid to say you don't know things. You don't need to have API documentation memorized. They aren't looking for that. API documentation will be available to you while you write code at your job. Interviews are usually there to help the interviewer verify that you know how to break larger problems into more understandable chunks. Ask questions. Ensure you understand what they are and are not asking you. Nearly every interview that I've had that's resulted in a job offer has had me ask questions about what they are asking.
A few things I've found work really well for this:
And then finally as your last question:
This question in particular tends to signal interest in the person interviewing you. I don't completely understand why, but it seems to be one of the most useful questions to ask; especially with initial interviews with hiring managers or human resources.
Even if it's just watching your breath for 5 minutes. I find that doing this helps reset the mind and reduces subjective experiences of anxiety.
Getting the first few real jobs is tough, but after you get a year or two at any employer things get a lot easier. Your first job is going to give you a lot of experience. You are going to learn things about things you didn't even think would be possible to learn about. People, processes and the like are going to surprise or shock you.
At the end of the day though, it's just a job. It's impermanent. You might not fit in. You might have to find another. Don't panic about it, even though it's really, really tempting to. You can always find another job.
I hope this is able to help. Thanks for reading this and be well.
This article was posted on M06 18 2019. Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.
This post was not WebMentioned yet. You could be the first!
The art for Mara was drawn by Selicre.
The art for Cadey was drawn by ArtZora Studios.