aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristine Dodrill <me@christine.website>2019-06-18 18:50:55 -0400
committerGitHub <noreply@github.com>2019-06-18 18:50:55 -0400
commitcf4bf2bd3ae212c02be6c99524629606f496dffd (patch)
treec938376c09e70db7dbeb79b14c31700d0ab25205
parent28883b78e9f4f348b93c4332738494066a536e36 (diff)
downloadxesite-cf4bf2bd3ae212c02be6c99524629606f496dffd.tar.xz
xesite-cf4bf2bd3ae212c02be6c99524629606f496dffd.zip
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
-rw-r--r--blog/career-advice-2019-06-18.markdown192
-rw-r--r--static/resume/resume.md2
2 files changed, 193 insertions, 1 deletions
diff --git a/blog/career-advice-2019-06-18.markdown b/blog/career-advice-2019-06-18.markdown
new file mode 100644
index 0000000..dc6b89e
--- /dev/null
+++ b/blog/career-advice-2019-06-18.markdown
@@ -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.
+
diff --git a/static/resume/resume.md b/static/resume/resume.md
index 88ff995..bd2eec3 100644
--- a/static/resume/resume.md
+++ b/static/resume/resume.md
@@ -4,7 +4,7 @@
##### Montreal, QC &emsp; [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