When you're interviewing for a job requiring XML skills, it helps to know why the company is using the markup language in the first place. Is it for message passing? Document storage? Object serialization? Understanding that context is about more than crafting good answers to interview questions. It can help you determine whether the company is a good match, notes Simon St. Laurent, senior editor for O'Reilly Media and author of XML Pocket Reference and Programming Web Services with XML-RPC. Still, when it comes to the part where the interviewer is focusing on your knowledge of XML, you want to be as prepared as you can be. Here are some of the questions they might ask, and some notes on what they're looking for in your answers. On which platforms have you used XML?

• What most people say: "I've worked with XML a little bit. I've integrated RSS feeds with some e-reader apps on my iPad."
• What you should say: "I've mostly worked with XML in PHP in Drupal and a little bit in WordPress." Or:  "I've used XML functions in C# to aggregate data for a proprietary Web CMS."
• Why you should say it: Specific use-case scenarios of XML are always better.

Which systems did you integrate?

•  What most people say: "I've used XML plugins to combine Google News and Twitter feeds into a single stream on Opera. It makes for the easiest reading."
• What you should say: "I did an XML data feed to integrate with an e-commerce tool called Foxy Cart. I integrated it with both Drupal and WordPress. The tool granted people access to exclusive content after they purchased a subscription. In Drupal, I used a module called Feeds. WordPress was a bit more time-consuming. I had to code from scratch using SimpleXML. As for protocols, it's a custom XML layout designed by Foxy Cart." Or: "My client needed an app that would aggregate RSS feeds of news articles and sports scores and display them in real time on his website. I used the standard XMLReader class in System.Xml and stored the data locally in MS SQL."
• Why you should say it: A good candidate should be able to say what platform they used and what the XML integration was for. A great candidate will give specific names of the libraries or APIs that were involved.

If I asked you to design a vocabulary, when will you use elements and when will you use attributes?

• What most people say: "I use whichever seems most compact for the model I'm using."
• What you should say: "I decide based on context and the odds that I might someday have to add extra structure to the content in a piece of information."
• Why you should say it: There's no consensus on when to use elements and when to use attributes. Many data-driven formats use attributes because they seem simpler and smaller, while many document formats use attributes for metadata, to keep it out of the way of the "real" content. The biggest headaches arrive, though, when something that used to be a single value in an attribute needs to be a complex structure. Context lets you bridge the document/data divide, and future-proofing demonstrates that you're thinking longer-term.

Someone sends you a broken XML file. What do you do?

• What most people say: "I reject it and send them some kind of error message. XML isn't supposed to be forgiving."
• What you should say: "It depends on the kind of information. If it's not critical, maybe discard it. But if it's potentially important, then I'd consider figuring out what's wrong or letting the sender know."
• Why you should say it: XML has a reputation for strictness ,but the costs of "reject it and forget it" models can be high, especially if different tools in a chain evolve even slightly different criteria for what information should be in a document. "Be conservative in what you do, be liberal in what you accept from others" — known as Postel's law or the robustness principle — often applies. The most important documents are sometimes the ones that arrive broken.

What tools do you typically use when you're working with XML?

• What most people say: "I love XYZ editor/toolchain, but I'm happy to work with whatever you need."
• What you should say: "I've used a variety of editors and toolchains, I'm not afraid of the raw XML, and I'm eager to explore further."
• Why you should say it: Many organizations have hidden their XML work behind tools, and it's obviously a plus if you know exactly which tool set they're using. However, if they're really hiring you to solve XML problems, as opposed to programming problems that happen to have XML along the way, odds are good you'll have to consider a wide range of possibilities. You'll have to make similar choices around schemas, vocabularies, and stylesheets — and a number of false starts in XML standards demonstrate that the latest isn't necessarily the greatest.

Tell me your feelings about Unicode.

• What most people say: "I can make Unicode documents and data work well. It's gotten a lot easier over the years."
• What you should say: "I can reliably create documents containing Unicode characters and can figure out what happened when someone sends me something that isn't quite right."
• Why you should say it: This has gotten easier over the years, even as people do things like use the Unicode Snowman (U+2603) in their documents. Unfortunately, there's still a lot of human and programming error out there that lets content from other character encodings slip into XML documents, often without labeling it as such. Weird cases include documents in a mix of encodings. Unicode also offers a variety of legal but complicating issues, like representing the same character in multiple ways. If Unicode will be important to the job, you'll need to be able to react appropriately.

What do you think XML is best used for?

• What most people say: "It's good at representing whatever you want it to, though some folks are using JSON now."
• What you should say: "Whatever you do in XML, it's going to be a document format. You can put all kinds of things into that format, but things that are naturally documents will fit most easily."
• Why you should say it: XML exploded into the world because people saw it as a container for anything and everything. As it turned out, there are many data structures and circumstances where XML isn't a good fit. Sometimes JSON or YAML, or even a binary format, is a better idea for complex data. XML comes from the world of loosely structured documents, not tightly structured data, so it offers structural flexibility at the cost of verbosity. If you need that flexibility, XML is likely a great choice.

Though some tools will auto-generate XML, employers will appreciate candidates who know XML inside and out. To boost your value, demonstrate that you know how to use it to improve performance and ease integration for Web services projects. In compiling these questions and answers, we spoke with Simon St. Laurent and  Riley Swenson, CIO at Power Practical, a Utah-based startup that created a camping cook pot that can power electronic devices. If you have other suggestions for questions XML candidates might hear and how they should be answered, add them in the comments below. Image: Wikimedia Commons