Can I ask an interviewer what their preferences are before I work on a technical assignment?

Question

Currently, I am in the process of searching for a job as a software developer. In this field, technical assignments are a popular way for employers to assess candidates. I like this process, but I have a concern.

I get the feeling that interviewers (understandably) have specific subjective preferences that relate to programming paradigms, architectural choices, and so on. These preferences may affect their review process.

As for me, I do have my own subjective preferences as well, but I believe that I am quite adaptable and can write code in dramatically different styles — it really depends on what kind of project I'm working on and who my audience is.

---

The problem is that when I'm submitting code for technical assignments, I don't know who my audience is. The choice of technology often doesn't tell me a lot, because some languages are multi-paradigm (e.g. C# and Scala) and there may be two equally valid ways to use them (e.g. the Java way and the Haskell way). And, overall, I'm terrible at assessing another person's preferences without asking them.

So, whenever I receive an assignment, I run the risk of submitting a solution that the interviewer will dislike, even though I could (and was willing to) submit a solution that they would have liked. This is not the end of the world, of course, but it makes the entire process feel like gambling and a waste of my time (and theirs).

Can I politely require a clarification from the interviewer before I invest time and effort to the assignment, or would that be considered rude? (That clarification would be about what paradigms and practices their ideal solution would follow.) And are there any points I should be careful about in my request?

Answer 1

The answer to this is both yes and no. Some interviewers will be like me. When they give you an assignment they want you to ask questions. In fact, one purpose of the task is to see if you ask questions. (I don't do take home "assignments", this is for an in-person whiteboard interview.) If I give a vague task, it's because I expect you to ask clarifying questions before you begin.

Other interviewers, however, want to minimize their effort in screening out people who can't even code. This is especially true when you've downloaded a task from a web site and are expected to just upload your solution. Answering questions from you does not minimize their effort. So it would be good to come up with specific crisp questions that get you a lot of information at once and make you look smart, not like someone wandering in the wilderness who doesn't know how to do things. These might be:

• do you use a specific style guide? (Optionally add "or should I just use X" where X is some well known style guide in your community.)
• is it ok to use [framework] on this or do you need pure [language]?
• can you give me some context of the larger picture this would fit into (if you're being asked to design an API or some other external interface and need more information to make choices)
• do you have an example of something else from your team so I can use a similar approach to naming and layout?

If the person declines to answer these, they may be telling you that working there wouldn't be great for you. They may be thinking to themselves "this candidate can't make any decisions and is asking me about trivial stuff." They may be proud of themselves and their ability to overlook your style choices, naming conventions, even paradigm choices in some cases, to spot the true programming talent underneath. You asking implies they don't have that ability and may count against you. (Or of course it may show how you are smart enough to know two ways to do it and wise enough to ask which way they prefer. A lot depends on how you word the question.)

Bottom line: if you need information to proceed (eg they didn't tell you what programming language to use or what version of something to target) or you can ask one short easy question like "do you have a style guide you want me to follow" then it is probably safe to ask one question if this is an async thing over email or through a website. Depending on the response, you may feel safe asking another. If this is a whiteboard interview, or a remote pairing session, go ahead and ask as much as you want, that's part of the process.

Try to ask good questions where you can. Compare:

• did you want tests on this as well?

with:

• We're including tests, right? Do you use [test framework]?

Try to frame the questions as "I know a thing, that's good right, should I show you I can do the thing?" and not as "do you want me to thing?" which doesn't confirm you can and will.

Answer 2

As an interviewer, if you asked me questions about what I expected in an answer I would be pleased that you were making sure you understand what I was asking for, unless your questions were stupid. Good questions can show me that you understand that there may be nuisances to the question and tradeoffs in the possible answer. If you asked me questions about those tradeoffs I would be impressed that you know there is not one right way to do something. I think this is true of any good interviewer.

When it comes to opinions about paradigms and architectures You can ask and different interviews will react differently. I would be careful not to steer you towards a particular choice. I would want you to make the decisions. Afterwards we could talk about the choices I would make. Other interviews may be much more willing to give you direction on these decisions. I doubt anyone would hold it for asking these questions. After you gave your answer I would follow up with questions about your answer to make sure you are doing what you believe is the right thing and not what you think I am looking for.

When it comes to qestions of philosophy and judgment make the choices you would make, not the choices you think will please the interviewer.

There are two purposes to an interview:

1. For the company to decide if you are a good fit for the role.
2. For you decide if the company is a good place for you to work.

If you change how you work in the interview to get the job it may work. You will then have to work that way when you get the job. You may be adaptable adaptable enough to do it. However, you will be doing things in ways you wouldn’t pick. There is some compromises like this in every job, however if you are fundamentally have different philosophies on paradigms and architectures you will not be happy. Every day you will have to force your self to work against your judgement. You won’t be able to put your passion into the job.

Instead, let the interview know what you believe. You can both decided the the way the companies works and they way you work are close enough that you can be excited to work there.

Answer 3

If you don't want to ask, I hope that you at least always explain. That's what I do at interviews.

It explains my thought process, every single step of the way, starting by rephrasing my understanding of the problem in my own words, to design decisions, to each line of code as I write it, giving the interviewer a chance to both evaluate me and correct me.

As you said in your question, there can be multiple ways to approach a problem. By explaining, I show the interviewer my thought process, while giving them the opportunity to guide me to a solution which might be more relevant to the project for which I am interviewing.