The job is a mixed programming and tech support position at a small software company that does software for the real estate market. The company makes back end software, and other companies have to produce software that interacts with it.
The question is: “Describe how you would handle email support.”
The problem is that it’s such an open-ended question, I don’t know what approach to take.
I think they’re asking for things like how you would prioritize issues, like site wide vs. individual, what you would check first, how you troubleshoot, typical failures you’ve solved, how you would document the problem and resolution, and communication to close and follow up? At least that’s what I would want to know. Add in some proactive checklists for users to go through before reporting and they’ll like that way of thinking, even if they don’t do it.
From my experience, you don’t want a position where you are both programming and providing direct tech support. Otherwise your day will be spent constantly putting out one fire after another. And it will get progressively worse as you will face increasing pressure to apply quick Band Aid fixes without proper documentation, QA or coding standards. Typically you will get at least one troublesome customer who makes the most noise and will turn you into their private IT resource.
Everyone likes to joke about the “people person” guy in Office Space who brings the requirements to the engineers. The reason that guy exists is not because the engineers can’t do it themselves. It’s so they don’t have to.
Another thing I’d suggest (which is something I do) is that I’d create templates/signatures with common responses, to save time typing out the same response to multiple queries.
If I got that question in an interview, my response would be “That’s a very open-ended question. Could you be more specific?”. If they couldn’t or wouldn’t, I would say “In that case, my answer is that I would handle it competently and efficiently.”.
Well, yes, of course it is open-ended, and probably deliberately so. They left the question that way to get you talking in general to see what you say. Therefore, I would treat the question as an opportunity to do some shameless, but specific, bragging.
“I can tell you of an instance where I handled e-mail support. I read a thread of e-mail and its responses, and I did so from newest to oldest, in reverse order. By doing so, I could tell that they were talking at cross-purposes. So I was able to respond to the real problem, and that caused a lot of the noise and confusion to subside and I could cut right to the real problem. I got the issue resolved rather quickly after that - the customer was delighted, and so was I.”
Or -
“One of the skills I developed was a feel for when an issue can be handled via e-mail, and what needs a phone call. Things are easier to misunderstand or misinterpret in e-mail that are much clearer when you can hear a voice. An example of this is…(blah blah blah anecdote that makes you look like a champion etc.).”
Develop the knack of being able to drag any question into an opportunity to show off.
I would say make sure to respond to each email in some way rapidly, and have a system to prioritize and schedule all of the current requests so you can give the customers some idea of when they would receive a solution for their problem. The highest priority requests should receive immediate attention, and a response by phone if that is feasible. In any case the first step is to clearly establish what the customer needs, and then make sure the resources are available to provide a solution. Only the simplest questions of pure factual nature would be given a link to some website or documentation, all others would be considered serious matters requiring investigation and any proposed solutions should be tested and verified before providing them to the customer. In all correspondence the customer should feel that their request is being taken seriously and handled with the urgency due for the circumstances.
I’ve had that job at a couple different security software vendors. Here’s how I’d approach that question:
Check that the customer is entitled to support. Do they have a valid maintenance contract?
Have a template you can use for standard information gathering. What version of the product? What platform? What error messages do you see. But only send the customer the questions that they didn’t already answer. It makes you look like a robot if you ask for things that have already been provided.
Prioritize the work according to SLA.
Keep the language professional and neutral. That is, don’t use slang or colloquialisms that a foreign customer may not understand.
Be careful not to cross-contaminate internal email discussions about the issue with customer communications.
If the email system isn’t already integrated with the CRM system work out a method to make sure all customer communication is saved.
Big picture: Small company = few / no established bureaucratic systems. Each employee must self-organize their work & their interface to others in the company. The polar opposite from a big company where the right answer is “I’d look the procedure up in the book & follow it precisely.”
Having done interviewing for developers & QA for a small software company I was mostly interested in how well they could self-manage. Not so much in exactly which choices they’d make, but that they’d even recognize the need for choices.
We had lots of candidates that had worked as long-term temps for the major corporations in town. And who had years of experience putting a single cherry on each sundae on the assembly line so to speak. Those folks were useless. To us.
Don’t be that guy.
ETA since I forgot to refresh before posting: As msmith537 said, this kind of split job can be a real trap. But for most small businesses it just comes with the territory. If they have enough support / devs it works. If not, not. Any business can be under-resourced. The mere fact this outfit has split roles doesn’t guarantee that’s the case.
See, to me, the question is about supporting their email system not answering emails from customers. i.e. patching servers, setting archiving policies, etc…