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:
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.
Комментариев нет:
Отправить комментарий