Blogpost on career advice/interview advice (#56)
* blog: add post on career starting/nurturing advice * update resume * Update career-starting-advice-2019-06-18.markdown * Rename career-starting-advice-2019-06-18.markdown to career-advice-2019-06-18.markdown * spelling error
This commit is contained in:
GitHub
parent
28883b78e9
commit
cf4bf2bd3a
|
|
@ -0,0 +1,192 @@
|
|||
---
|
||||
title: Advice to People Nurturing a Career in Computering
|
||||
date: 2019-06-18
|
||||
---
|
||||
|
||||
# Advice to People Nurturing a Career in Computering
|
||||
|
||||
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 at 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.
|
||||
|
||||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
##### Montreal, QC   [christine.website][homepage]
|
||||
|
||||
`Docker`, `Git`, `Go`, `C`, `CentOS`, `CoreOS`, `IRC`, `Stenography`, `DevOps`, `Heroku`, `Continuous Integration/Delivery`, `Event Sourcing`, `WebAssembly`, `Lua`, `Haskell`, `Nim`, `Python`, `Java`, `Rust`, `Javascript`, `Gherkin`, `Mindfulness`, `Lojban`, `HTTP/2`, `Rails`, `Ruby`, `Sinatra`, `Alpine Linux`, `Ubuntu`, `Debian`, `Linux`, `Dart`, `Flutter`, `TCL`, `Emacs Lisp`, `MoonScript`, `RPM`, `Node.js`, `npm`, `GraphViz`, `Progressive Web Apps`, `yaml`, `SQL`, `Postgres`, `MySQL`, `SQLite`, `Ordained Minister`, `Dudeism`, `Tech Writing`
|
||||
`Docker`, `Git`, `Go`, `C`, `Stenography`, `DevOps`, `Heroku`, `Continuous Integration/Delivery`, `WebAssembly`, `Lua`, `Mindfulness`, `HTTP/2`, `Alpine Linux`, `Ubuntu`, `Linux`, `GraphViz`, `Progressive Web Apps`, `yaml`, `SQL`, `Postgres`, `MySQL`, `SQLite`, `Ordained Minister`, `Dudeism`, `Tech Writing`
|
||||
|
||||
## Experience
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue