
Questions to ask your potential employer - stefan_kendall
http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html
======
tptacek
I think this is a thing that everyone goes through in their career at some (or
various) points: you take an inventory of what does and doesn't work about the
roles you've held, and try to turn them into a qualifying questionnaire for
future roles.

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.

------
pasbesoin
The elephant in the room, for many of us: What would be my physical
environment?

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

~~~
mooreds
I think it is OK to ask 'where would I be working? I find I'm most productive
in quieter settings?'

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

~~~
thenerdfiles
If you're trying to remove or drastically limit the human element, _that_ is a
sign that you need to freelance.

~~~
mooreds
Agreed, but limiting the human element (as opposed to 'drastically limiting')
can lead to better productivity.

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-...](http://www.amazon.com/Peopleware-Productive-
Projects-Second-Edition/dp/0932633439)], 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.

------
pbiggar
Coming from the interviewer's standpoint, this is one of the best lists like
this I've seen. Everything is relevant, they're all valuable questions, and
their all fair to ask.

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?

~~~
yitchelle
That is a really good point. It is really important to know that the growth of
the company is planned. I doubt if the company would ever paint a dark picture
of the future of the company. It would either paint it neutral or bright.

------
perlgeek
0) Do you use version control for your code, and if yes, what?

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!

~~~
10098
I would never think of asking this question since I have always just assumed
that if you are building software, you are using version control. Apparently I
was wrong...

~~~
dyadic
I once thought the same, and then I landed at a company where the source was
contained across a mixture of svn, network drives and customer production
servers.

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.

~~~
nilliams
> ... 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!

------
Bahamut
Questions I like to ask as a job candidate:

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

~~~
reinhardt
> \- Can I see the code base?

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?

~~~
rmc
Heck, employers want to see code samples from employees. Why shouldn't
employees be allowed see code samples for what they will be working with.

------
sbov
I don't quite get why internal tools are listed as "beware of". Internal tools
are products too. At game companies they have teams dedicated to building just
them. I'm sure most larger companies do too.

~~~
wtracy
Because you will end up investing a lot of time learning skills that don't
transfer anywhere else.

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.

~~~
quanticle
Yeah. This is one place where startups have a distinct advantage over
established firms. Established firms tend to have home-grown build and
deployment systems, either because they started writing code before open
source versions of those systems became available or because of straight up
NIH. Startups, on the other hand, aren't big enough to tolerate that kind of
wastefulness. They use as much open-source and standardized software as
possible, simply because they don't have the time or manpower to write non-
business code.

------
rch
> Why are you hiring?

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

------
davmar
i've been trying to determine why this list bothers me because it's seems so
reasonable, but i think i found it.

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

~~~
devanti
right on. a large of big companies don't have things like automated testing

~~~
eitally
Or they do, but only in a small niche where a progressive manager made it a
priority and hasn't yet earned consensus among his or her peers. The same
things goes re: NIH at most large companies. It's not that the homegrown tool
is better, but if it's the difference between spending $250k on dev and
$100k/yr on maintenance and improvements versus $1.5m on licensing, $500k on
implementation and change management and another $250k/yr ongoing... those
things get a lot of scrutiny. Especially when they're not driving the profit.
As a couple of examples, let's look at homegrown HR systems vs things like
Workday. Workday is loads better and they are constantly adding new features,
but it is always easy to excuse a homegrown HR system because of innumerable
edge cases in localized employment law, or ties to tiny payroll systems in
third world countries that you've already built but no one else has, or ....
Netsuite is having the same adoption challenges vs Oracle & SAP, too. It's not
that the big guys are objectively better, necessarily, but that they've been
around long enough and have a huge enough consulting arm (and external
partners) to have seen almost every possible business scenario globally.
There's a lot of value there, and it often leads to short sighted and myopic
decisions.

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.

------
seiji
Practical questions that always bite me:

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

~~~
Espressosaurus
Total compensation is what's important, so long as the interval between
payments isn't too long.

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.

~~~
seiji
It's always easy for not-poor-people to say "just have 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.)

~~~
philwelch
If you're making 100,000 salary, you're well off. Incidentally, I find it much
simpler when I get paid once a month.

~~~
seiji
Getting paid once a month solves the entire problem.

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.

~~~
philwelch
It turns out you can dedupe most of your bills into one by paying them with a
credit card. As long as the total amount stays under 4 weeks pay, there are
zero timing issues and you get a month of float plus rewards (cash back,
airline miles) for free.

------
Silhouette
I'm not sure I'd agree with all of these. For example, the ones about
automated testing or building internal tools sound a lot like "Do you like to
work the same way I do?" and if the answer is no then the dubious assumption
is that you know more about what this potential employer does than all of
their existing staff. The list seems reasonable for the most part, though.

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

~~~
novaleaf
I totally agree with this. I personally do not use unit tests at all.

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

~~~
ababab
Could you expand on what you mean by assert-driven testing? I'm not finding
any good explanations from a Google search. Sounds interesting.

~~~
throwaway1979
My GUESS was that he/she means that the code has asserts in it that check if
something is not right at runtime. I personally would not call that a
replacement/alternative for unit tests. In fact, it may be counterproductive
... a small error in the code would bring down and entire application.

~~~
novaleaf
i would counter this by saying that a small error in code SHOULD bring down
the entire application.... during development. otherwise the error is not
visible to developers when they can best/easiest fix it.

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.

------
Bahamut
In my case in my last interview, I asked to see some of the codebase. It was a
less than ideal situation, and there were no unit tests for the frontend.
However, I saw it as an opportunity to make an immediate impact on the dev
process.

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.

------
dylam
I agree with most of the things here except for the last part of no. 9:

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

------
edw519
Excellent 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.

~~~
joezydeco
\- What will I be doing the first week I'm here?

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.

~~~
rmc
a "goat rodeo"?! I think I'm missing the analogy, can you explain?

~~~
joezydeco
Chaos.

------
brianmcconnell
I would add a question about vacation policy as a signal about whether you
want to work there.

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.

~~~
mfringel
"Four weeks, use it or lose it" wouldn't tell me whether people actually used
the vacation or not... which is a somewhat harder question to phrase.

~~~
eru
At my current job, I have five weeks plus, and two of them are mandatory.

------
mcenedella
This is a terrific developer-specific list. The realism about acceptable
answers is quite good.

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?

~~~
dinkumthinkum
Your #2 sort of bothers me. Actually, a lot of these seem like "answers" to a
school assignment about what to ask an employer ... Also, would you really ask
all this? You put a lot of work into this.

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

~~~
PeterisP
Most other questions may seem too verbose to actually ask in a short
interview, but the #2 is a key question that should be asked always. Most
likely will tell you more about the actual job contents (i.e., which task
you'll be required to focus on) than everything else; and asking it early is
key to avoid a mismatch in expectations.

~~~
dinkumthinkum
How do you earn a gold star should always be asked.

------
tokenrove
Ten or fifteen years ago one of the fastest make or break questions I would
ask was "what version control system do you use?" (and of course, whether they
were using nothing(!) or ClearCase or VSS or CVS would immediately say a lot
about the culture there); version control is ubiquitous now even in lousy
companies, so I think "what is your code review process?" is my new favorite
question to get some indicators of the development culture at a company.

~~~
rmc
Even now, version control can tell you a lot. An organisation _still_ use CVS,
or even SVN, will tell you something.

------
tgrass
To filter for those managers who will never be happy with anyone's work ask:
"Who is your favorite employee? Why? How do you motivate them?"

~~~
jerryr
I like the intent of this, but I'm not sure I'd ask "who", specifically. I
personally would not feel comfortable answering that part of the question.
Instead maybe, "How do you motivate your favorite employee?" If the answer is
vague or too broad, the manager probably hasn't identified a favorite
employee.

------
jakejake
These are all really good questions. I think it's a great idea to have some
questions in mind when you interview. It shows that you are interested in
making an investment in a company and not just looking for a paycheck.

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!

------
namenotrequired
11\. What's your reason for working here?

------
btilly
I prefer questions that are specific, verifiable, and relevant to me. When
they are specific and formatted differently, interviewers will often surprise
themselves by being honest. Furthermore if there is anything that would be a
deal breaker, you need to ask up front.

"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?"

------
raverbashing
Good list. N. 2 is a good catch really.

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)

------
j1z0
Given that I run a consulting company I spend a fair amount of time on each
side of the interview table. Both recruiting for contractors to help with a
project and trying to convince others that I'm the right guy / company to
develop the system.

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

------
erikb
I like the list. Just for me personally there are some differences. From
experiences I like chaos more then organization, because I can make more out
of the chaos for myself. I don't feel so well today? Well in a chaotic company
I can just stay home or answer emails. When I feel energetic I can also
convince my coworkers to get a major feature done or an ugly bug fixed that
was laying around for months.

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!

------
dsr_
I've never interviewed a candidate in person and not given them at least 20%
of the scheduled time to ask questions about the company. I have only once
accepted an offer from a company that didn't offer me a similar opportunity,
and that acceptance was a major mistake.

------
aabalkan
Take a look at this post for specifically web developer positions:

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

------
human_error
I had a job interview two days ago and the manager covered the first 9
questions before I asked (I had 1,2,3,4 and 6 on mind but he talked about all
of those topics). I don't know if it's a good sign or a bad sign though.

~~~
namenotrequired
I'd say that depends on whether you liked the answers or not :)

------
alex_hitchins
I think another important question to ask is will they will let you speak to
the current team(s) and ask them questions. In my experience they are more
likely to give honest answers.

~~~
sethammons
or just interview at a place where the teams do the interviewing, like where I
work ;)

------
kapilkaisare
Instead of asking "What's the process like?", I'd try to avoid a buzzword-ed
answer by asking instead "How long is an iteration? How are your teams
structured (flat vs hierarchical)? Does each team have its own tester, or is
there a separate QA division in the company?"

------
rmc
Interview are not just a company evaluation a prospective employee, they are
also a person evaluating a prospective employer.

------
seivan
Regarding #2 what if a person wants to be both. What should one ask then?

------
jkbyc
The list may be good but I find this writing style off-putting

------
ye
> _We don 't have tests. - Get out_

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.

~~~
bowlofpetunias
This applies to virtually any item on that list. The questions are good, but
the lack of ambition bothers me.

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.

~~~
quanticle
There's a _huge_ difference between "we don't have tests and we don't see the
value in automated testing", and "we don't have tests right now, but automated
testing and process improvements are something we're working on". I suspect
you're talking about the latter, whereas OP is talking about the former.

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.

------
thenerdfiles
"Do you use presentational CSS classes in markup, or do you fully utilize
LESS/SASS?"

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.

~~~
zalew
Low level implementation details are relevant questions for getting a
freelance programming assignment of taking over an existing project, not a
full-time contract and especially not one at a bigco. IMO asking such
questions tells you are religious about petty stuff instead of looking at the
bigger picture and focusing on the deliverables. Being curious about team
structure, general project management and development practices is great, as
it shows interest in your possible future working environment, but picking on
tools and discriminating against minor tech solutions is a bit naive from my
perspective.

~~~
dinkumthinkum
I agree. I had a "Oh, here we go" reaction.

~~~
thenerdfiles
It's effectively asking a coding style question. How is this not fair?

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

