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 and so on to spot the true programming talent underneath. You asking implies they don't have that ability and may count against you.

In fact you say "Obviously, these preferences may affect their review criteria heavily" and I think that's completely wrong. I have never counted a person's code exercise poorly because they used camelCase for local variables or indented differently from me. If you tell me you think I will, I'm not flattered. I think both the word heavily and the word obviously are completely wrong and your concern about style is misplaced. Worse, communicating this opinion could offend the interviewer. Be aware. Sure, I want you to write readable code (is there someone who doesn't?) and to care about your code. But subjective preferences like calling a function EmployeeUpdate vs UpdateEmployee? You just haven't seen enough terrible code to think this is what we're judging on.

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.)

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 and so on to spot the true programming talent underneath. You asking implies they don't have that ability and may count against you.

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.

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 and so on to spot the true programming talent underneath. You asking implies they don't have that ability and may count against you.

In fact you say "Obviously, these preferences may affect their review criteria heavily" and I think that's completely wrong. I have never counted a person's code exercise poorly because they used camelCase for local variables or indented differently from me. If you tell me you think I will, I'm not flattered. I think both the word heavily and the word obviously are completely wrong and your concern about style is misplaced. Worse, communicating this opinion could offend the interviewer. Be aware. Sure, I want you to write readable code (is there someone who doesn't?) and to care about your code. But subjective preferences like calling a function EmployeeUpdate vs UpdateEmployee? You just haven't seen enough terrible code to think this is what we're judging on.

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.