mike's web log

 

Blog Search


(Supports AND)

 

Google Ads

 

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

 

Quote

He who gets his users past the suck threshold and into the kick-ass zone the fastest wins.

Kathy Sierra



 

Navigation






<April 2014>
SMTWTFS
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910


 

25 Most-Visited Entries

 

Categories

  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
  RSS
 

Blogs I Read

 

Contact

Email me
 

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 4/3/2014

Totals
Posts - 2298
Comments - 2480
Hits - 1,618,145

Averages
Entries/day - 0.58
Comments/entry - 1.08
Hits/day - 410

Update every 30 minutes. Last: 2:22 AM Pacific

 
   |  Technical writer interviews: Part 1

posted at 11:21 PM | | [1] |

Someone I know was prepping to interview for tech writer job and asked whether I had any thoughts on questions that might be asked. I don't know too much about how it works in the wide world, but I did give a thought to how we (well, I) think about the interview process.
Before we get any further, I need to say this very clearly: what you read here does not necessarily reflect company policy, or our team's philosophy, or any specific or actual interview questions. What you're getting here are my personal thoughts about the interview process for technical writers. Ok, with that out of the way ...
If you interview in our group, you're looking for a "programmer/writer" position, meaning that you're a writer and you can program. So the interview process has to address both the technical and the writing.

There’s some difference in how this is handled for full-time positions vs. contracting positions. For contractors, the idea is that we’re looking for someone with a specific set of skills to solve a short-term problem. As such, the interview process focuses on drilling down into those skills and what the candidate can do to help with that particular problem. For a full-time position, the idea is that you’re hiring not just for now, but for 10 years from now. FTEs are an investment, so you’re looking as much for aptitude and what the company calls "core competencies" as you are for those specific skills. The FTE interview cycle is necessarily more elaborate and wider in scope.

I should also note that it’s an ongoing discussion about which is more important, the technical or the writing. This is sometimes articulated as "Is it easier to teach a programmer to write or to teach a writer to program?" I work in the most programmer-centric division of a programmer-centric company, so my sense is that there's a bias in favor of highly technical candidates. Of course, the ideal candidate can do both, and we have plenty of people (some whose job description does not include "writer") who have both technical and writer chops. But if you're faced with two good candidates, one a long-time programmer with a little writing experience, and one a long-time writer with a little programming experience, which do you choose? Answer: I don't know. Or more like: it depends – on the position, on the candidate, and on the team.

All that said, whether the position is for a contracting job or a full-time position, there’s still a technical screen early on to get an idea of the technical end of your capabilities. I don't usually participate in technical screens, so I’m not really an expert on that side interview process. But in general, our group documents web technologies, so we're interested in what you know about that, and about working with the .NET platform specifically.

So this is the flavor of the sort of thing that we might think about asking you, which are all questions I'm just making up for the purposes of illustration:
  • How do you get the value of a field that's been submitted in a form?
  • Describe what's "cascading" about CSS.
  • What are some options for maintaining state between pages?
  • What's a cross-site scripting exploit and how can you protect against it?
  • What's AJAX and what's it good for?
What these questions get at is not a specific set of knowledge about how ASP.NET works so much as a candidate's experience with web programming. If you've done server-based programming for the web, these are things you've presumably encountered, if not necessarily become an expert at. (Have I mentioned that these are not necessarily specific questions that might come up?) If you don't know any of these things (or whatever kind of equivalent questions are actually asked), one might wonder whether you're a good candidate for writing about web technologies.

There might also be a slew of ASP.NET-specific questions as well, again depending on what exactly the interview is for and what the candidate seems to know, perhaps along the lines of What's view state? or What are your options for displaying data on an .aspx page? or -- heh-heh -- In an ASP.NET app, how do you establish read-write permissions for SQL Server when the database isn't on the same box as the web server? Heh-heh.[1]

There are also likely questions to determine how much a candidate understands about .NET and about object-oriented programming, which might be along the lines of, dunno, How do you create a read-only property? or What's the difference between an interface and an abstract class? Questions that, again, are really more about familiarity than about super-expertise.

Ok, so that's technical, which I will say again that I am not generally involved with. Whenever the opportunity arises, I do try to get involved with assessing the other half of technical writing, namely writing. More on that next time.


[1] We would actually know if you had experience with this question just by glancing at you -- people who've investigated this have big divots on their foreheads from where they banged their heads on their desks.

[categories]