Questions to ask your potential employer(stefankendall.com)
stefankendall.com
Questions to ask your potential employer
http://www.stefankendall.com/2013/11/10-questions-to-ask-your-potential.html
169 comments
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).
I like a challenging problem. I don't like fighting a bunch of extraneous noise and distraction while trying to concentrate on it. (Collaboration is just fine. Noise is not.)
I've yet to see a clear formula for addressing this concern in a neutral fashion (or, perceived as neutral or acceptable).
Any 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.
I think it is OK to ask 'where would I be working? I find I'm most productive in quieter settings?'
Any interviewer that is offended by this seems like they work for a company worth avoiding.
Any interviewer that is offended by this seems like they work for a company worth avoiding.
If you're trying to remove or drastically limit the human element, that is a sign that you need to freelance.
Agreed, but limiting the human element (as opposed to 'drastically limiting') can lead to better productivity.
But most developers work better in offices with doors that shut (at least according to what I remember of Peopleware [http://www.amazon.com/Peopleware-Productive-Projects-Second-...], 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.
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.
Step into the office and take a look? In my experience your first impression is correct 9 out of 10 times.
I got dinged for pointing that out at one agency I went to an interview at.
Did you get dinged, or did you avoid a company that would have been a bad fit?
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.
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.
You could ask to see where you'll be working?
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?
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.
0) Do you use version control for your code, and if yes, what?
If they say "no" or "RCS", politely say that you don't want to be a part of that dev team. Unless they hire you as the only developer, and you see real chances of introducing some sanity.
This is not just about the way they store code; it's about the attitude towards tools. If they aren't aware of source/version control, or are aware but don't care, experience shows that they will be a huge pain to work with. Know a perfectly fine, open source library that does 90% of that task? Have fun getting permission to use it!
If they say "no" or "RCS", politely say that you don't want to be a part of that dev team. Unless they hire you as the only developer, and you see real chances of introducing some sanity.
This is not just about the way they store code; it's about the attitude towards tools. If they aren't aware of source/version control, or are aware but don't care, experience shows that they will be a huge pain to work with. Know a perfectly fine, open source library that does 90% of that task? Have fun getting permission to use it!
I would never think of asking this question since I have always just assumed that if you are building software, you are using version control. Apparently I was wrong...
... Yeah. I spent one job emailing code files back and forth (and verbally acquiring locks at the file-level). I spent most of the time there trying to convince the team to at least learn how to use a patch tool and mail patches instead.
At another job they just had a shared drive with a single copy of each project and mandated we use a particular editor because it had an in-built locking scheme. There were a few conditions (e.g. crashes) that required manual lock manipulation before you could accomplish anything. People would often manually release locks out of habit, open a file for writing but just leave it open all day in the background while the lock-holder worked, save the old copy when they were closing up at the end of the day, thereby reverting a day's progress. There was no backup strategy in place. This wasn't the 90s or anything, git and GitHub were already established.
At another job they just had a shared drive with a single copy of each project and mandated we use a particular editor because it had an in-built locking scheme. There were a few conditions (e.g. crashes) that required manual lock manipulation before you could accomplish anything. People would often manually release locks out of habit, open a file for writing but just leave it open all day in the background while the lock-holder worked, save the old copy when they were closing up at the end of the day, thereby reverting a day's progress. There was no backup strategy in place. This wasn't the 90s or anything, git and GitHub were already established.
I once thought the same, and then I landed at a company where the source was contained across a mixture of svn, network drives and customer production servers.
However, I don't directly ask about VCS now, it seems overly focused for a question, instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.
However, I don't directly ask about VCS now, it seems overly focused for a question, instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.
> ... instead I will ask how they produce builds, what the deploy pipeline is, and then track back if I find their answers alarming.
That's a good approach, noted!
That's a good approach, noted!
Yep - I worked at a company where our entire codebase was inside a folder in our web server. We actually copied things locally and had to paste in changes via FTP.
I tried to make the team switch to something like Git or hell - even SVN - something to manage the code and not have it all in one point of failure but that fell on deaf ears.
Ultimately I create a private repository on Bitbucket and pushed the code there using Git and used that as my personal backup in case shit hit the fan.
I tried to make the team switch to something like Git or hell - even SVN - something to manage the code and not have it all in one point of failure but that fell on deaf ears.
Ultimately I create a private repository on Bitbucket and pushed the code there using Git and used that as my personal backup in case shit hit the fan.
Oh those companies exist.... Much less now... but still...
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 :)
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.
right on. a large of big companies don't have things like automated testing
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.
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.
I'm not sure I'd agree with all of these. For example, the ones about automated testing or building internal tools sound a lot like "Do you like to work the same way I do?" and if the answer is no then the dubious assumption is that you know more about what this potential employer does than all of their existing staff. The list seems reasonable for the most part, though.
Aside from obvious questions about the kinds of projects you'd be working on and the skills and technologies involved, I used to rely on a few simple tests:
1. What is the employee turnover like, and if people have left recently, why? [This is a reasonably objective proxy for what the rank and file staff really think, and they collectively know this potential employer much better than me.]
2. Did they ask brain teaser type questions or do a pop-psych personality test in the interview? [Do their hiring practices suck, in which case even if they hired me, would I want to work with anyone else they hired? Also tends to indicate an unhealthy assumption of superiority and desire to conduct one-sided interviews, which is a red flag in its own right.]
3. Will they show me a sample of their production code and of the related documentation, and if so, what is it like? [If they won't and don't have a very good reason, my assumption is that they aren't confident their code will impress, which is not a good sign. If they will, what I see is about as good a marker for whether they're any good technically as any benchmark you can fit into an interview.]
4. What does the car park look like on the way in? [Far from scientific, but a handful of executive cars in reserved spaces and then nothing but old models in the few remaining spaces is rarely a good sign.]
5. Does the contract impose on my life outside of work? For example, would I need permission from the employer to take on an unrelated side job that had no bearing on my ability to work properly for them? Would they be claiming IP rights to any work I did unrelated to that employment, so that for example I couldn't release a hobby project as Open Source if I wanted to? [Any attempt to control life completely outside work is a fairly reliable red flag for a generally over-controlling attitude and/or a show run by HR/legal rather than sensible management or the people I'd actually be working with.]
Aside from obvious questions about the kinds of projects you'd be working on and the skills and technologies involved, I used to rely on a few simple tests:
1. What is the employee turnover like, and if people have left recently, why? [This is a reasonably objective proxy for what the rank and file staff really think, and they collectively know this potential employer much better than me.]
2. Did they ask brain teaser type questions or do a pop-psych personality test in the interview? [Do their hiring practices suck, in which case even if they hired me, would I want to work with anyone else they hired? Also tends to indicate an unhealthy assumption of superiority and desire to conduct one-sided interviews, which is a red flag in its own right.]
3. Will they show me a sample of their production code and of the related documentation, and if so, what is it like? [If they won't and don't have a very good reason, my assumption is that they aren't confident their code will impress, which is not a good sign. If they will, what I see is about as good a marker for whether they're any good technically as any benchmark you can fit into an interview.]
4. What does the car park look like on the way in? [Far from scientific, but a handful of executive cars in reserved spaces and then nothing but old models in the few remaining spaces is rarely a good sign.]
5. Does the contract impose on my life outside of work? For example, would I need permission from the employer to take on an unrelated side job that had no bearing on my ability to work properly for them? Would they be claiming IP rights to any work I did unrelated to that employment, so that for example I couldn't release a hobby project as Open Source if I wanted to? [Any attempt to control life completely outside work is a fairly reliable red flag for a generally over-controlling attitude and/or a show run by HR/legal rather than sensible management or the people I'd actually be working with.]
I totally agree with this. I personally do not use unit tests at all.
Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.
Why? Because I do assert-driven testing. My test code is integrated into the actual business logic. So no need to contrive scenarios.
So you do do tests, just not specifically separate unittests.
That's totally different from an organisation that doesn't do tests at all (yes they exist).
That's totally different from an organisation that doesn't do tests at all (yes they exist).
yes, but if someone asks me in an interview if we do unit testing, the answer is really a no...
so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)
so maybe the takeaway is if people don't do what you expect, maybe digging a little deeper before running away screaming ;)
Could you expand on what you mean by assert-driven testing? I'm not finding any good explanations from a Google search. Sounds interesting.
My GUESS was that he/she means that the code has asserts in it that check if something is not right at runtime. I personally would not call that a replacement/alternative for unit tests. In fact, it may be counterproductive ... a small error in the code would bring down and entire application.
i would counter this by saying that a small error in code SHOULD bring down the entire application.... during development. otherwise the error is not visible to developers when they can best/easiest fix it.
of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.
but during development, I'd say crashing during small errors is a great thing.
of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.
but during development, I'd say crashing during small errors is a great thing.
Assert driven testing means that the tests are part of the actual code that is running. It's helpful because when an assert fails, the stack trace is right at the position where it failed. In many ways it's an easy way to incorporate testing into your application without the need for an additional framework.
A simple example can be done by writing a single function in the root scope or some global function (javascript)
function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }
Then in a function in your application:
function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);
\\Continue code... }
This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P
Some systems have something like this built in, such as node which has more features.
http://nodejs.org/api/assert.html
A simple example can be done by writing a single function in the root scope or some global function (javascript)
function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }
Then in a function in your application:
function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);
\\Continue code... }
This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P
Some systems have something like this built in, such as node which has more features.
http://nodejs.org/api/assert.html
Without scenarios, how do you run your code before it goes into production?
i use the combination of assert-driven development + UI/UX testing. (manual, but that could be a valid candidate for automation in my projects)
so I'm not saying there are no scenarios, but they all end up being the customer facing scenarios, and verifying those meet expectations. Also just developers making sure the functionality "works" naturally catches the technical bugs (because asserts in production code would cause the app to crash)
so I'm not saying there are no scenarios, but they all end up being the customer facing scenarios, and verifying those meet expectations. Also just developers making sure the functionality "works" naturally catches the technical bugs (because asserts in production code would cause the app to crash)
You might be interested in `contracts' which are basically assertions on steroids. See https://en.wikipedia.org/wiki/Design_by_contract (or http://blog.racket-lang.org/2012/11/contracts-for-object-ori...) for an introduction.
You might also want to explore QuickCheck, which helps to generate these scenarios.
You might also want to explore QuickCheck, which helps to generate these scenarios.
I find it interesting that you decide that assumptions about software process maturity are dubious but are happy to make assumptions about the lack of utility of "brain teaser" questions or personality tests.
I find it interesting that you decide that assumptions about software process maturity are dubious
You appear to be making your own questionable assumption, which is that the techniques mentioned before necessarily imply a more mature software development process. If a development team didn't use automated testing, I'd certainly be interested to know why, but I can immediately think of multiple plausible alternatives that might have proven to be more effective for that team depending on the circumstances. Unlike the use of brain teasers and popular psychology to assess applicants' value as employees in technical fields, there is a significant body of empirical data to back up the effectiveness of some of those alternative testing strategies.
You appear to be making your own questionable assumption, which is that the techniques mentioned before necessarily imply a more mature software development process. If a development team didn't use automated testing, I'd certainly be interested to know why, but I can immediately think of multiple plausible alternatives that might have proven to be more effective for that team depending on the circumstances. Unlike the use of brain teasers and popular psychology to assess applicants' value as employees in technical fields, there is a significant body of empirical data to back up the effectiveness of some of those alternative testing strategies.
I'm very interested in this. Can you name some of these strategies?
Two strategies I was thinking of were technical peer reviews and formal proofs. Of course, these aren't mutually exclusive either with each other or with automated testing, and these are all generic terms that each cover a multitude of specific implementations.
All three have a strong track record of finding bugs when implemented well. All three also add significant overheads, so there is a cost/benefit ratio to be determined. The relative costs of implementing each strategy will surely vary a lot depending on the nature of any given project. The benefit for any of them would likely be significant for a project that didn't have robust quality controls in place, but you'd get diminishing returns using more than one at once.
I could easily believe that skilled developers had evaluated their options and determined that for their project some other strategy or combination of strategies provided good results without routine use of automated testing and that the additional overhead of adding the automation as well wasn't justified.
All three have a strong track record of finding bugs when implemented well. All three also add significant overheads, so there is a cost/benefit ratio to be determined. The relative costs of implementing each strategy will surely vary a lot depending on the nature of any given project. The benefit for any of them would likely be significant for a project that didn't have robust quality controls in place, but you'd get diminishing returns using more than one at once.
I could easily believe that skilled developers had evaluated their options and determined that for their project some other strategy or combination of strategies provided good results without routine use of automated testing and that the additional overhead of adding the automation as well wasn't justified.
I would add a question about vacation policy as a signal about whether you want to work there.
Wrong answers: two weeks, or "unlimited" (because everyone knows there will be peer pressure not to use vacation time).
Right answer: four weeks, use it or lose it (as in, we want you to check out for a proper vacay a few times a year).
The definition of vacation = I am going to be on a beach/wherever, not checking email, probably drinking, and definitely not thinking about work.
Location is also important. If you have a 2-3 hour round trip commute each day, you'll hate your job no matter how interesting the work is.
Wrong answers: two weeks, or "unlimited" (because everyone knows there will be peer pressure not to use vacation time).
Right answer: four weeks, use it or lose it (as in, we want you to check out for a proper vacay a few times a year).
The definition of vacation = I am going to be on a beach/wherever, not checking email, probably drinking, and definitely not thinking about work.
Location is also important. If you have a 2-3 hour round trip commute each day, you'll hate your job no matter how interesting the work is.
"Unlimited vacation time" isn't always a red flag. I work for a company with unlimited vacation time (Braintree) and I've always felt comfortable taking vacations. In fact, in June I went to Europe for over 3 weeks, and I still feel comfortable taking time off for the holidays as well.
A "real" unlimited vacation policy is a strong positive signal about the company. It shows that (a) people are trusted to manage their own time and not to abuse the system and (b) the people who work there are good enough and driven enough to deserve that trust.
A "real" unlimited vacation policy is a strong positive signal about the company. It shows that (a) people are trusted to manage their own time and not to abuse the system and (b) the people who work there are good enough and driven enough to deserve that trust.
Of course, that depends on the country. In the EU, the legal minimum is 4 weeks that you have to take (or be paid for), some member states have higher legal minimums.
"Unlimited" holidays is a scam, unless they'll put in writing that you're entitled to 6 months holiday per year.
"Unlimited" holidays is a scam, unless they'll put in writing that you're entitled to 6 months holiday per year.
These are all really good questions. I think it's a great idea to have some questions in mind when you interview. It shows that you are interested in making an investment in a company and not just looking for a paycheck.
I would probably spread these questions out over a few people and not hit the same person with 20 questions. I would also be cautious of making the interviewer feel embarrassed if they are not following SCRUM to the letter with 100% automated testing and code coverage. Because in real world situations we are often striving for that but we don't always get to do it perfectly by the book. So it won't help if you make them feel even worse about it!
I would probably spread these questions out over a few people and not hit the same person with 20 questions. I would also be cautious of making the interviewer feel embarrassed if they are not following SCRUM to the letter with 100% automated testing and code coverage. Because in real world situations we are often striving for that but we don't always get to do it perfectly by the book. So it won't help if you make them feel even worse about it!
Given that I run a consulting company I spend a fair amount of time on each side of the interview table. Both recruiting for contractors to help with a project and trying to convince others that I'm the right guy / company to develop the system.
That being said I think this list of questions is excellent. I would be much more inclined to hire someone who asked these questions than someone that didn't.
Somewhat conversely as an interviewee I would be at least slightly concerned with a company if I had to ask these questions. This is basic ground that any good interviewer should cover in an interview and if thy don't they may not be looking for the type of development styles that I like most.
Interviewing is a two way thing both sides should be choosey and neither side should settle for something less than ideal. If we all found jobs / employee that we love then the workplace would be some much better off for it
That being said I think this list of questions is excellent. I would be much more inclined to hire someone who asked these questions than someone that didn't.
Somewhat conversely as an interviewee I would be at least slightly concerned with a company if I had to ask these questions. This is basic ground that any good interviewer should cover in an interview and if thy don't they may not be looking for the type of development styles that I like most.
Interviewing is a two way thing both sides should be choosey and neither side should settle for something less than ideal. If we all found jobs / employee that we love then the workplace would be some much better off for it
I like the list. Just for me personally there are some differences. From experiences I like chaos more then organization, because I can make more out of the chaos for myself. I don't feel so well today? Well in a chaotic company I can just stay home or answer emails. When I feel energetic I can also convince my coworkers to get a major feature done or an ugly bug fixed that was laying around for months.
Also from some of my colleagues I see that not everybody is really interested in delivering results. Some are just fine with doing what they are told, then going home and caring about their family. When the whole department/company thinks like that, then the life of these people is much better. It's definitely not for every engineer, but I think it's good such spaces are out there!
Also from some of my colleagues I see that not everybody is really interested in delivering results. Some are just fine with doing what they are told, then going home and caring about their family. When the whole department/company thinks like that, then the life of these people is much better. It's definitely not for every engineer, but I think it's good such spaces are out there!
Take a look at this post for specifically web developer positions:
"Questions to ask your future web dev employer" https://medium.com/what-i-learned-building/f7a161b5bc70
"Questions to ask your future web dev employer" https://medium.com/what-i-learned-building/f7a161b5bc70
Regarding #2 what if a person wants to be both. What should one ask then?
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.
or just interview at a place where the teams do the interviewing, like where I work ;)
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.
I'd say that depends on whether you liked the answers or not :)
11. What's your reason for working here?
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.
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.
[deleted](7)
Excellent list.
A few more:
- What will my typical day be like? (The answer will always start with "We don't have a typical day." So you say, "I know. Describe it as if there were one.")
- What will my life be like in 6 months? One year?
- What's the worst thing that can happen in the next 6 months? Next year?
- What's the probability we'll achieve our goals in the next 6 months? Next year?
Don't depend upon the answers but expect some very insightful discussion.
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.
- What will I be doing the first week I'm here?
If you get an answer like "you'll be setting up your development machine and loading/building the A-12 project to get a feel for our servers and systems", that's good. You also have your first assignment when you show up and your boss is too busy to guide you around.
If you get a shrug and something more nebulous, press harder. If they can't answer, expect a goat rodeo when you start.
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 found, "what was yesterday like, then?" to be a fine response when interviewers have claimed there's no typical day.
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.
Interview are not just a company evaluation a prospective employee, they are also a person evaluating a prospective employer.
Good list. N. 2 is a good catch really.
I would add another question. What's the development stack like. And by that I don't mean N.4
What I mean is: What's your source control system, bug tracker, (possibly) IDE/Editor, (possibly) other tools/environmental issues depending on the area (more usual in specific areas, embedded software for example)
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)
The list may be good but I find this writing style off-putting
Questions I like to ask as a job candidate:
- Can I see the code base? (it lets me see a bit of app structure, code style, etc.)
- How is the company doing business-wise? (I like to see big success indicators like rapid growth)
- How flexible is the employer with regards to having to take emergency and/or scheduled time off work without being penalized for vacation (i.e. waiting for a package, or specific to me, reserve duty in the military)?
- How do you see me fitting in with the company initially? (I am flexible, but I would like to know what role I am being hired for, as job descriptions are often opaque or misleading)
Unspoken questions I'm looking to have answered by coming in for an interview as a job candidate:
- What is the dynamic between employees?
- What is the company culture?
- How intense is work at the place typically? (just for personal gauging purposes - this isn't a make or break thing, but it's something I want to know)
- Does the workplace treat its employees well? (do the employees look happy to be there?)
- How transparent is a company when answering my questions? Are the responses detailed? Is there something that is being hidden from me?
There are probably more questions I tend to want answered that are never spoken, but incumbent on me to take note of through observations. As a job seeker, you owe it to yourself to be as sharp as possible about your own future.
- 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.
> - Can I see the code base?
I've often wanted to ask this but didn't have the nerve to do it. Even if it doesn't raise some eyebrows, are there companies that actually say yes?
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?
Heck, employers want to see code samples from employees. Why shouldn't employees be allowed see code samples for what they will be working with.
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.
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.
Practical questions that always bite me:
- When do we get paid? Every two weeks or twice a month? Every two weeks means your pay is essentially reduced by two entire paychecks. With "twice a month" your paycheck is $NET_SALARY/24. With "every two weeks" your paycheck is $NET_SALARY/26, meaning two months out of the year, you'll get three pay checks. But--the rest of the year, your salary is essentially reduced by ($NET_SALARY/26 * 2). You can't create a monthly budget out of two pay checks you get twice a year, six months apart.
Realistically, you aren't going to not go with an employer because they pay 26 times a year instead of 24. It's just something to be aware of since it reduces your practical salary by two entire paychecks.
- Are benefits included? It's a mild disappointing cognitive change to go from a job that pays full benefits to one that makes you pay $100/month for them.
- Meals/snacks/fruit? It's another mild disappointing cognitive change going from a company catering two meals a day to one charging $2 for a water from a third party vending machine.
- Are you lumping any bonuses in with the full salary you're offering? Be careful of HR starting your conversation with "Your total compensation is $80,000 per year" when they then mumble "That's a $45,000 base and a $35,000 bonus, paid out yearly at the end of your hire date anniversary." Your huge total comp package may make your ego feel good, but you can't budget against end of year bonuses.
- Stock is always imaginary unless you're at a public company. Always try to double or triple the base "options" they offer. Be wary of places that do 25% cliffs instead of 50% cliffs. 25% cliffs are just silly.
- 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.
The two weeks is very American no one in a professional job in the Uk and Europe doesn't get a monthly salary.
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.
"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.
And if that bonus isn't guaranteed, then you're not even getting that.
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.
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.
Total compensation is what's important, so long as the interval between payments isn't too long.
If you have to sweat the difference between being paid twice a month and every two weeks, you need to start saving yourself more of a cushion.
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.
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.)
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.)
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.
$100k a year is not a "poor person" salary.
That might be a good strategy to spend more wisely, and save up the 'extra' money that comes up twice a year.
If you're making 100,000 salary, you're well off. Incidentally, I find it much simpler when I get paid once a month.
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.
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.
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?
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?
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.
If someone asked me this stuff, I would thank them and probably go on a vacation to forget the whole experience.
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.
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.
How do you earn a gold star should always be asked.
Yeah, I write the largest career advice newsletter in America over at TheLadders, so I do this stuff professionally.
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.
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.
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.
I think it's a little strangely phrased (sounds a bit obsequious), but I think it's a valid and important question.
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.
http://github.com/ChiperSoft/InterviewThis
http://github.com/ChiperSoft/InterviewThis
Looks great. I will add via github.
These are good questions, but many seem to be applicable to 100+ person companies only.
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.
Thanks. I write the largest career advice newsletter in America over at TheLadders.com -- reaches an audience of 6mm weekly.
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-...
You can see all my stuff here: http://www.theladders.com/career-newsletters
This particular newsletter is here: http://www.theladders.com/career-newsletters/it-s-not-about-...
I 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?"
"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?)
It draws a line.
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.
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.
I agree. I had a "Oh, here we go" reaction.
It's effectively asking a coding style question. How is this not fair?
Is asking coding style "religious"? I must argue: "That's, like, your opinion, man!"
Is asking coding style "religious"? I must argue: "That's, like, your opinion, man!"
You missed the point. It's a fishing question.
> 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.)
> 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.)
> 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.
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.
Definitely, theres always room for wild speculation and armchair psychology.
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.?
Which means there's an open dialogue.
We like dialogue, as socially conscious beings.
We like dialogue, as socially conscious beings.
I can't think of any substantial job where stylesheets, of all things, are anywhere near the top 100 concerns.
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.
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.
[deleted]
> "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.
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.
You understood the point as to the nature of my question.
It's a fishing question.
It's a fishing question.
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.
A negative attitude is not "in reality".
To filter for those managers who will never be happy with anyone's work ask:
"Who is your favorite employee? Why? How do you motivate them?"
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.
> We don't have tests. - Get out
Maybe it's an opportunity to introduce automated testing.
I've worked at many companies where my managers wouldn't allot any time to develop automated tests and change the deployment to accommodate them.
Many companies are just not aware, because they never hired the people who are familiar with automated testing.
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.
> 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.
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...
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.
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.
> Established shops mean established culture.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Even now, version control can tell you a lot. An organisation still use CVS, or even SVN, will tell you something.
I agree with most of the things here except for the last part of no. 9:
"Beware of "I built an internal tool that..." or "I built a flux capaciting tool that..." or "I rewrote an open source tool because...". Some developers like to jerk off to rebuilding the wheel and wasting business money on projects that strictly aren't required or useful to the business as a whole. Like I said, I like to build products. If you feel like you needed to rewrite the compiler, you're probably awful, and almost certainly wrong."
What about DevOps and people who work on improving the work flow for other developers?
Otherwise, great list.
"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.
> Why are you hiring?
This is a good one to ask, but tricky sometimes. I've heard answers along the lines of 'we keep positions open perpetually' for architects, systems analysts, data scientists, and the like. So I think to myself, that's great! It is fun to think I'll be a valued hire, and the friend who brought me in will eligible for a nice referral bonus. However, I am starting to think that if a company appropriately values experienced, talented leadership in the most challenging sectors of development, then these roles don't need to be 'always open' any more than entry level positions. My guess is that there's always a catch with companies that give this answer.
So what's a good answer? I'd prefer: 'we weren't hiring, but X thought we should meet you.'
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.
They're a potential indicator for NIH syndrome.
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.")
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.")
For larger companies, internal tools become absolutely essential.
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.
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.
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.
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.
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!
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!
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).
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).
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.
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.
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.
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.
That's fine as far as it goes, but one of the things you'll learn as you progress is that superficial process issues are actually not at the core of effectiveness; talent, vision, and ability to execute are. You want to be careful that your questionnaires don't blind you to opportunities to work in radically different cultures/processes that will succeed for reasons you don't yet understand.