vcavallo · September 21, 2015 18:36
diff --git a/questions-for-employers.txt b/questions-for-employers.txt
 Comments: "stefankendall.com: 10 questions to ask your potential employer"

 URL: http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html


 The interview is all too often driven by the employer. Can you handle this workload? What are your strengths and weaknesses? How do you feel about this aspect of the business?
 But at the end of the interview, you do not know enough to know if you will actually love and enjoy the work. How many developers or designers do you know who have worked at a place for less than a year? Less than 9 months? I bet more than a few.

 Here's some questions you should ask before committing a significant portion of your life to a company.

 1.) What's the process like? How do you build software? Do you describe yourself as "lean", "agile", or "scrum"?

 This can make or break a position. If the work culture hasn't been somewhat formalized, you might be entering a position where your main job is managing the chaos. If a company thinks they're doing "lean" or "agile", this might mean you're walking into a formalized reasonable process, or it could mean that you spend half your time in meetings with decks of cards arbitrarily assigning cost to problems. The most important thing is that someone, at some time, has consciously decided how work is developed at the company, and it makes sense. Be cautious of too many buzz words.
 2.) How do designers work with developers?

 Do they even have designers at all? Is design a top-down throw-mockups-over-the-wall situation, or is there any room for collaboration and iteration? Developers acting as their own agents of design almost certainly means that design isn't important to the company, and most of the products probably suck. If you have a really good product person with design sense, you might get lucky here, but more often than not everyone is shooting from the hip and it will show in the products you build.

 3.) What's the state of automated testing? Continuous integration?

 Automated testing can be awesome. I use automated unit/integration/functional (where viable) tests for any products I build, and it shapes the interfaces and makes code maintainable long term. But you can hit extremists on either end of the spectrum.

 We don't have tests.Get out. Your about to slam into a million line code base where only the original authors have a chance of making changes and not breaking the product. And you'll be blamed for the breakage. We have 100% test coverage.Bullshit. Or most of your tests are asserting private method calls with mocks, stubs, and other 0-value tools that were invented to achieve 100% test coverage. Trying to change anything in the application will either break the entire test suite or break none of the test suite. Either way is dangerous. And you'll be blamed for the breakage.
 4.) What *exactly* will I be working on? What's the tech stack?

 Job postings are notorious for lying or on job postings to attract developers. Many times, there's one developer in the company who loves pet-technology-X, so he lists it on the job application, but it doesn't relate to the job at all. For example:

 "Needs experience in rails, iOS development, HTML5, node..., and Perl experience is preferred."
 What this really means:

 "Most of what you do will be maintaining a 2 million line perl server application. I want to rewrite everything in rails and I like iOS, but we'll never actually do this."

 5.) How big are the teams? How big will my team be? 

 You can't move Mount Fuji, no matter how clever you are. If team sizes are small, and there aren't many teams, there's a very good chance you can make rational arguments and fix problems with the development process or with the team. In a large organization, you're going to crash against individuals in positions of power and change structures optimized to preventing change. Change is scary, and we've been kind of successful with the current process and 100/200/1000 people! Why would we need to change anything? You're the outlier, and you're the problem. In a smaller team, you can't be an outlier. That's math.
 6.) Is there any allowance for remote work?

 You may not even want to work remotely, or work remotely a significant percentage of the time. Still ask this question.

 Why? This is a direct indicator of whether or not the company is looking for work output or warm bodies in chairs. Do you really want to work somewhere where the employee spending 10 hours a day in the office (mostly on reddit and in useless meetings) is valued above the employee producing 2-10x their output? Fuck no. Certain industries have strange legal reasons for requiring everyone work on-site, so that's one possible excuse for disallowing remote work, but by and large, "everyone needs to be in the office" === "we care more about warm bodies than results."

 7.) Are there core business hours?

 If all aspects of the business are perfect, but there's no room for you to pick up your kids, or work out, or attend your weekly book club, is the job going to work for you? Probably not. If you're dealing with customers, it's not unreasonable to need to cover a window of time, but it's still possible to be flexible with "core hours". A strict adherence to core hours might mean that most business processes are synchronous versus asynchronous, which will strictly bottleneck your ability to get shit done. Pry a bit here, and figure out exactly why there are core hours, and what it means about the company.
 8.) Why are you hiring? Is this a new product? Scaling? Did someone recently quit?

 A company in the midst of churn is a telling indicator that something is wrong with the company. It could mean that compensation is poor, or work life balance is off, or the work culture is toxic, etc. If someone left, find out why. If the company is scaling, you may be joining a 100 person company you believed to be a 20 person company.

 9.) What's the coolest thing you've built here, personally?

 I like to build products that ship. Some companies don't. Find out what the last successful project your interviewer worked on was, and when it made it into customer hands. This tells you whether the company delivers in small increments, or allocates huge budgets to failed projects. How many projects have you worked on that never made it into customer hands, or failed as soon as it was launched? How did you feel when that project ended? 

 Asking what the "coolest" thing the interviewer has built will tell you if the employees take pride in the work they're doing. A software developer or designer will gush on a dime if they've built something even mildly interesting that even a single customer loved. This is what you want. 

 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.

 10.) What do you wish you had known about the company before working here? What's the worst part of this job?

 All companies have problems. Stop tricking yourself into believing Canaan exists; it doesn't.

 At a good company, your interviewer won't be afraid to be honest and divulge the shit. When someone isn't afraid to call out the shit, the shit can be fixed and changed. No relationship, company, or product is perfect. How you manage issues defines whether coming to work will be a slog or will invigorate you. "I have to deal with X today. Fuck my life." or "I get to try and fix X today. Today is the day we fix this problem forever."

 At a bad company, you're gonna get a sales pitch. "My biggest weakness is being too devoted to perfection." Here are the possibilities:

 Your interviewer is lying to lure you to the job. They know that it's very, very costly and disruptive to switch jobs, so they figure you'll be stuck as soon as you join the company. Your interviewer is afraid to be honest. You've found a culture of silence, and you'd better be ready to put your head down and ignore problems.  Your interviewer has drunk the Kool-Aid. This is just as bad as lying, except they don't know that they're lying. If no one in the company sees the 80 hour a week forced overtime as a bad thing, GET OUT. You'll either get sucked into the brainwashing yourself or be forced to deal with people who cannot see that there are problems to be fixed. 
 Not all companies are evil, but know what you're getting into. We only have so many years on this planet, and you don't want to waste those digging ditches with your head down.
	Comments: "stefankendall.com: 10 questions to ask your potential employer"

	URL: http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html


	The interview is all too often driven by the employer. Can you handle this workload? What are your strengths and weaknesses? How do you feel about this aspect of the business?
	But at the end of the interview, you do not know enough to know if you will actually love and enjoy the work. How many developers or designers do you know who have worked at a place for less than a year? Less than 9 months? I bet more than a few.

	Here's some questions you should ask before committing a significant portion of your life to a company.

	1.) What's the process like? How do you build software? Do you describe yourself as "lean", "agile", or "scrum"?

	This can make or break a position. If the work culture hasn't been somewhat formalized, you might be entering a position where your main job is managing the chaos. If a company thinks they're doing "lean" or "agile", this might mean you're walking into a formalized reasonable process, or it could mean that you spend half your time in meetings with decks of cards arbitrarily assigning cost to problems. The most important thing is that someone, at some time, has consciously decided how work is developed at the company, and it makes sense. Be cautious of too many buzz words.
	2.) How do designers work with developers?

	Do they even have designers at all? Is design a top-down throw-mockups-over-the-wall situation, or is there any room for collaboration and iteration? Developers acting as their own agents of design almost certainly means that design isn't important to the company, and most of the products probably suck. If you have a really good product person with design sense, you might get lucky here, but more often than not everyone is shooting from the hip and it will show in the products you build.

	3.) What's the state of automated testing? Continuous integration?

	Automated testing can be awesome. I use automated unit/integration/functional (where viable) tests for any products I build, and it shapes the interfaces and makes code maintainable long term. But you can hit extremists on either end of the spectrum.

	We don't have tests.Get out. Your about to slam into a million line code base where only the original authors have a chance of making changes and not breaking the product. And you'll be blamed for the breakage. We have 100% test coverage.Bullshit. Or most of your tests are asserting private method calls with mocks, stubs, and other 0-value tools that were invented to achieve 100% test coverage. Trying to change anything in the application will either break the entire test suite or break none of the test suite. Either way is dangerous. And you'll be blamed for the breakage.
	4.) What exactly will I be working on? What's the tech stack?

	Job postings are notorious for lying or on job postings to attract developers. Many times, there's one developer in the company who loves pet-technology-X, so he lists it on the job application, but it doesn't relate to the job at all. For example:

	"Needs experience in rails, iOS development, HTML5, node..., and Perl experience is preferred."
	What this really means:

	"Most of what you do will be maintaining a 2 million line perl server application. I want to rewrite everything in rails and I like iOS, but we'll never actually do this."

	5.) How big are the teams? How big will my team be?

	You can't move Mount Fuji, no matter how clever you are. If team sizes are small, and there aren't many teams, there's a very good chance you can make rational arguments and fix problems with the development process or with the team. In a large organization, you're going to crash against individuals in positions of power and change structures optimized to preventing change. Change is scary, and we've been kind of successful with the current process and 100/200/1000 people! Why would we need to change anything? You're the outlier, and you're the problem. In a smaller team, you can't be an outlier. That's math.
	6.) Is there any allowance for remote work?

	You may not even want to work remotely, or work remotely a significant percentage of the time. Still ask this question.

	Why? This is a direct indicator of whether or not the company is looking for work output or warm bodies in chairs. Do you really want to work somewhere where the employee spending 10 hours a day in the office (mostly on reddit and in useless meetings) is valued above the employee producing 2-10x their output? Fuck no. Certain industries have strange legal reasons for requiring everyone work on-site, so that's one possible excuse for disallowing remote work, but by and large, "everyone needs to be in the office" === "we care more about warm bodies than results."

	7.) Are there core business hours?

	If all aspects of the business are perfect, but there's no room for you to pick up your kids, or work out, or attend your weekly book club, is the job going to work for you? Probably not. If you're dealing with customers, it's not unreasonable to need to cover a window of time, but it's still possible to be flexible with "core hours". A strict adherence to core hours might mean that most business processes are synchronous versus asynchronous, which will strictly bottleneck your ability to get shit done. Pry a bit here, and figure out exactly why there are core hours, and what it means about the company.
	8.) Why are you hiring? Is this a new product? Scaling? Did someone recently quit?

	A company in the midst of churn is a telling indicator that something is wrong with the company. It could mean that compensation is poor, or work life balance is off, or the work culture is toxic, etc. If someone left, find out why. If the company is scaling, you may be joining a 100 person company you believed to be a 20 person company.

	9.) What's the coolest thing you've built here, personally?

	I like to build products that ship. Some companies don't. Find out what the last successful project your interviewer worked on was, and when it made it into customer hands. This tells you whether the company delivers in small increments, or allocates huge budgets to failed projects. How many projects have you worked on that never made it into customer hands, or failed as soon as it was launched? How did you feel when that project ended?

	Asking what the "coolest" thing the interviewer has built will tell you if the employees take pride in the work they're doing. A software developer or designer will gush on a dime if they've built something even mildly interesting that even a single customer loved. This is what you want.

	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.

	10.) What do you wish you had known about the company before working here? What's the worst part of this job?

	All companies have problems. Stop tricking yourself into believing Canaan exists; it doesn't.

	At a good company, your interviewer won't be afraid to be honest and divulge the shit. When someone isn't afraid to call out the shit, the shit can be fixed and changed. No relationship, company, or product is perfect. How you manage issues defines whether coming to work will be a slog or will invigorate you. "I have to deal with X today. Fuck my life." or "I get to try and fix X today. Today is the day we fix this problem forever."

	At a bad company, you're gonna get a sales pitch. "My biggest weakness is being too devoted to perfection." Here are the possibilities:

	Your interviewer is lying to lure you to the job. They know that it's very, very costly and disruptive to switch jobs, so they figure you'll be stuck as soon as you join the company. Your interviewer is afraid to be honest. You've found a culture of silence, and you'd better be ready to put your head down and ignore problems. Your interviewer has drunk the Kool-Aid. This is just as bad as lying, except they don't know that they're lying. If no one in the company sees the 80 hour a week forced overtime as a bad thing, GET OUT. You'll either get sucked into the brainwashing yourself or be forced to deal with people who cannot see that there are problems to be fixed.
	Not all companies are evil, but know what you're getting into. We only have so many years on this planet, and you don't want to waste those digging ditches with your head down.