Monica

We're hiring, so I've had recent occasion to see a hiring "dark pattern". I don't know how widespread this is outside of the tech industry, but I see it a lot in tech and it needs to stop.

The pattern: asking for "number of years of experience in (insert tool, language, or skill here)".

Jobs are multi-faceted. I'm seeing people who don't know how to choose a number, and just as I see the ones that overshot, I know there must be ones who undershot and were filtered out. I saw a resume recently from someone with a broad role, who listed "N years experience" in something where N was the length of the job, even though the job involved many other things and wasn't primarily about that skill. That's "N years of experience" in the same way that I have "20 years of Java experience". Spoiler alert: I don't.

Recruiters and hiring managers put people in this position: we have this checklist, tell us how many years of each, and we need a number not an explanation. Maybe we're making you fill out a web form and you can't even add a comment or ask questions. In the absence of guidance about primary and secondary skills, people will apply different weighting factors. It's a mess.

I often don't know how to answer either. In the last four years I've gained four years of tech-writing experience, the focus of my job, and four years of git experience, meaning I have all the basics and can untangle a merge conflict (but I've never rebased successfully). Those "four"s don't mean the same thing; I don't spend all day using git. Tech writing is fundamental to my role and I'd have no qualms about fully claiming those four years, but for git I would want to say that I've used it as part of my job for four years. That's different. I don't have the same knowledge that an infrastructure person whose job revolves around maintaining git servers and stuff for the same amount of time has. "How many years of experience?" questions don't allow for that nuance.

People who are trying to be thoughtful and honest run the risk of getting filtered out, and people who count "everything" get filtered in. I wonder how the success rate (meaning "acceptable hire", since you'll never know if you got the "best hire") of this exercise compares to recruiters just not filtering on skill-specific numbers at all (just general experience) and having the hiring team evaluate more people. I'm fortunate enough to be sufficiently "long in the tooth" that I don't need to worry about this gatekeeping -- either you're looking for a top-notch tech writer with all that implies, or you aren't -- but this hurts early-career people where the difference between "2" and "4" can make or break a deal.

As for the Java: I spent years documenting and helping to design Java APIs, wrote some examples, but haven't written anything deep and complicated. Someone with a year or two of full-time actual Java development experience beats me. Would the recruiter be able to tell?

Today's bit of randomness:

When I was a young programmer I worked for an AI company on a text-categorization project -- for a commercial client, all hush-hush for a while to preserve their competitive advantage and such, apparently really innovative (didn't realize then; I was just writing code to solve a problem, y'know?). Then somebody accidentally published the training dataset. And apparently it's gotten quite a lot of use in the research community, which I was completely unaware of, having never really been that kind of researcher.

For 30+ years there's been a mystery in that dataset that people have noticed, commented on, and apparently never tried to track down...until now. This podcaster got in touch with me and some others last week, and here's the result: Underunderstood: The Case of the Blah Blah Blahs. (36 minutes; no transcript yet but it looks like they're planning one.)

It was neat to hear this trip down memory lane, and also to hear other parts of the story I'd never known about before, including the discussion from a researcher from the "other side" of one of the big arguments in AI in the 80s.

Like many others, I get lots of unsolicited email from recruiters who claim to have read my LinkedIn profile and have a great opportunity for me. They're almost always wrong about both. But I usually skim the tech-writing ones when they arrive, to (maybe) learn a little about the state of the field.

The latest one, about a "fast-paced innovative team", started off generic, as most of them do. (Hint to recruiters: if you want me to respond, give me a reason to. I'm not actively looking; you have to show me something interesting.) But the list of responsibilities included "work with architecture and UX teams to understand how best to organize and present the documentation" -- hey, they have a UX team! That's unusual (in a positive way). I kept reading.

Then I got to the requirements, which included:

• Experience with Cobol
• Strong working knowledge of Microsoft Office

Ha ha, no.

Also, it's in New Jersey and the ad doesn't say anything about remote employees. Bzzt.

Somebody on a tech-writing mailing list just asked what kinds of questions we tend to ask interviewers when we're interviewing for jobs. The person had already mentioned, specifically for hardware-related jobs:

• Do you test the documentation? How?
• How does legal review work (for things like liability)?
• Availability of subject-matter experts for reviews?

Here's what I wrote in response:

My experience is in software, which might be different from hardware, but I always want to know:

• How early and in what way are writers involved in development? Do writers participate in functional and design reviews? Do we have input into the user interface? Are we part of the team, or do we come in later, take what they've built, and document it?

• Can I use the product? As much as I want?

• What processes do both the dev and doc teams follow? (If they say "agile" there are more questions.) How is doc reviewed and by whom?

• (How) do we make doc improvements that aren't directly tied to new features or bugs? (For example: larger reorganizations, improving indexing, adding runnable examples, tools improvements.)

• (How) do you use source control for documentation?

That's off the top of my head, without digging out my notes from my last round of interviews.

So that's not a complete list either, but these are the kinds of things I tend to be thinking about. (I also try to find out if I have access to the source code, but since he was asking about hardware I didn't bring that up.)

I also want to know where the documentation group is placed, organizationally speaking, but I usually learn that indirectly.

Part of this meme:

LISP

The most valuable part of my education as a technical writer was my student internship with the Common LISP project. It was also either the first- or second-most important part of my education as a software developer. Yes yes, the classroom stuff was important and the software-engineering project course was essential for putting the pieces together, but this was the real world and the real world is far less tidy than the classroom.

I was brought on to help write the documentation for this then-in-development language. (Other varieties of LISP existed; this was an attempt to unify them.) But unlike all previous tech-writing work, this was for a thing that did not fully exist yet, and I was part of the ongoing design process. I was there in the (virtual) room with the lead designers, Guy Steele, Dave Moon and dozens of others big and small, and if my contributions had merit it didn't matter that I was an undergraduate with no real experience. On the ARPAnet nobody knows you're a dog undergrad. Mind, being an undergraduate with no real experience, I didn't necessarily have a lot of design ideas to contribute, but even then I was pretty good at catching inconsistencies and asking key questions. I learned to write software-interface documentation there, but even more importantly I learned to be part of a real software-development process, to ask questions even if they might seem "stupid", to argue for technical positions and support those arguments, and to be a full member of a team.

When I graduated and met more of the real world I would learn that it usually doesn't work like this. In a lot of places, tech writers are not part of the development process (and may not even be in the development department) and the attitude is that they can come in after the big boys are done developing the product. Phooey on that; this important early experience taught me that it doesn't have to be that way, and I have held firm on this in every place I've ever worked. If I hadn't had this early lesson, I might well have fled the field.

It is also because of the Common LISP project that I went into programmer documentation (and expanded from there). I wouldn't have pursued tech-writing jobs that were all about walking the menus in the UI and stepping through wizards and such; I want to look under the hood, understand what's there, and use that knowledge to help users. Building software development kits like I do now is exciting and nourishes my inner geek. When I went to college I hadn't even heard of technical writing (I went there to do computer science), but I came out as a technically-proficient writer who knows the good that is possible. I have Common LISP to thank for that.

Someone on a tech-writing mailing list today asked the following: "As a hiring manager, what are you looking for in a resume? Do you think hiring managers with a technical writing background look for different things than one that is just getting to employee their first technical writer?" I want to record my response here:

I am a software developer and manager who was formerly a full-time tech writer. (I still do some writing, but it's not the majority of my work any more.) When I was hired it was for a sole-writer position.

What I look for in a resume is: technical expertise (what domains do you already know?), types of writing, size/complexity of past projects, and classes of tools. On this last: I don't care about the long list of tools (my eyes kind of glaze over, actually), just as for programmers I don't care about the long list of languages dating back to college. I do care about whether the candidate has worked with structured editing (e.g. XML) versus just working in Word. I care about whether a candidate has built or maintained the tool chain. But I don't really care if you've used Epic or FrameMaker. Tools are tools; I assume you can learn the ones we use. We'll sanity-check that assumption in the interview.

You may have noticed an absence of actual writing skills on my list. I can't judge that from a resume (except in the negative); that's what the writing samples are for, and they're essential. I want up to a few hours with them, not just what I can see while we're talking during the interview.

I don't have a lot of data about what non-writer hiring managers look for, but I believe the factors that got me hired by my current company were: technical skill (both writing and programming), ability to work with geeks, ability to work independently (demonstrated by past positions), and asking insightful questions about their software (showing that I wasn't going to just parrot what the SMEs told me, and also that I'd done some homework). (Granted, you don't get to demonstrate some of that until you get the interview.)

(Not posted on the mailing list because it would have been topic drift: For what makes an excellent writer in my particular domain, as opposed to just what I'm looking for in candidates, I find that an entry I wrote almost seven years ago still sums it up pretty well.)

A friend recently posted (in a locked entry) about an amusing experience he had on a job-interview trip. It reminded me of something that happened on my first day-long interview. (For some reason this style of interview was then called a "plant trip". Or maybe that only described the subset of such where they had to fly you in; not sure. I haven't heard this term in quite some time.)

I was a senior in college, so I was trying to line up that first post-graduation job and was not being at all fussy during the interview stage. I didn't have strong opinions about geography back then, so of course I accepted the interview offer from a large computer-equipment company on Long Island. I would fly in in the morning, have a day of interviews, and fly home that night. This was my first such trip, so my only clues about what to expect came from the well-meaning but under-informed folks in career services.

( Read more... )

gregbo linked to an article about why it's hard to keep senior developers doing development. The author asserts that no self-respecting developer started his career thinking "I want to be a manager!", but the natural progression is toward technical leadership, management, or both. This progression is captured, somewhat cynically, as the Peter Principle.

The author of the blog article calls on developers to resist the urge. Remember that you love coding, he says. But I think there are good reasons to want to move in this direction, reasons that probably don't become apparent until you've been out there a while, and which I'm seeing now that I'm in that position.

I think I was a pretty darn good individual contributor when that was the main thing I did professionally. Because I work with a cool group of people in a business sector that already tends toward this kind of flexibility, I was generally able to get a hearing with the leaders -- product managers, tech leads, executives, et al -- because I'd proven that I had some clues. That means it was possible to have influence beyond my own little box. That's important to me. If I'm going to spend 40+ hours a week on something, I want to have some ability to make it matter. If I don't care, I disengage, and that's no good for job satisfaction or employer satisfaction. I need to believe that I'm making good stuff and meeting professional quality standards. Nearly a year ago, when the possibility of my current project first arose, I told our CEO-equivalent that if we're going to do this right I want to be deeply involved, and if we're not going to do it right I want nothing to do with it. He made me tech lead.

I've been a tech lead before, but this is my largest and most complex project so far, with potential to get much bigger, and it's been pretty nifty. I'm providing a lot of the technical vision, conducting design and code reviews, mentoring newer people, learning to be agile and adaptive (new requirements, discovering bodies in the code base, bugs, etc), and, in many ways, setting the agenda. I'm not the arbiter of requirements nor long-term strategy (and I don't have customer contact), but I have opinions there and a chance to get them heard seriously. Because I've been at the company a while, I'm seeing seeds I planted (as tech lead of a much smaller effort) years ago finally starting to take root -- this project is a logical follow-on, and in the intervening time I've gained some credibility. I think I can push out some good stuff beyond the confines of my own projects, and this role gives me better traction to do that.

I make sure I keep some individual-contributor work for myself, because I don't want my skills to rot and because I want to produce something beyond carbon dioxide and meeting notes. I also hold by the philosophy that, as much as possible, I shouldn't ask people on my team to do stuff I'm not willing to do myself. I might not be able to do it due to time constraints or (lack of) specialization, but I should strive to be able to, as much as practical. First off, it avoids that peons-versus-leaders chasm where the scut work falls to the so-called peons (today I started doing a particularly ugly merge, for instance). There shouldn't be peons; I want the people on my team to feel they have more power than that. Second, it improves overall adaptability if someone gets sick or hit by a bus or lured away by Google.

I'm also a manager (in the HR sense); I currently have three direct reports, two of whom I got this year. I used to worry that I would be bad at this, but so far that's working out ok. Part of that is excellent people. But I also find that I enjoy the mentor role. (And it's a small-enough group that management qua management doesn't consume a lot of time, except during performance-review season.)

All of this gives me a chance to increase my impact. I think I'm good at what I do and that I have a decent clue about what's good for our business unit on a strategic level, so this seems like a win to me. But it's not without risk; most significantly, I think, it can be hard to go back to the old role. I like this now, and I like where I think it leads for the next few years; beyond that is pretty hard to imagine.

Granted, I was never the type of senior developer the article is targetted at, but there are enough similarities with the sometimes-twisted path my career has taken to resonate anyway.

1. What do you like best about the city where you live now? What do you like least? ( Read more... )

2. What is your impression of Orthodox Judaism "from the outside", as it were? ( Read more... )

3. How did you choose the synagogue you go to?( Read more... )

4. How did you get into RPG and what's your favorite game? ( Read more... )

5. If you could have any job in the world, what would it be? ( Read more... )