That's fine as far as it goes, but one of the things you'll learn as you progress is that superficial process issues are actually not at the core of effectiveness; talent, vision, and ability to execute are. You want to be careful that your questionnaires don't blind you to opportunities to work in radically different cultures/processes that will succeed for reasons you don't yet understand.

I like a challenging problem. I don't like fighting a bunch of extraneous noise and distraction while trying to concentrate on it. (Collaboration is just fine. Noise is not.)

I've yet to see a clear formula for addressing this concern in a neutral fashion (or, perceived as neutral or acceptable).

Any interviewer that is offended by this seems like they work for a company worth avoiding.

But most developers work better in offices with doors that shut (at least according to what I remember of Peopleware [http://www.amazon.com/Peopleware-Productive-Projects-Second-...], though that was published before IM was everywhere).

So I think acknowledging that you work better with quiet, and framing it as 'I want to be as effective as I can', is fine.

It can even open up a discussion on true effectiveness--if I am writing tons of great code because it is quiet, but you could have saved me 8 hours of code writing because of a library you know about or wrote, am I as effective as I could be (no). This is the quiet end of the spectrum.

The loud end is the bullpen with no headphones, where it can be very difficult to think.

As the sort of work they are doing becomes more computer/technicly based - they have to change to be able to properly execute - you cant just pick up the phone and bully the printers any more.

I would add that you should ask questions about the employer's business too, especially at a startup. How do you make money? When will you be profitable? What's your direction?

If they say "no" or "RCS", politely say that you don't want to be a part of that dev team. Unless they hire you as the only developer, and you see real chances of introducing some sanity.

This is not just about the way they store code; it's about the attitude towards tools. If they aren't aware of source/version control, or are aware but don't care, experience shows that they will be a huge pain to work with. Know a perfectly fine, open source library that does 90% of that task? Have fun getting permission to use it!

At another job they just had a shared drive with a single copy of each project and mandated we use a particular editor because it had an in-built locking scheme. There were a few conditions (e.g. crashes) that required manual lock manipulation before you could accomplish anything. People would often manually release locks out of habit, open a file for writing but just leave it open all day in the background while the lock-holder worked, save the old copy when they were closing up at the end of the day, thereby reverting a day's progress. There was no backup strategy in place. This wasn't the 90s or anything, git and GitHub were already established.

However, I don't directly ask about VCS now, it seems overly focused for a question, instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.

That's a good approach, noted!

I tried to make the team switch to something like Git or hell - even SVN - something to manage the code and not have it all in one point of failure but that fell on deaf ears.

Ultimately I create a private repository on Bitbucket and pushed the code there using Git and used that as my personal backup in case shit hit the fan.

- Can I see the code base? (it lets me see a bit of app structure, code style, etc.)

- How is the company doing business-wise? (I like to see big success indicators like rapid growth)

- How flexible is the employer with regards to having to take emergency and/or scheduled time off work without being penalized for vacation (i.e. waiting for a package, or specific to me, reserve duty in the military)?

- How do you see me fitting in with the company initially? (I am flexible, but I would like to know what role I am being hired for, as job descriptions are often opaque or misleading)

Unspoken questions I'm looking to have answered by coming in for an interview as a job candidate:

- What is the dynamic between employees?

- What is the company culture?

- How intense is work at the place typically? (just for personal gauging purposes - this isn't a make or break thing, but it's something I want to know)

- Does the workplace treat its employees well? (do the employees look happy to be there?)

- How transparent is a company when answering my questions? Are the responses detailed? Is there something that is being hidden from me?

There are probably more questions I tend to want answered that are never spoken, but incumbent on me to take note of through observations. As a job seeker, you owe it to yourself to be as sharp as possible about your own future.

I've often wanted to ask this but didn't have the nerve to do it. Even if it doesn't raise some eyebrows, are there companies that actually say yes?

I was obviously not looking to steal code, and I was a candidate that was "interviewed" by only tech leads - I think I asked more questions than they did, and I kept the discussion very respectful.

Good, well developed internal tools which speed up company work in a way that something off the shelf cannot, can be a good thing. Even the best internal tools, however, will require some ramp-up time for someone joining the company to understand and use them to their full potential. They require developing in the first place. The gains must be able to justify the costs, which even a good tool cannot always do due to the limited consumer base of an internal tool.

In less ideal circumstances, they can be unholy buggy unsustainable messes that actively sap resources for maintenance and are worse in many if not all respects than cheap off-the-shelf alternatives, even for the company's own specific needs. They may be kept alive by the difficulty of transitioning, other internal tools depending upon it, or misplaced attachments to the system ("we've invested too much into it to switch now!" etc.) or misguided approach to tools in general ("licenses are expensive, let's just build our own.")

But a large company probably has at least one unessential tool meeting a need better filled by something off the shelf, just by a matter of statistics. There can be all sorts of legitimate reasons this happened other than NIH Syndrome (it predated the off-the-shelf solution, it couldn't be found despite research, regulatory requirements, etc.) but NIH Syndrome is one to watch out for.

Two of the last three companies I've worked at had their own internal version control systems. I'm sick of having to learn how to check code in all over again every time I start a new job.

On the other hand, if you ever find a company that wrote their own VCS 3 years ago that has half the features of Git, then run far and run fast!

I think it's usually fairly easy to tell which person is which. (Person is either a bullshitter you can quickly catch out, or is smart and inspiring to talk to).

But he does have a point in that the majority of rewrites are not significant improvements; you have to look more closely to evaluate this.

This is a good one to ask, but tricky sometimes. I've heard answers along the lines of 'we keep positions open perpetually' for architects, systems analysts, data scientists, and the like. So I think to myself, that's great! It is fun to think I'll be a valued hire, and the friend who brought me in will eligible for a nice referral bonus. However, I am starting to think that if a company appropriately values experienced, talented leadership in the most challenging sectors of development, then these roles don't need to be 'always open' any more than entry level positions. My guess is that there's always a catch with companies that give this answer.

So what's a good answer? I'd prefer: 'we weren't hiring, but X thought we should meet you.'

this list helps you identify a "goldilocks" product company. it's narrowly targeted at a specific subset of product-based companies at a specific growth stage with a very opinionated view of how the company should be organized.

try answering any of these questions from the shoes of microsoft or a no-name early stage startup. you cannot win in either case. i can only see a company like airbnb or dropbox succeeding in answering these questions to his satisfaction.

kudos to the author for knowing what he wants and what makes him happy. i think candidates will most likely need to compromise on more than a couple of these points with most companies they interview with.

edit: i absolutely agree that candidates should interview the employer as much as they are interviewed. and i think this list is very good. what bothers me is that it's hard to answer positively to all these questions, so flexibility on the part of the candidate is probably an important thing :)

I don't actually know that this is true, but I suspect the vast majority of programmers work for large, non-software-product companies, and most of them spend their time primarily on KTLO work, not any kind of innovation or profit creation.

- When do we get paid? Every two weeks or twice a month? Every two weeks means your pay is essentially reduced by two entire paychecks. With "twice a month" your paycheck is $NET_SALARY/24. With "every two weeks" your paycheck is $NET_SALARY/26, meaning two months out of the year, you'll get three pay checks. But--the rest of the year, your salary is essentially reduced by ($NET_SALARY/26 * 2). You can't create a monthly budget out of two pay checks you get twice a year, six months apart.

Realistically, you aren't going to not go with an employer because they pay 26 times a year instead of 24. It's just something to be aware of since it reduces your practical salary by two entire paychecks.

- Are benefits included? It's a mild disappointing cognitive change to go from a job that pays full benefits to one that makes you pay $100/month for them.

- Meals/snacks/fruit? It's another mild disappointing cognitive change going from a company catering two meals a day to one charging $2 for a water from a third party vending machine.

- Are you lumping any bonuses in with the full salary you're offering? Be careful of HR starting your conversation with "Your total compensation is $80,000 per year" when they then mumble "That's a $45,000 base and a $35,000 bonus, paid out yearly at the end of your hire date anniversary." Your huge total comp package may make your ego feel good, but you can't budget against end of year bonuses.

- Stock is always imaginary unless you're at a public company. Always try to double or triple the base "options" they offer. Be wary of places that do 25% cliffs instead of 50% cliffs. 25% cliffs are just silly.

If you have to sweat the difference between being paid twice a month and every two weeks, you need to start saving yourself more of a cushion.

Let's use an example. Assume $100,000 salary, pre-tax. Post-tax, let's assume your net salary is $74,000.

For being paid twice a month (15th and last day of the month), each pay check will be $3,000 (we're rounding up here). Each month you'll have $6,000 to spend.

For being paid every two weeks (every other Friday), each pay check will be $2770. Each month you'll have $5540 to spend ($460 less than the twice a month schedule). Except—two months out of the year, you'll get a third $2770 paycheck, giving you $8310 to spend in those two months.

It's just... weird. What's the difference? A car payment or a student loan payment or extra food or insurance premiums or parking or transit or anything you can spend $460/month on. Sure, to a well off person $460/month may not sound like much, but it adds up when it's taken out every month and only paid back in lump sums twice a year. (My entire point being: you can't form your monthly budget to include lump payments six months in the future.)

The only reason this whole pay period thing matters is because bills (rent, car payment, insurance, utilities, iPhone bill) tend to be due monthly and not every two weeks.

And if that bonus isn't guaranteed, then you're not even getting that.

Am I missing something there? To me, this is only a concern for someone living paycheck to paycheck and that generally doesn't seem to be an issue for software developers.

Aside from obvious questions about the kinds of projects you'd be working on and the skills and technologies involved, I used to rely on a few simple tests:

1. What is the employee turnover like, and if people have left recently, why? [This is a reasonably objective proxy for what the rank and file staff really think, and they collectively know this potential employer much better than me.]

2. Did they ask brain teaser type questions or do a pop-psych personality test in the interview? [Do their hiring practices suck, in which case even if they hired me, would I want to work with anyone else they hired? Also tends to indicate an unhealthy assumption of superiority and desire to conduct one-sided interviews, which is a red flag in its own right.]

3. Will they show me a sample of their production code and of the related documentation, and if so, what is it like? [If they won't and don't have a very good reason, my assumption is that they aren't confident their code will impress, which is not a good sign. If they will, what I see is about as good a marker for whether they're any good technically as any benchmark you can fit into an interview.]

4. What does the car park look like on the way in? [Far from scientific, but a handful of executive cars in reserved spaces and then nothing but old models in the few remaining spaces is rarely a good sign.]

5. Does the contract impose on my life outside of work? For example, would I need permission from the employer to take on an unrelated side job that had no bearing on my ability to work properly for them? Would they be claiming IP rights to any work I did unrelated to that employment, so that for example I couldn't release a hobby project as Open Source if I wanted to? [Any attempt to control life completely outside work is a fairly reliable red flag for a generally over-controlling attitude and/or a show run by HR/legal rather than sensible management or the people I'd actually be working with.]

Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.

That's totally different from an organisation that doesn't do tests at all (yes they exist).

so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)

so I'm not saying there are no scenarios, but they all end up being the customer facing scenarios, and verifying those meet expectations. Also just developers making sure the functionality "works" naturally catches the technical bugs (because asserts in production code would cause the app to crash)

You might also want to explore QuickCheck, which helps to generate these scenarios.

of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.

but during development, I'd say crashing during small errors is a great thing.

A simple example can be done by writing a single function in the root scope or some global function (javascript)

function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }

Then in a function in your application:

function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);

\\Continue code... }

This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P

Some systems have something like this built in, such as node which has more features.

http://nodejs.org/api/assert.html

You appear to be making your own questionable assumption, which is that the techniques mentioned before necessarily imply a more mature software development process. If a development team didn't use automated testing, I'd certainly be interested to know why, but I can immediately think of multiple plausible alternatives that might have proven to be more effective for that team depending on the circumstances. Unlike the use of brain teasers and popular psychology to assess applicants' value as employees in technical fields, there is a significant body of empirical data to back up the effectiveness of some of those alternative testing strategies.

All three have a strong track record of finding bugs when implemented well. All three also add significant overheads, so there is a cost/benefit ratio to be determined. The relative costs of implementing each strategy will surely vary a lot depending on the nature of any given project. The benefit for any of them would likely be significant for a project that didn't have robust quality controls in place, but you'd get diminishing returns using more than one at once.

I could easily believe that skilled developers had evaluated their options and determined that for their project some other strategy or combination of strategies provided good results without routine use of automated testing and that the additional overhead of adding the automation as well wasn't justified.

I ended up accepting the job, but I knew what situation I was entering and what to do to make a difference. Suffice it to say, it has been a great experience for all parties involved, and we took a demo and shipped a major product in under 2 months while solving many critical issues along the way, paving the road for smoother development in other concurrent & future projects.

"Beware of "I built an internal tool that..." or "I built a flux capaciting tool that..." or "I rewrote an open source tool because...". Some developers like to jerk off to rebuilding the wheel and wasting business money on projects that strictly aren't required or useful to the business as a whole. Like I said, I like to build products. If you feel like you needed to rewrite the compiler, you're probably awful, and almost certainly wrong."

What about DevOps and people who work on improving the work flow for other developers?

Otherwise, great list.

A few more:

- What will my typical day be like? (The answer will always start with "We don't have a typical day." So you say, "I know. Describe it as if there were one.")

- What will my life be like in 6 months? One year?

- What's the worst thing that can happen in the next 6 months? Next year?

- What's the probability we'll achieve our goals in the next 6 months? Next year?

Don't depend upon the answers but expect some very insightful discussion.

If you get an answer like "you'll be setting up your development machine and loading/building the A-12 project to get a feel for our servers and systems", that's good. You also have your first assignment when you show up and your boss is too busy to guide you around.

If you get a shrug and something more nebulous, press harder. If they can't answer, expect a goat rodeo when you start.

Wrong answers: two weeks, or "unlimited" (because everyone knows there will be peer pressure not to use vacation time).

Right answer: four weeks, use it or lose it (as in, we want you to check out for a proper vacay a few times a year).

The definition of vacation = I am going to be on a beach/wherever, not checking email, probably drinking, and definitely not thinking about work.

Location is also important. If you have a 2-3 hour round trip commute each day, you'll hate your job no matter how interesting the work is.

A "real" unlimited vacation policy is a strong positive signal about the company. It shows that (a) people are trusted to manage their own time and not to abuse the system and (b) the people who work there are good enough and driven enough to deserve that trust.

"Unlimited" holidays is a scam, unless they'll put in writing that you're entitled to 6 months holiday per year.

Here's my own list of 20 interview questions, from a more generic business / process / employee life perspective:

1. What's the biggest change your group has gone through in the last year? Does your group feel like the recession is over and things are getting better, or are things still pretty bleak?

2. If I get the job, how do I earn a "gold star" on my performance review? What are the key accomplishments you'd like to see in this role over the next year?

3. What's your (or my future boss') leadership style?

4. About which competitor are you most worried?

5. How does sales / operations / technology / marketing / finance work around here? (I.e., groups other than the one you're looking to work in.)

6. What type of people are successful here? What type of people are not?

7. What's one thing that's key to this company's success that somebody from outside the company wouldn't know about?

8. How did you get your start in this industry? Why do you stay?

9. What are your group's best and worst working relationships with other groups in the company?

10. What keeps you up at night? What's your biggest worry these days?

11. What's the timeline for making a decision on this position? When should I get back in touch with you?

12. These are tough economic times, and every position is precious when it comes to the budget. Why did you decide to hire somebody for this position instead of the many other roles / jobs you could have hired for? What about this position made your prioritize it over others?

13. What is your reward system? Is it a star system / team-oriented / equity-based / bonus-based / "attaboy!"-based? Why is that your reward system? What do you guys hope to get out of it, and what actually happens when you put it into practice? What are the positives and the negatives of your reward system? If you could change any one thing, what would it be?

14. What information is shared with the employees (revenues, costs, operating metrics)? Is this an open-book shop, or do you play it closer to the vest? How is information shared? How do I get access to the information I need to be successful in this job?

15. If we have a very successful 2015, what would that look like? What will have have happened over the next 12 months? How does this position help achieve that?

16. How does the company / my future boss do performance reviews? How do I make the most of the performance review process to ensure that I'm doing the best I can for the company?

17. What is the rhythm to the work around here? Is there a time of year that it's all hands on deck and we're pulling all-nighters, or is it pretty consistent throughout the year? How about during the week / month? Is it pretty evenly spread throughout the week / month, or are there crunch days?

18. What type of industry / functional / skills-based experience and background are you looking for in the person who will fill this position? What would the "perfect" candidate look like? How do you assess my experience in comparison? What gaps do you see?

19. In my career, I've primarily enjoyed working with big / small / growing / independent / private / public / family-run companies. If that's the case, how successful will I be at your firm?

20. Who are the heroes at your company? What characteristics do the people who are most celebrated have in common with each other? Conversely, what are the characteristics that are common to the promising people you hired, but who then flamed out and failed or left? As I'm considering whether or not I'd be successful here, how should I think about the experiences of the heroes and of the flame-outs?

If someone asked me this stuff, I would thank them and probably go on a vacation to forget the whole experience.

I think it's a little strangely phrased (sounds a bit obsequious), but I think it's a valid and important question.

As a candidate, I always ask what would make my future boss count hiring me an awesome decision. Also, it's really interesting when different interviewers answer the question differently; I've been in the middle of a job I quit after a year where different decision makers thought the role should be different things, and it sucked.

The key to asking #2 is to be more 'Vince Vaughan' than 'Steve Buscemi' in your approach. More butt-kicker than butt-kisser, if that makes sense.

http://github.com/ChiperSoft/InterviewThis

You can see all my stuff here: http://www.theladders.com/career-newsletters

This particular newsletter is here: http://www.theladders.com/career-newsletters/it-s-not-about-...

I would probably spread these questions out over a few people and not hit the same person with 20 questions. I would also be cautious of making the interviewer feel embarrassed if they are not following SCRUM to the letter with 100% automated testing and code coverage. Because in real world situations we are often striving for that but we don't always get to do it perfectly by the book. So it won't help if you make them feel even worse about it!

"Why and when did the last three people who left, leave?"

"How big is the team?"

"Due to family responsibilities, I need to work an odd schedule. How open are you to letting me start at noon and then work a full day?"

I would add another question. What's the development stack like. And by that I don't mean N.4

What I mean is: What's your source control system, bug tracker, (possibly) IDE/Editor, (possibly) other tools/environmental issues depending on the area (more usual in specific areas, embedded software for example)

That being said I think this list of questions is excellent. I would be much more inclined to hire someone who asked these questions than someone that didn't.

Somewhat conversely as an interviewee I would be at least slightly concerned with a company if I had to ask these questions. This is basic ground that any good interviewer should cover in an interview and if thy don't they may not be looking for the type of development styles that I like most.

Interviewing is a two way thing both sides should be choosey and neither side should settle for something less than ideal. If we all found jobs / employee that we love then the workplace would be some much better off for it

Also from some of my colleagues I see that not everybody is really interested in delivering results. Some are just fine with doing what they are told, then going home and caring about their family. When the whole department/company thinks like that, then the life of these people is much better. It's definitely not for every engineer, but I think it's good such spaces are out there!

"Questions to ask your future web dev employer" https://medium.com/what-i-learned-building/f7a161b5bc70

Maybe it's an opportunity to introduce automated testing.

I've worked at many companies where my managers wouldn't allot any time to develop automated tests and change the deployment to accommodate them.

Many companies are just not aware, because they never hired the people who are familiar with automated testing.

Established shops mean established culture. If it doesn't already exist, and you aren't in a position of sufficient authority to make it happen without buy-in, this "opportunity" is probably more likely to be bailing out the ocean.

I've been at a company with thousands of developers, where a guy that was just hired came in, saw a need for a tool that had been missing, prototyped something, and showed how useful it could be.

When there are missing needs like this, it's a tremendous opportunity for someone who is sufficiently motivated.

Of course, there's a balance between a good company that is just missing some things here and there, and a very bad company that is missing just about everything...

There's a significant difference in difficulty between building a tool and institutionalizing a labor-intensive (though very valuable) process. And given the surplus of developer jobs out there, it's probably easier, and better, to just move on to your next option.

I work at a relatively large technology company (Bloomberg) and I have had great success in changing developer culture for the better. It takes a lot of elbow grease, many meetings and you need the gumption to ride through it but we've truly made the day-to-day productivity enhancements that we need for our business. In just this year my team has accomplished:

> GitHub Enterprise deployment;

> Massive project conversions from Ruby 1.8.7 to 1.9.3;

> Adoption and training of AngularJS building reusable directives;

> Utilizing Boxen to make developer work environments reproducible and deterministic;

> Consolidating build systems (Jenkins) and integration with corporate internal systems;

We're really on a roll and I think once you gain the trust of management and they see the moral changing for the better you can really stop the world. But coming in from the outside I can see how this is intimidating and, roughly speaking, you need to consider most organizations are not going to give you the keys to the castle with merely blind faith. You need to disrupt a bit.

I've been there, man; I'm not exactly saying something I haven't tried. :-)

"Intimidating" isn't the right word, though. "Vastly unlikely" is probably closer to where I'm standing. Unlikely to the point where the downside risk--being stuck at a job with regressive coworkers and management who doesn't want to change anything--probably outweighs, for most people on HN, the potential upside given that they probably have other options.

I could go in and risk my time and my earning potential to change things somewhere, or I could go to the next place with their head on straight.

But maybe that's just me, I would always prefer to work at the place that isn't 100% perfect but will give me the opportunity to change things. Much more of challenge in that than just being a replacement cog in an already perfectly tuned machine.

Culture is a lot harder to change than code. If the people already there don't see the value in process improvement, then attempting to introduce any sort of process improvement will be a Sisyphean task. You'll make progress only to see it get rolled back time and again by teammates who just don't believe in what you're doing.

Take automated tests as an example. I have worked at a place where I committed automated tests and configured them to run before build. Then, I got a bug report for a module I had worked on and wrote a test suite for. The test suite should have caught the bug... had it not been disabled by another developer who'd committed the breaking change and, instead of investigating why the test failed, just dropped @ignore annotations until the tests passed again. That's the sort of thing that OP is warning against. Life isn't long enough to spend time bashing your head into walls like that.

The lack of testing culture, for example, was what first drove me away from PHP (to Ruby). Every PHP role interview, I'd gingerly have to ask if they knew what Automated Testing was ("Yes? Great. Have you done any yet? ... No? You don't want to? Oh."), whereas at every interview for a Ruby role I've basically gotten a "Of course we're testing. What else would you be doing?" response.

Once you get past talking about things up to the baseline, you can start the real interview.

Sure, but this is why you ask a follow up question, "why don't you have tests?"

If the answer is "We are just starting this project, and haven't done any yet. We'd like you to help us write tests", then that's an oppertunity.

If the answer is "Tests don't work, they're useless and never catch serious bugs. Our team is smart enough to not break things, and we have to move too fast to waste time write silly little unittests for everything", then there's no oppertunity here.

I think the answer here will explain everything. (Does this employer know/care? Am I about to dive into legacy practices? What does the bottom floor of the codebase look like?)

It draws a line.

Is asking coding style "religious"? I must argue: "That's, like, your opinion, man!"

> know/care

This is an implied project management question. (1) Can the employer even speak to it? (2) Does the employer see those who specialize on these areas as less important than other areas, in that they are fine with having no opinion on the matter?

> legacy practices

Did you not see this?

I picked HTML and (presentational) CSS (classes) for a reason, as they are boilerplate and they indicate whether or not Separation of Concerns bubbles up to management. Questions about HTML minification, the whole point behind preprocessed languages, etc. can be teased out with just one question.

It's like breaking into a network, looking at the codebase, and then combing for organizational and sociological judgments based on what you see. (LESS/SASS will comparatively more likely be documented. That said, would you take on an employer that leaves undocumented what can most easily be documented? — so it's likely they have lots of throw-away, unreadable, undocumented CSS. Do you want to work for an employer that is okay with "throw-away, unreadable, undocumented"?)

HTML is the lingua franca of the Web. Would you honestly work for an employer that calls this "petty stuff"? Tell me that. It's a tech interview both ways.

What if the employer responds, "That's petty stuff. We hire you to make that decision. We don't care. See the forest"?

You can find any person on the street who might say this. So why are you dolled up in a suit and tie yet again to be told "What you care about is irrelevant"?

Or what if the employer says, "I don't really know, but I'm glad you think about very finely detailed problems..."?

Generally my belief is that interview questions should fish or have the structure of getting you hired on the spot (http://pbfcomics.com/81/), where in asking them you've maximally described yourself but minimally given the employer the opportunity to fail. (Again, you don't care about your lingua franca of the Web? Go hire someone who has no opinion on this like you do.)

One positive thing that comes from your example is, if they know too much about that it means there is a whole lot of micro-management going on.

We like dialogue, as socially conscious beings.

Look at what the question contains: "presentational CSS classes in the markup". That's Separation of Concerns, not "stylesheets."

You're begging the question. And it's one question that can easily be generalized as a format-question: look at the operative words "use" and "utilize". Look at where they appear in the sentence.

Are those even exclusive?

One of the projects I work with uses Ace “responsive admin template” (paid theme from Wrapbootstrap). In its styles, declared variables and nesting are used unpredictably, as is indentation and other whitespace, which leads to awful readability and flexibility. It does utilize LESS, but it also uses presentational classes (least of its problems).

Pure well-structured CSS can be much better. LESS offers some useful possibilities, but also a lot of new ways to shoot yourself in the foot.

My point is—what OP wants (I guess it's readable, elegant, maintainable code) depends more on coding standards than tools used.

It's a fishing question.