Trigger Checklists!

I love checklists. I have a terrible memory, so it’s very easy for me to forget all the things I need to do. If I go to the store without a list of things to buy, I will forget at least one. Or two. Or I’ll get the wrong type.

I do the same thing with software. If I don’t have something reminding me, I’ll forget to check all the getters I’m using to see if they sometimes return NULL. I’ll forget to check that my new member variables have been added to all the initialization list, the comparators, AND the hash function. So this is why I love checklists: because they remind me. They help me catch the simple errors that I can catch easily if only I pay attention. And they give me some degree of assurance, the third time I should have asked how a function should behave on empty inputs, that I’m not going to make the same mistake again any time soon, because I’ve added it to my checklist. I review my checklists regularly to remove extraneous or not-effective parts and keep them a reasonable size (less than a dozen items), and in general, the upkeep of the lists is no problem.

My problem with checklists is that I often don’t remember to use them.

I’m not alone; we started using a code review checklist a few iterations into our practicum project, but we kept running into very same the issues it advised us to check. It wasn’t until we decided that the reviewer should have a printed copy of the checklist with them and check off each item whenever they did a code review that we started to see its benefit. Our original problem was that we had never decided when to use it.

This same problem is what has been affecting my personal review checklists. I realized: It’s just as important to describe when to use the checklist as to describe what things to check.

The obvious extrapolation for my personal reviews is to say, “use the code review checklist before compiling or submitting,” but I realized that I could get feedback much more quickly by breaking up my list into smaller, easier to apply pieces. I call them trigger checklists. Here’s one of mine:

Are you adding a method?

  • What if the inputs (or even class members) are null?
  • Can the method be const? Can the inputs be const?
  • Is there a JavaDoc style comment?
  • If the method is used in another toolkit, is it exported?

So far, this has been great. I have my trigger checklists on a sheet of paper next to my monitors, so I’ll glance at it fairly often in a day. If I’m in the middle of doing one of the things that trigger a checklist, I’ll go through and check each item to make sure I’ve covered my bases, or add TODOs to help me remember to check specific things later.

"Soon, our missiles will launch and the world leaders will - wait..." *checks a list titled, "Revealing your secret plan to an enemy? Are they dead? are you sure? etc... "Haha! Good try, good try.

PS: I went on a search online to find some good checklists to link from here, but there aren’t many, possibly because each checklist is so tied to the team, domain, language, and libraries. Macadmian has one which is good, if long and for team code reviews (I suspect that team checklists will often be longer than personal ones). If you have a copy of A Discipline for Software Engineering, Humphrey’s C++ checklist for PSP is also good (it’s on page 242).

Thanks to Geoff Geisel for looking over a draft of this and for his feedback. Geoff was part of our practicum project.

Posted in The Craft | Tagged , , , | Comments closed

Lessons from the Job Hunt (part 2 of 2)

In the first part, I wrote about resumes and the seeming randomness of the job search. In reviewing it, Raúl summarized that random element well: “sometimes it’s because the hiring process is obscure and sometimes it’s because there is just a lot of random gateways in the process, like what impression the interviewer got of you as a person, if it was a good week for the office, if they were looking for a person of your expertise at that time, etc.”

This part is about organization, interviewing, and choosing a job. I’m leaving out significant portions here as well, from negotiations and benefits to issues for international students.

Keeping thyself organized

I’m in a hotel in South Carolina, in my socks at one of the computers in the “Business Center.” I have an interview the next day, I have one recruiter asking for references and another asking me to re-send my resume, but I’m miles away from my computer and all my stuff at home.

Luckily, I kept all my job search materials on a private online website.

When I started, I anticipated using a website to make it easier to switch between my own computers, but as I found myself more and more on the road, it was the ability to work at any computer which saved me and kept me on top of things. That night in South Carolina, I printed off a few copies of my page of questions and reviewed my file on the company, reminding myself of the things I had read or talked to them about which really interested me and the people I had talked to there. I copy-pasted my references’ contact info and e-mailed them to the first recruiter, then e-mailed each of my references telling them to expect a call and briefing them on some of the companies which would be calling. I downloaded the latest version of my resume and attached it to an e-mail for the last recruiter, along with some of the times I would be available in the next week to talk. The website helped me when I wanted to print out some copies of cover letters to get feedback, and to keep track of job boards and with companies I had sent something to. And of course, it helped me keep track of my progress: on the sidebar was a counter for days since graduation, resumes sent out, interviews, and offers.

[Comic] INTERVIEWER: As you can see, we have quite a file on you. APPLICANT: Um. Ditto.

Honestly, it is about fit

When you’re in a phone interview answering questions about what inheritance is or how you would write a function to reverse a string, the confusion between job hunt and final exam is more understandable. It feels very adversarial: you want to go on to the next step of the process, and they want to stop you if they can. But thinking of it as a win-lose situation distorts the situation. In truth, it’s collaborative, and you are both looking for a win – they want to hire you if you’re a good candidate, and you want to work for them if they’re a good place to be.

There is no standard way of knowing whether you’re a good candidate – each company has their own requirements. There’s no standard way of knowing what is a good place to be – each person has their own ideal company and priorities. But seeing it this way does two things. First, you don’t feel so bad when you don’t make it past a screen – it’s not a good fit. Second, you start paying attention to things you like and red flags from the company earlier. Let me illustrate:

I got a call back from Company A a week after I sent them my resume. The interview included standard background chatting and then three programming questions. I did fine on two of them, but I struggled with the third, which depended on a part of computer architecture which I had forgotten. I looked it up after the interview and sure enough, I had it dead wrong. I later talked with my classmate, who had referred me to the company after working there for several years, and he told me that was a deal breaker – nobody who got one of the screening questions wrong got to the next stage of their process. Sure enough, the next week I got an e-mail telling me “thanks, but no thanks.” I wasn’t upset that I had “failed” the interview, though. If they had zero tolerance for any mistakes, I wasn’t interested. I had expressed my uncertainty but given it my best shot rather than giving up, which was the right thing to do. I filed the question away in memory and never got it wrong again. (As a postscript to this story, I have been assured by others that this all-or-nothing approach to questions is rare – don’t get worked up about getting the absolute right answer every time. Do your best, explain your thoughts and express your uncertainty if it’s strong)

For technical interviews, my best review was the handouts from “How to Hack a Google Interview” which are a good refresher on the computer science you already know handily presented in the context of technical interview questions. After finding it, I did not go into a technical interview without first reviewing it. Also helpful: for integers, radix (or bucket) sort is linear time.

For other interviews, I was honest and open. I tried to keep my selling points in mind and come back to them if they were relevant. I didn’t study any puzzle questions beforehand, and I don’t know that it helped the friends I had who did study them. I had an indispensable list of questions which I could ask anyone. Developing your own list of questions is a valuable exercise in understanding your priorities, so I am only including five of my questions here:

  • What does your typical day look like?
  • What are the biggest challenges you face? the biggest opportunities?
  • What critical things for this job don’t people learn in school?
  • What makes people successful in this position? In this company?
  • (and, for when I’m feeling ballsy) Is there anything about me that would make you hesitate to hire me?

Sidebar: A list of types of assessments I encountered during my hunt

  • Background phone interview
  • Coding/knowledge phone interview
  • Take-home coding exercise
  • Take-home case study
  • Submission of a code sample
  • Timed 90-minute exam
  • Online personality assessment test
  • Coding interview
  • Algorithms interview
  • Product design interview
  • Interview-with-Manager
  • Code review interview
  • Lunch/dinner social meeting

A note on networking

People tell me that networking is the essential element of job hunting. I had classmates admit that at their former companies, they had a policy of only hiring people referred to them by people they trusted. I didn’t have enough experience with it to draw any significant conclusions.

As a recent graduate, I did not have a strong professional network of my own. None of the alumni I contacted through my schools’ alumni networks responded to me. I had no friends or classmates who were working where I wanted to go, and I had no friends-of-the-family with connections in the companies I wanted to work for. I did have some friends online who went far above and beyond, spending hours on the phone helping me practice interviewing and giving me fantastic advice. I am sure that their help or recommendations were critical in getting some of my interviews.

This whole job search thing is a challenge and an enigma for many of us. There are lots of people who are willing to help if you just ask.

Thanks to Varokas Panusuwan and Raúl Alejandro Véjar Llugany for reviewing the post and for their feedback.

Posted in The Profession | Tagged , , , , , | Comments closed

Lessons from the Job Hunt (part 1 of 2)

MYTH: If you’re smart, you can get a job anywhere.

This is how I envisioned the hiring process. As a student soon to graduate from college, the job hunt was like the ultimate final. The majority-of-my-grade, comprehensive test of what I’d learned in school. If I did well, I got a good job. If I didn’t, I could always rent a room in my parent’s basement and be someone’s code monkey.

I finished my first job search a few months ago, and I learned that this vision of job hunt as exam was completely wrong.

This is what I learned instead: In the beginning, it’s a numbers game. Then it’s about finding a fit together. Know your selling points and reinforce them. Keep organized, and keep at it. This is an opportunity to learn.

I spent several months focused on little but the job search, so forgive me if the post is long; I’m breaking it into two parts. The first is about mindset and about preparation. The second is about talking to people, going on the road, and interviewing. I’m leaving out big portions here despite its length; I’ve barely mentioned cover letters or finding possible companies.

In the Beginning, A Game Of Numbers

I applied to 30 companies in two months. I had 16 total interviews with 8 of them. I had 3 on-sites, and 4 offers. I accepted 1.

The job search is a big filter. You start by sending out lots of resumes, feeding lots into the top, and each step through the process filters some out. They get filtered out – even if you’re basically awesome. This is just how it goes.

There’s some essential degree of randomness here. I sometimes like to think of the job search as a big Plinko board. You put the resume in at the top, it plinks around and maybe lands in the winning category: get a response! There are things you can do to communicate more clearly, but sometimes the chip falls the wrong way and it’s beyond your control.

Know Thyself

Before I could apply, I needed a resume. And because I wanted a single page resume so awesome it would blow down any doors in my way, before I could have a resume, I needed to be overwhelmed with anxiety. This is the point where my Dad sat me down and said, “Son, what makes you different? Why would someone want to hire you?”

Three or four key selling points acted as the underlying message behind my interactions with employers. I made sure I had points on my resume I could refer to when talking about them. I had reusable portions for my cover letter depending on which combinations of these selling points a particular employer seemed interested in. They were the structure behind my pitch as I handed my resume to recruiters at career fairs, and as I introduced myself to interviewers on the phone. These points gave me a starting point when I thought about how I was approaching an employer, and they helped keep me coherent (except in one interview, where I literally answered a question like this: “I think something that, uh, you know, makes me…um, different from others is that, uh….I have a background in writing and so I’m…oh, what’s the word? I’m more…uh, you know, articulate.”)

The resume is way more than these points, but it’s a great first place to start reinforcing them. For most people you meet in the job search, your resume is your introduction. It’s like an ice breaker where the prompt is, “Tell us your name, where you went to school, and a page1 of interesting things about you.”
This is really useful, but it can be tricky. What’s interesting, and how do you make it more so?

INTERVIEWER: it says on your resume that you're the "James Bond of programming" APPLICANT: Yes. I get the job done when others can't. I use the latest - the greatest - technology to do it. And I leave behind a multi-million dollar mess everywhere I go.

I got a lot of advice about resumes, but one of the bits that stuck with me the most was from a friend who’s been doing interviews at Google for several years: “I go into every interview wanting to hire the candidate; help me by giving me the chance to ask questions you can answer WELL.”

I also liked this guide on “How to Write a Killer Resume (for Software Engineers),” written by Niniane Wang

  • Include technical details of your work: programming language, your individual contribution, metrics.
  • Don’t dilute the impressive details with unimpressive ones.
  • Showcase your work using facts, not adjectives.
  • Include all relevant impressive details (awards, pet projects)
  • Don’t lie.

Microsoft’s Jobs blog has a post similar to Niniane’s point on using facts, about describing what you’ve “Made, Saved, and Achieved (MSA)”

Looking back, I probably spent way too much time obsessing over my resume. It’s still not perfect, and I doubt it will ever be. I spent a long time considering each section: I threw out the “Objectives” because I wanted to describe it better and tailor it more in each cover letter. I ended up describing my school curriculums because not everyone knows what you learn in a “Software Engineering” program (as an Apple rep. once asked, “So…uh, why didn’t you get a Masters in Computer Science?”). Instead of just listing languages and skills, I took the advice of another friend and described my level of competency and interest. Just listing languages is very vague. Does having JavaScript on your resume mean that you’ve written an application in it, or that you’ve popped up alert boxes? If you put COBOL on your resume because you did some hacking in it for a class, do you want people to hire you for that?

Thanks to Varokas Panusuwan and Raúl Alejandro Véjar Llugany for reviewing the post and for their feedback.

  1. I had two versions of my resume. One was two pages, with more details and which was fine to e-mail because most people scrolled through it anyway, and the other was one page, carefully condensed, for handing out, because that better suits the situation of giving them something quick and glance-able to introduce yourself 

Posted in The Profession | Tagged , , , , , | Comments closed