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.
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.
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.
No, it's not. Even an average developer gets to pick between half a dozen offers when looking for a job. And his choice isn't always based on who pays him the most. Camaraderie and interesting projects also count for a lot.
It's trivial to have multiple job offers, and it is trivial to interview when you already have a job. You have to give the person being interviewed a reason to come work for you other than 'I sign the checks, bucko'.
So, yes, I want to know what the job is like, or I'm not accepting.
While you're interviewing job candidates, candidates are also interviewing the company, and evaluating whether it is a good fit for them or not. While I agree that some of the questions in the article are bad, I think you should try to answer as much as possible from the company side, so as to be as transparent as possible.
You've to show that you're ready to adapt with the company needs. I don't have a crystal ball to tell you exactly what you will be working on.
There is a difference between asking for a crystal ball, and asking which of the tech listed on the job advert is actually relevant.
Remember, this question is asked due to widespread misrepresentation from companies about job adverts. Prospective employees can stop asking this question when job adverts become much more honest.
Many of these questions will make you look arrogant and not easy to work with.
Which, incidentally, is exactly how you're portraying yourself when you assume that the choice is up to you alone and dismiss the right of the potential employee to choose another employer.
Not really. The reason for the deletion was avoiding being down-voted by stupid people like you who didn't get the point (since the account is new and may be shadow-banned).
Stupid? You were the one who said that most interviews should only be a one-way street. That you will only let yourself get asked the questions in the article if the job applicant is a top-talent AND your company specifically wanted to recruit that person.
If I remember correctly, you also quoted the question "What's the coolest thing you've built here, personally?" and your response was "Who's getting interviewed here?".
You should've let your posts be. Own up to what you wrote.
While I don't agree with your position. You ARE an interviewer (allegedly :) ), unless there are other interviewers to contradict you or know that is an uncommon position, your post was valuable, and does not deserve to be downvoted.
- 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.
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.
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)
- 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 got an affirmative answer with just a brief look into it - I didn't see the details, but I saw enough for me to extrapolate valuable developer insight.
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.
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?
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.
- 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.
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.)
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.
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.
Honestly, if you're making $100k and this is something that you're thinking about, you're living paycheck to paycheck and you need to learn how to manage your money.
Was coming to post the same thing, here in the uk the more regularly that you get paid, the simpler the job type. Nearly all salaried jobs are monthly, come temping and contracting is biweekly, and manual work is weekly or even daily in small scale construction or other manual work.
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.*
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.
"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."
And if that bonus isn't guaranteed, then you're not even getting that.
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?
I'm currently at an organization of about 50 and almost all of these are questions that would provoke very good information about this company. Even if finance is one person, it's important to know if your manager gets along with her.
Have you considered publishing this list somewhere? It's incredibly useful, and though I'm saving the HN permalink, it could probably become something more.
I have an open source list of these kinds of questions up on github called InterviewThis. Would you object to me adding some of these to it? These are all really good and cover some things I didn't think of previously.
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.
I personally think #2 is quite important: it proves the employer knows why they're employing you, and that they have thought about the scope for career growth in the role. If the employer hasn't got a clear idea of why they're employing you, then your role becomes an amorphous "do whatever I want done" job, that won't necessarily meaningfully contribute to your skills or remain interesting. If the employer hasn't thought about the scope for career growth in your role, then that -- to me -- shows they don't value their staff enough to care about whether they get anything more than a salary out of the job.
I think it's a little strangely phrased (sounds a bit obsequious), but I think it's a valid and important question.
how? Are you in the habit of hiring without knowing the criteria for success in that role? Is the candidate supposed to guess or read your mind?
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.
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.
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?"
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?"
"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?)
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.
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.)
> 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.
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.
Okay, what's the point of "Can I see the codebase?" if not to come to assertions about the caliber and organization of the developers, and their capacities, backgrounds, etc.?
I'm playing devil's advocate here, but a full-time front-end designer might care deeply about such things. I would not, for example, take a J2EE job even though I know Java because I know they are not "just the same." I could see a designer caring about the stylesheets they'd be working with even though it's all fundamentally CSS.
Look, "text/less" is not something browsers understand. This question is also asking about the adoption of standards — this has absolutely nothing to do about stylesheets. Three aspects of the codebase are involved here: HTML (the lingua franca of the Web), CSS, and LESS.
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.
> "Do you use presentational CSS classes in markup, or do you fully utilize LESS/SASS?"
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.
Maybe in your mind but in reality this could just tell you that the person interviewing saw one if the same YouTube ideas you d and started using LESS, big whoop.
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.
> 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.
Like anything, often it's just a matter of selling it properly, even without "authority". Even at an established shop, if something will make a difference in the bottom line, it will likely gain traction.
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...
Selling "we need to do weeks of LOE to address a problem we don't necessarily believe exists" generally requires more than line-developer authority. (I've been there. My current company is moving towards test coverage only because I can lay out that we should do this for our mobile group, and because I'm raising hell about the rest of the company.)
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.
> 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.
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.
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.
This is actually a very useful and insightful comment rather than the obligatory "What!? You aren't using tool X that I watched a YouTube vid about!? No way I'm working here!" responses you expect in these kinds of threads.
There's a baseline level of competency I'm willing to work with. I've had to fight for basic things (like version control) over and over again, and I'm fed up to the point of not wanting to fight those wars again every time I join another company.
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.
Maybe it's an opportunity to introduce automated testing.
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.
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.
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?
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.'
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.
Indeed; according to this author, the guys at Naughty Dog were "awful" (writing their own compiler) during a period where I would have killed to work with them.
Well, there really is a difference between people who are reinventing wheels for good (because they really know their shit) and people who are doing it out of ignorance.
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).
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.
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.
The last company I worked at had one. How bad of a sign this is depends on when it was developed and why. Theirs was developed in the early days of VCS, when none of the off-the-shelf systems had the feature set that they needed. Probably they kept using it longer than they should have, I suppose out of inertia, but they were in the process of moving away when I left. In that situation, it isn't too bad of a sign.
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!
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.")
Even in smaller companies, some custom internal tools can be essential. Even in my own personal use, some custom tools can be useful or essential.
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.
It depends. Internal tools that are specialized for the industry or a specific business process at that company are probably fine and necessary. But I've seen many instances where a developer or manager gunning for a promotion writes yet another build server, deployment system, content management system or what have you just to have a "trademark" project that they can take credit for. It's that sort of internal tool which one should be very wary of, since they tend to get deprioritized but not abandoned. That is to say, once the person who championed that tool has received their reward, their continuing priority is to ensure that the tool sticks around (so that they're not blamed later for writing a tool that was later abandoned) but not necessarily to improve the tool on an ongoing basis. You want to stay away from situations like that, because you'll be assigned with fixing issues and putting out fires as they arise, but you won't be given the resources to properly refactor the tool to ensure that issues never arise in the first place.
Abandonware is never fun to work with, but I've seen internal build and deployment tools that are (a) actively maintained and (b) so good that former employees pine for them when they leave the company.
Yes, that point definitely should have been qualified better. If the new tool is much better than preexisting ones in important ways, it probably isn't a waste of time, and it could very well be a key asset.
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.
I think they're definitely "beware of" if it's the answer to "what's the coolest thing you've produced?" Unless, like you said, it's an interview for a position in a large company that's dedicated to building internal tools.
Their answer should be combined with the size of their organistion. Pretend, someone like google has their own internally developed web server. It makes sense, they have the manpower and the need. But when a 10 person tech team has their own internally developed bug tracker for no real reason, that's something to worry about.
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).
Bit of both I think - though these sorts of marketing/add agencys are still living in the past.
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.
Any company that can advertise a quiet working environment would have a huge boost with me and other developers who care about that sort of thing. I'm not looking for a private office, but open plan offices with dozens or hundreds of programmers lined up seem incredibly depressing to me.
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.
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 :)
Now you know why it was submitted to HN. Here we lionize the small percentage of startups that succeed and actually build something worthwhile, while demonizing the big fish in the pond, and pretending the heaps of failed startups never existed.
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.
169 comments
[ 3.4 ms ] story [ 254 ms ] threadI 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.
"Get real. Interviews are a one-way street unless the candidate is a top talent AND the company is trying to recruit him."
His response to being called out:
https://news.ycombinator.com/item?id=6702475
So, yes, I want to know what the job is like, or I'm not accepting.
Or candidate that knows if he can fit or not?
Sounds to me you have no order/process and scared of being exposed by an employee.
There is a difference between asking for a crystal ball, and asking which of the tech listed on the job advert is actually relevant.
Remember, this question is asked due to widespread misrepresentation from companies about job adverts. Prospective employees can stop asking this question when job adverts become much more honest.
Which, incidentally, is exactly how you're portraying yourself when you assume that the choice is up to you alone and dismiss the right of the potential employee to choose another employer.
If I remember correctly, you also quoted the question "What's the coolest thing you've built here, personally?" and your response was "Who's getting interviewed here?".
You should've let your posts be. Own up to what you wrote.
Not a disagreement button.
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.
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)
- 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.
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?
- 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.
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.
And if that bonus isn't guaranteed, then you're not even getting that.
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?
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-...
http://github.com/ChiperSoft/InterviewThis
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.
"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 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.
> 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.
Is asking coding style "religious"? I must argue: "That's, like, your opinion, man!"
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.
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.
"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.
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.'
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).
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!
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.
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.
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).
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.
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.
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.