Post-its and Interviews Part 2

Here's the continuation of Janet and her team getting ready to interview candidates to hire a new team member. (See Part 1 here)

As the team files back in after their break, several people stop in front of the board, looking it over and thinking. Janet calls everyone to the table.

"Ok. We've built a good list here. We've got a couple of tasks to take care of, and maybe a little homework for everyone. Let's start out by talking about our job posting. What should it say? Why don't we break into pairs and see what we can come up with?"

After several minutes the pairs are combined into two teams of four and asked to write a new posting based on both pairs efforts. Several minutes later and the two teams are combined and work on merging their job postings into a final draft.

"Hey, this is a great start, but I think we might want to tailor the message a bit for our different channels," says Cindy, another team member.

"Good idea," responds Janet. "Before we go down that path though, which recruiting channels should we use? Any ideas?"

Several people respond as the lead writes ideas on the white board: the local UX users group, the jobs board at a conference two team members are going to next week, the HR recruiter, and a number of other ideas are all written down. Janet speaks up again.

"I like this list. How should the messages be different for each of them?"

The team dives into the discussion again, coming up with a short list of do's, don'ts, and thoughts about each of the possible recruiting channels. Team members are each assigned a recruiting channel to write a job posting for, and asked to email their efforts to the team tomorrow for approval.

Larry, the senior designer, speaks up, "Ok, if that's out of the way, do we want to build the interviewing team? I really liked the job Susan's been doing leading our reading group. Could she be the primary screening interviewer?"

"I think that would be great! Susan, are you up to it?" Asks Janet.

"Well, I was hoping to be on the main team again, but this sounds like a fun task too." Susan replies.

"Don't worry, we'll look to you for some guidance on what to ask about, and listen for, around books the candidates have read recently." Janet turns to the rest of the team. "Which of our customers should we invite into the interview process?"

Does your team spend enough time before the interview to make sure you'll hire the right people? What do you do to improve your interviewing and hiring process?

Post-its and Interviews Part 1

I was in a meeting room I'd not visited before the other day and I saw a great idea on the wall. At a glance, I saw what another team had been doing.  With a little more thought and discussion with a co-worker, I was able to build a more complete picture of their activity, what it could have been about, and what it could lead to.

An entire wall was covered in sticky-notes, each with a short description on it.  There were inscriptions like: "listens", "thoughtful", "understands user perspective", and "can read code". The notes were divided into groups like: "Leadership", "Communications", "Design", and "Information Architecture".

It didn't take much to realize that I was looking at a team's description of what they wanted in a co-worker. It was only a smaller jump to put together the following scenario.

---

The Web Design Team for Product-X recently had a member jump to another team, and they were preparing to hire her replacement. I imagine Janet, the team lead, gathering everyone in a room and handing out small stacks of sticky notes. Then she would address the team to kick things off.

"You all know what's in our job description. I'd like you to think about that for a moment, then write down some traits you think we need to be looking for. Let's take 5-10 minutes to write them down and put them on the board. Don't be afraid to talk to each other while you're working, we're not keeping any secrets."

I can almost hear the buzz of the team working on this and building on each others ideas. As they wind down, Janet speaks up again.

"Ok, this looks like a good sized list. Let's organize it into groups. If you see duplicates, stack them together and we'll sort them out in a bit."

This is probably a pretty interesting process as clusters of traits are built up, split apart, and moved around. Gradually, the level of activity settles as the team comes to some agreements. Bill, one of the designers might speak up and say something like.
"Hey, I think we're missing some things here in "Leadership" and maybe there in "Design". How about we take five more minutes and flesh these out.  We could work on the duplicates while we're at it."

There's a lot more discussion this time. Some of the supposed duplicates are split off and moved into other groups. Others are recognized as real duplicates and those traits are starred, indicating higher importance. New traits are added to each of the groups. Finally, the energy beings to lag again, and Janet speaks up.

"Ok, this looks like a pretty good start.  I'd like to take a ten minute breather before we come back and get into our next steps."

Everyone files out of the room intent on getting some water, juice, or coffee, and maybe a quick walk outside for some fresh air.

---

I'll post about the follow-up meeting on Thurssday. Do you think a process like this might help with your next hire? Maybe in writing job descriptions for your team (you do have job descriptions, right?)? Have you tried something like this?

Reviewing Annual Reviews

Almost everyone seems to hate end of year performance reviews. Done correctly though, they could be celebrations of your accomplishments. What would it take to make them more exciting, more interesting, or at least less painful?

How about this for an annual review?


Maybe we're not going to see videos with voice-over announcers, screaming fans, or a pulsating soundtrack. Surely we can do better than a drab document that briefly mentions the couple of things that we remember from the last year, right?

Here are some thoughts that might make your annual review a more positive experience:

• Keep records during the year. What have you done? What have people said about it? What did it mean to your org? The more data you have the easier it will be to create a year end review that shines.
• You might not be the one writing the review, but you can create something to send to your boss to help her remember what you've accomplished this year.
• Think about how you want to organize your review. You don't have to write things chronologically. Maybe you'd rather pull out some specific themes and follow them?
• Remember to prioritize your entries by impact too — 2nd, 3rd, 1st is a nice order to help keep the big wins 'top of mind'.
• Include comments from others. Quoting an email or notes from a on-on-one is a great way to reinforce the value that others see from your contribution.
• Work from established goals. Both yours and your organization's.
• Use last year's review and your records from the current year to hold personal retrospectives periodically. Make sure you're on track and excited to move forward.

And, who knows, a soundtrack couldn't hurt, right?

This is a book that I wish was on my son's required reading list.  Not that his code is hard to read (for someone in their first programming class), but that there are all kinds of bad habits that wouldn't need to be broken if he and his classmates spent some time learning what good code looks like before they started to write their own.



The Art of Readable Code from O'Reilly is a quick, easy read with a lot of useful ideas for new programmers.  It weighs in at 180 pages, but there's a lot of well used whitespace and a number of (mostly on topic) comic panels in those pages making it seem shorter.



Part one covers naming, code layout, and writing comments; parts two and three cover the meat of refactoring; and part four discusses testing and gives an example of applying the ideas in the book to a small coding project.



The book's examples are in C++, Python, Java, and Javascript.  I would have appreciated seeing some examples in other languages as well (haskell or scala might be good candidates), especially where that language might obviate or change the advice given.



Truth in advertising note, O'Reilly sent me a free copy of this book to review.

The Linux Command Line

As a long-time, professional Unix/Linux sysadmin, I spend a lot of time on the commandline. I've grown pretty familiar with it, but I often find that junior teammates don't have the same familiarity. They often grew up in a world of windows and GUIs. That means I spend a lot of time helping them learn the ropes.

When I saw that No Starch Press had published The Linux Command Line, I wanted to take a look and see if it would make a good primer for the new guys on my team. Then, the good folks at No Starch sent me a review copy and I figured I'd better act on it.

This is a decent sized book, weighing in at 430 pages and 36 easily digestible chapters. The writing and layout are pretty good, and there are a ton of examples.

Part One is 10 chapters (~110 pages) that cover the basics: built-ins and simple commands; redirection; command line short-cuts (for bash in emacs-mode); permissions; and processes.

Part Two is 3 chapters that will jumpstart you getting beyond command line use. These talk about: setting and using environment variables and startup files; using vim; and making the command prompt more useful.

Part Three is a bit meatier. This contains 10 chapters covering tools for: package management; networking; working w/ storage media; regular expressions; working with text, and more. A couple of chapters in here seem less than necessary (E.g., Chapter 23 'Compiling Programs') but if you don't need them, you can always skip over them.

Part Four dives into scripting, where the true power of the command line comes out. There are 13 chapters which cover: designing scripts; conditionals; looping; parameters; and more.

My biggest complaint about this book is its bash centricity. It would have been nice to throw in a chapter and some sidebars talking about how other shells differ, or mentioning those parts that only bash provides. Since dash is becoming more frequent on Linux systems, it would seem like a natural comparison to make in the text.

Still, this is a good book on using the Linux Command Line. If you're just getting started with Linux, or you have a friend and/or coworker that needs some help, this is a good place to start.