Blogs about meta
I recently bought digital subscriptions to some "newspapers" (Seattle Times, NYT, WaPo) because I believe that creators should be paid for their work, that the news media is important in these political times, and because I wanted to move the motivation equation away from "ads and eyeballs". But I'm kinda disappointed at the less-than-premium treatment of paid subscribers by these organizations. Here are some examples of what I do not want:
- Automatically signed up to daily news and marketing emails. No, I don't want more email - that's pretty much the last thing I want.
- Automatically renewed subscriptions. No, I'll pay again next year if I want to
- Repeated modals asking me to sign up for the email newsletter. No! See first item in list
- Terms of service which allow you call me on the telephone. No
- Ads and trackers - no matter if in a website or an app. No - by paying you, I shouldn't have to deal with these. You don't get to monetize me twice
- Paper. I really don't need more material to recycle.
A resume is a marketing document. Its job is to get you a phone screen or interview. During that interview, the resume can guide the conversation. Each bullet point should be able to start a story which demonstrates the specific ways in which you are awesome.
When I was unemployed a number of years ago, I learned a lot about resume writing from books, articles, and especially the career counselor that I saw. Because of this, I've offered to review friends' resumes. After a few rounds of this, I've put together the common pieces of feedback that I've shared:
Instead of listing technical skills, acronyms and tools in bullet points or a keywords section at the bottom of the resume, include that thing within context of a position. This is a much stronger way to demonstrate your abilities. Something like these, for example:
This method also gives you the opportunity to demonstrate what business problem you solved. (A job is all about solving the business' problem.)
- Used Unix shell commands and bash scripts to concatenate complex reporting data
- Developed VB scripts to automate tedious Excel data transformations.
- Always send a .pdf resume. It will be most consistent visually, and a shady recruiter won't be able to swap their own contact information in place of yours like they can on a Word doc. Name the file "Your Name Resume.pdf" so that it's easy for the recruiter to find.
- School, military, and even minimum-wage work can belong on resumes when it demonstrates experience related to the position you're applying for. Be specific about what the school projects encompassed, and if it's really old you can remove the dates. Leadership, troubleshooting and mentoring are always valuable.
- Instead of listing your address, list just the city and state that you're seeking work in. Recruiters might judge your neighborhood and / or commute negatively.
- Your most recent work will tend to be the most important, yet least fleshed out. A good source of material for these can be looking through your annual reviews, or coffee with coworkers.
- Your resume can be one, or more commonly, two pages. Keep it to under two unless you're sure that they're looking for more.
- Always have someone else review your resume for typos.
Let us take a little time to compare and contrast printed products with their online counterparts - such as a printed newspaper and the same newspaper's website.
The printed version is tangible and tactile. Once printed, it can't be revised by the creator, though the user can make notes on the paper. Since it's a tangle product, the user must find a way to dispose of the used product; which may be repurposed as combustion or packing material. Each newspaper will probably only be used by one or two users.
The online version is interactive: searchable and sharable. It is easily updated. The website is much more likely to be seen by users outside of the physical area of the newspaper. Many users will use the same "version" of the paper, which can generate comments and discussions.
These are completely different products, even though they share the same content.
Way back in 2013, I decided that it would be good for my professional development to attend some conferences. I had just started a new job, with some savings left over from unemployment time, and so I had some budget to attend conferences on my own dime. I had met Carter Rabasa (founder and long-time organizer of CascadiaJS) by attending the SeattleJS meetup in the previous year. So I arranged a trip to Vancouver, BC for CascadiaJS in November. On the Hacker Train up from Seattle to Vancouver, I met Tracy Hinds, who had organized the Hacker Train all the way up from Portland.
CascadiaJS 2013 was an absolute blast. The talks were interesting and educational, and I met a bunch of new (and now long-time) conf-friends and even got mistaken for a speaker! I followed new friends on Twitter, and CascadiaJS on Github. Not too long after coming home, I wrote up and posted some of my notes and published them on this blog. I knew I would be ready to do it again in 2014.
And I did. CascadiaJS 2014 was in Portland, and I bought a ticket and lodging nice and early. Beyond being excited about attending, I had even begun to think I might be able to speak. I had even submitted a talk. It was pretty awful, but that's the first step. 2014 was just as wonderful as the last year - I made sure to thank Tracy and Carter (head organizers for that year) personally, since I knew it was a ton of work to organize something so big and so lovely. (Organizing a conference is kinda like organizing a wedding, once a year.) Since I followed the CascadiaJS repo, I was able to observe many parts of the organization process, and contributed some (hopefully!) helpful thoughts for the next year.
So, there you go. I got involved by attending first, providing useful feedback to the organizers, and participating in the community.
A while ago, I interviewed for a job with a company that I was absolutely in-love with. I'd been excited to see that they were looking for a front-end developer and I applied right away.
Back to the interview, we'd gone though a few basic questions and the interviewer had moved on to the algorithm questions. It was a little more complicated than Fizz Buzz, but it wasn't too tricky. But I flailed around for a while trying to both understand what the interviewer was asking, as well as trying to logic out the solution. I didn't solve the algorithm easily enough, and I didn't get any further in the interview process.
Why evaluate a front-end developer based on a algorithm? It's such a very small part of the job, and especially over a video conference after a full day of work, and it's the wrong test to get the front-end developer to demonstrate their best. It's like evaluating an NFL kicker based on their tackling skills - sure, they need to do it sometimes, but a proper blocker will always be more skilled at tackles.
More blogs about meta: