About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 30 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

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

Dogs are my favorite role models. I want to work like a dog, doing what I was born to do with joy and purpose. I want to play like a dog, with total, jolly abandon. I want to love like a dog, with unabashed devotion and complete lack of concern about what people do for a living, how much money they have, or how much they weigh. The fact that we still live with dogs, even when we don't have to herd or hunt our dinner, gives me hope for humans and canines alike.

Martha Beck



Navigation





<December 2014>
SMTWTFS
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

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  

Contact

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 11/24/2014

Totals
Posts - 2316
Comments - 2506
Hits - 1,693,641

Averages
Entries/day - 0.55
Comments/entry - 1.08
Hits/day - 404

Updated every 30 minutes. Last: 12:21 PM Pacific


  11:21 PM

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]  

[1] |