Uh oh. I’m seeing laundry list job descriptions. You know, the kind of job description that so carefully bounds the job with so much technical tool skill, that no one could fit the job.If your job descriptions are laundry lists of tool skill, reconsider how you’re describing the job. I like to think about the four dimensions of technical skill:
Functional skills: what the person knows about their job (development, testing, project management, writing, etc.) Learned job skills.
Product Domain expertise: how people understand the product and the product domain, and how they apply those skills to the product.
Tools and Technology: how well the person knows the tools of the trade: compilers, testing tools, defect tracking tools, databases, and so on.
Industry Knowledge: what the person knows about the kinds of people likely to buy your system, and the general expectations of the your users.
If you are hiring a developer, the kinds of functional skills you’re looking for could include: design, debugging, pair work, how to use a configuration management system and defect tracking system. When you look for domain expertise, you’re looking for how the candidate applies their functional skills to the development at hand. The tools and technology are the minimum set of tools you require. (And remember, technical people are excellent at learning new tools.) Decide if a candidate needs to know about the industry.Avoid those laundry lists job descriptions. Organize your technical requirements into these four dimensions, and you’ll have a way to think clearly about the job requirements.
I was reading How Would You Design Bill Gates’s Bathroom? and realized that Microsoft discriminates for people who are visionaries, people who see the big picture. When they do this, they ignore the other types of people necessary for successful products and projects: the stabilizer, the firefighter, and the catalyst.Keirsey calls these temperaments by slightly different names:
Rational: People who have a vision for the big picture (visionary)
Guardians: People who can complete things (stabilizer)
Artisans: People who solve problems without believing in or following the One True Path (firefighter)
Idealists: People who are empathic and use that empathy to create communities (catalysts)
All of us have access to all of these parts of our personalities, and most of us have a strongly preferred temperament. And, many of the people who work in software development are visionaries. When Microsoft (or your company) discriminates for more visionaries, consider whether you’re helping the company complete their work successfully. Many visionaries have trouble completing the last little bits of work, things the stabilizers wouldn’t consider NOT doing. Visionaries think they have the one best idea, and that there is a specific path for fixing a problem, unlike the firefighters who choose a reasonable path that comes to the necessary conclusion. Although visionaries intellectually understand the concept of empathy, they wouldn’t consider taking the time to create a community, unlike the catalysts.A team of only visionaries has trouble creating and maintaining successful products. Microsoft’s products are market-successful, and too often create difficulty for the people using them. The good news is that we have whole industries fixing holes in Microsoft’s products. If Microsoft didn’t tilt its hiring so heavily to the visionaries, we wouldn’t need those industries.All of your interview questions discriminate for or against certain kinds of candidates. Just be sure you’ve considered personality diversity, not superficial diversity when you create interview questions and auditions.
Via the Boston Job Works blog I found this piece on Hiring in Times of Anger and Fear. The points Jack Thomas makes are great, and can be summarized by making sure you keep your self-esteem, follow through on commitments, and maintain your sense of humor. All easier said than done.If you’re looking for a job, especially if you don’t have one now, consider these suggestions:
Treat finding a job as you would a project. For me, that means creating an action item list, and managing my activities, so that I do everything I say I’m going to do. If you say you’ll send a document to someone, write yourself a note to do so, make sure you send it when you said you would, and cross it off your list when you’re done. (If you’re not a list person, you don’t have to make lists, but choose some mechanism so you know you’re meeting your commitments). When you treat looking for a job like it’s a project, you can track your progress, see that you’ve worked on it every day, and see what you have left to do. Crossing lots of items off your to-do list will help you feel as if you’ve accomplished something.
Define yourself by your successes, not your perceived failures. You’re probably not looking for a job because you’re a “bad” employee. You were probably in the wrong place at the wrong time. Look back at your career, and define your successes. What made you a success then? Is that work or an environment you can look for now? You’re not stupid or dumb; you’re unemployed. Find places you can rejoice in your competence now. For example, take Thomas’ advice, and get directions from multiple sources and leave early for the interview. If you realize you’re going to be late, call.
Don’t forget to maintain your sense of humor. Remember that Murphy’s Law sits on your find-a-new-job project, as much as Murphy used to sit on your work projects. Things will happen, and your best coping mechanism may be to see the humor in the situation.
You don’t need to be obsequious or demanding. Know who you are, what you’re good at, and why these folks should hire you. If you have your self-esteem, you’ll (eventually) succeed in finding a job.
In Workplace boomeranging, Jason Butler reports on his experience returning to a previous employer: “I found my previous experience at the company beneficial in minimizing ramp-up time; if you already have a reputation and you already know all the players, you can get right to work.”If you’re looking for a job, call all your ex-bosses and ex-companies. Your ex-bosses will know about you and your work. You can relate your most recent work to their needs. Your ex-companies will appreciate your domain expertise and any other new experience you’ve gained that you can relate to your domain expertise.This is a specific case of working your network. I like to create a script, so I know what I’m going to say. (You don’t have to read the script; I find that I’m less nervous if I have a script or at least a list of points.) Here’s a script I’ve used in the past:
Call previous bosses (I make a list with phone numbers and emails).
Introduce self. Remind boss when I worked for him/her and what I last did at the company.
A little small talk. (Hey, I’m a geek. If I don’t write this down, I may forget.)
“I don’t know if you’re looking for someone like me right now, but here’s what I’ve been doing.” (Summarize your experience.) “I’ve managed a few programs since we last talked. The largest one was 7 sub-projects, took 13 months, and had a total of 100 people. I had a blast. I’m calling to see if you need anyone with my experience.”
Wait. Let the other person think, breathe, whatever. Your ex-boss will say something.
If the ex-boss says there’s an opening, ask how you should send in your resume. The reason you want to ask how to send in your resume is to allow your ex-boss to take advantage of any recruiting fee the company pays for employees to recruit peers.
If the ex-boss says there’s no opening, ask if the ex-boss knows of anyone who could use you and your talents. Your ex-boss has a different peer set than you do, and you can leverage his/her network.
Sometimes, all the players have changed, and you don’t know anyone at the company anymore. In that case, call HR (a harder call), and lead with your previous experience, “Hi, I worked at YourCompany two years ago for five years, and I was wondering if you had any openings in my field.” Certainly, look on the jobs page for the company’s web site, but if you know any of the HR people, try them directly. Some jobs aren’t advertised at all.It’s harder to network with a company, even through HR, than it is with a person. If your ex-boss doesn’t have any openings, make sure you ask if he/she knows anyone who does have openings that might fit your talents. It can be scary to call someone out of the blue, but remember that you know this person. This isn’t a cold call; it’s at least a lukewarm call, if not downright warm. If you left on good terms, it can be a hot lead.I regularly network with previous employees. I’m happy they call, and I want to help them. I don’t think I’m that unusual as an ex-manager.
In response to my last blog entry, Questions for Hiring Architects and Designers, Dave Smith wrote this:”I took a slightly different approach when I was a hiring manager. Instead of canned set of questions, I would get the candidate to a whiteboard, pose a vaguely-stated, open ended design problem with no “right” answer, then ask the candidate to walk me through how they would approach it. Depending on what skills I was looking for, I’d ask for Use Cases, specific UML diagrams, etc. Since the problem was vague, I expected that candidates would ask for clarification (rather than diving right in), and by tossing in new information midway, I could get a handle on whether the candidate could switch gears, or whether they would charge ahead with whatever approach they’d started off with.”"Looking at what level the candidate chose for their initial approach was also enlightening. Architect/Designer candidates who started sketching data structures before they’d clarified the problem flunked out rather quickly. (Even when hiring developers, this approach was good for getting a quick grip on their true level.)”"I wrote the technique up a while back. See http://www.perlmonks.org/index.pl?node_id=53569.” [JR Note: Dave's post is slightly perl-centric, but the ideas are clear.]Dave shows a very high level of interviewing competence here. He starts with an open audition, and then tailors the audition on-the-fly to progressively probe the candidate’s abilities. Dave looked for information early: “candidates who started sketching data structures before they’d clarified the problem flunked out rather quickly,” and Dave was able progressively filter out candidates based on their responses to each part of the audition.If you’re a hiring manager, think about how you can frame auditions so that you can detect the candidate’s level of job ability. If you’re a candidate, think about how you want to showcase your abilities to hiring managers.If you’re a non
How do you differentiate true designers and architects from other software developers? This may be the hardest question to answer, and the most necessary. A real designer or architect, someone who doesn’t just hack a bunch of software together, is worth more to your company than you can pay him/her. A real designer or architect can translate the vision of what the product has to be into the here-and-now, no matter what development practices you use. (The agile practices help more of us become better designers and architects than the top-down, decomposition practices.)So if these people are worth a lot to you, you’ll want to think hard about the questions you ask them. Here are some suggestions; I’d love to hear your comments:
What’s the most powerful language you’ve ever used? Why? (I would listen for LISP or Java. If I hear C or C++, I worry about the exposure this candidate has had to alternative techniques. C and C++ are not particularly powerful. In my never-humble opinion, C and C++ can lead to bad designs if the candidate has not been exposed or hasn’t worked with alternative languages.)
Do you typically generate alternative designs? (The best architects and designers generate at least 3 alternatives.) How do you choose between these designs? (Listen for at least 2 or 3 stories about how the candidate made decisions, and with whom. Did the candidate make decisions alone? With others? When I’ve worked with great designers, they chose to bounce ideas off their peers. As a project manager or manager, they would explain the differences to me, but I was not always part of the decision-making process. It depended on the consequences of that decision (who else the decision affected).
Tell me about the last major design you did. What was the purpose? What happened? …. Listen for the candidate’s assessment of risks, who the candidate worked with, how the design worked, when the candidate found problems.
If you had to design for our product (talk about your product here), what approach would you take? …. Listen for language choice, type of architecture choice, type of investigation, whether the candidate would prototype, if the candidate would work bottom up or top down.
Things I listen for:
A lack of introspection. Good designers and architects spend time in their heads. They tend to be more introspective than other people. If a candidate says that he/she hasn’t thought much about how they design, I wonder about their level of design and architecture expertise.
If a designer tells me a first design is the “obvious first and only choice.” I don’t buy it. We edit writing, we should edit our designs.
A lack of multiple computer language experience. I don’t want a designer who doesn’t understand that the technical choices we make about the product radically influence the product architecture and the choice of lifecycle and practices. (See Language (and Language Environment) Influences Process.
Great designers are not born; they’re created from experience and learning from experience. Make sure you think about what you need from an architect or designer before you even phone screen a candidate. The value of a great designer or architect is immense — much more than you pay that person.
In previous hiring tips, I suggested you ask behavior description interviewing questions and perform auditions. I haven’t discussed hypothetical questions yet, because they can be difficult to frame well.In response to my current Stickyminds column about how to improve tester performance. Suzan Noden said she uses this as a question: “how would you test the ls (or dir) utility?”. A surface answer involved options and output. A deeper answer might involve timestamps, permissions and directory depths. An even better answer would include different types of filesystems, network mounts, etc.”What a great hypothetical question. Anyone who knows anything about Unix has the capacity to answer this question and show off their testing skills.A manual black box tester might say something like this, “Look to see that the output is alphabetical in columns,” a surface answer. A more knowledgeable person might say, “Let’s set up a possible race condition by having two processes modify the files at the same time as another process attempts to ls. A tester who knows about different devices might discuss timing and the response time of certain disk drives or other drives.Hypothetical questions help you understand how the other person thinks they think. Unfortunately, the way people think about themselves is not necessarily how they act, but that’s why you have behavior description interviewing questions.You can effectively use hypothetical questions to learn if the candidate has deep knowledge of the subject. Then follow up with behavioral interviewing questions to see if the candidate has ever used their knowledge on the job.