193 lines
8.9 KiB
Markdown
193 lines
8.9 KiB
Markdown
---
|
|
title: Advice to People Nurturing a Career in Computering
|
|
date: 2019-06-18
|
|
tags:
|
|
- career
|
|
---
|
|
|
|
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.
|
|
|
|
## Make a Portfolio Site
|
|
|
|
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](https://pages.github.com) with the `github.io`
|
|
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:
|
|
|
|
- Your name
|
|
- A few buzzwords relating to the kind of thing you'd like to do with computers (example: I have myself listed as a "Backend Services and Devops Specialist" which sounds really impressive yet doesn't really mean much of anything)
|
|
- Tools or soft skills you are experienced with
|
|
- Links to yourself on other social media platforms (GitHub, Twitter, LinkedIn, etc.)
|
|
- Links to or words about projects of yours that you are proud of
|
|
- Some contact information (an email address is a good idea too)
|
|
|
|
If you feel comfortable doing so, I'd also suggest putting your [resume](https://christine.website/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.
|
|
|
|
## Make a Tech Blog On That Site
|
|
|
|
This has been the single biggest thing to help me grow professionally. I regularly
|
|
put [articles](https://christine.website/blog) 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.
|
|
|
|
## Find People to Mentor You
|
|
|
|
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.
|
|
|
|
## Do Stuff with Computers, Post the Results Somewhere
|
|
|
|
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.
|
|
|
|
## You Don't Need 100% Of The Job Requirements
|
|
|
|
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.
|
|
|
|
## Interviews
|
|
|
|
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.
|
|
|
|
### Know the Things You Have Listed on Your Resume
|
|
|
|
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.
|
|
|
|
### Be Yourself
|
|
|
|
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.
|
|
|
|
### "Do You Have Any Questions?"
|
|
|
|
A few things I've found work really well for this:
|
|
|
|
- "Do you know of anyone who left this company and then came back?"
|
|
- "What is your favorite part of your workday?"
|
|
- "What is your least favorite part of your workday?"
|
|
- "Do postmortems have formal blame as a part of the process?"
|
|
- "Does code get reviewed before it ships into production?"
|
|
- "Are there any employee run interest groups for things like mindfulness?"
|
|
|
|
And then finally as your last question:
|
|
|
|
- "What are the next steps?"
|
|
|
|
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.
|
|
|
|
### Meditate Before Interviews
|
|
|
|
Even if it's just [watching your breath for 5 minutes](https://when-then-zen.christine.website/meditation/anapana).
|
|
I find that doing this helps reset the mind and reduces subjective experiences of
|
|
anxiety.
|
|
|
|
## Persistence
|
|
|
|
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.
|
|
|