17 ms·

A list of developer questions to ask prospective employers

• Visual_Tech 4y ago
  I’ve been through many many interviews myself, but the toughest ones in each recruiting processes is the one where you have to speak to a CTO/VP of Engineering or even a CEO/Founder. Here’s an article that helped me out a bit with the last iinterview I’ve had: https://blog.nextonlabs.com/9-questions-to-ask-a-startup-ceo-or-founder-during-an-interview https://blog.nextonlabs.com/9-questions-to-ask-a-startup-ceo...
• skrebbel 4y ago
  I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product. There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp. EDIT: to add some context, i run a small startup, we need the whole team able to ship. I can imagine that in certain bureaucratic bigcorps, performatively obsessing on code/process quality can be useful, because the distance between the programmer and the customer/user is so long.
  • switch007 4y ago
    Ah the cliche “I’m a hiring manager and I wouldn’t hire this person” comment. I think you’ve not considered the reason behind the question and jumped to conclusions. Eg if the say subversion and it’s a massively distributed team, the developer is not going to have a fun time. It isn’t a first class citizen when it comes to third party tools either. These are real issues.
    • gregors 4y ago
      While that's true, there are work arounds. Github does support Subversion. Having found myself on a team (in the past) that was tied to an outdated version control solution (source safe), you can still use Git locally to facilitate branches, rebasing and most everything else. Thankfully that's a rare occurrence these days. https://docs.github.com/en/get-started/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients https://docs.github.com/en/get-started/importing-your-projec...
      • supportlocal4h 4y ago
        I am ok with candidates asking questions. And I am ok with managers filtering out people who ask questions. From both perspectives, mission accomplished.
  • Trasmatta 4y ago
    That's an odd one to cherry pick. There's nothing performative about source control. It's one of the most important tools for actually shipping software.
    • woutr_be 4y ago
      I was going to say; I would ask this, as a lead up to CI/CD, and how they feel about developers shipping features continuously, or if there’s any process to actually ship what I’ve build.
    • technion 4y ago
      I can see the concern though. If you say something like "we invested in a large workflow involving Gitlab/Gerrit/anything else" and a potential applicant without any context expects you to go on the defense about why you aren't just using Github, I can see that person being hard to work with. I'm particularly noting the "and why" part here.
      • ryanbrunner 4y ago
        The problem isn't the question there though, the problem is an invented scenario that happens due to the response. The followup to that response could easily also be "Oh cool, how does that workflow work? Why did you go in that direction? What do you want to improve about it?"
    • skrebbel 4y ago
      The performative part is engaging in endless discussions and iterations about internal tooling
      • chrisseaton 4y ago
        > endless discussions and iterations about internal tooling They just asked a simple question. It's a one-to-three-word answer. 'GitHub', 'Gitlab', 'BitBucket', 'Self-hosted CVS'. They wanted information, not to start a fight like you thought.
  • wrycoder 4y ago
    It’s an easy question that could elicit an interesting response. For example, they could be using an internal CVS repo. Or, they could be using GitHub.
  • muzani 4y ago
    I've worked places where the source control tool was email and WhatsApp. I taught them Git but they were "too busy" to adopt it. Part of the reason for the busyness was everything was always on fire. As a junior, the Joel Test was a thing, and included source control. These days, it doesn't really matter though. It's easy enough to use Git, Github, and Github Desktop for everything.
    • rmnclmnt 4y ago
      WhatsApp for versioning, first time I hear, that’s a new one! (After all why not, there is even e2ee built-in!)
    • kleiba 4y ago
      "For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is." Linus Torvalds
      • yccs27 4y ago
        Presumably the "source control" for the kernel was a disciplined system with competent people in charge of tracking versions, not wildly sending around "project_v2 final (1).zip".
      • sidlls 4y ago
        Linus isn't right about everything.
        • dsr_ 4y ago
          Then he wrote git.
        • switchbak 4y ago
          If you haven't used CVS, his comment would sound crazy. They did use BitKeeper as well for a time, it's just that CSV/SVN weren't up to the task, so they did the best they could at the time.
  • deleted 4y ago
    [deleted]
    • deleted 4y ago
      [deleted]
  • raverbashing 4y ago
    Oh no that's a very useful answer It tell you how up with the times (or not) their company is ClearCase has been a very good indicator the place is a dumpster fire
  • bart_spoon 4y ago
    It’s not a bad question. There are still enough companies not using source control that the question is necessary.
  • jraph 4y ago
    Well, here's the thing. If I'm forced to use a clunky source control tool, the company ought to be able to tell me why (maybe there's a very good reason) and/or have other aspects I'll really like. So, yes, I might try to know this kind of things and understand the whys behind the choices, that'll also help me decide if the way choices are made seems reasonable to me, which is actually very important for both parties. Of course on should only pick questions that really matters to them / which may trigger an interesting talk.
  • arethuza 4y ago
    A few years back I worked for a large company that had, for various reasons, dependencies on software products produced by a lot of different suppliers. We wanted to do a "sanity check" on how good these companies were so we could identify where the risks were. So I came up with a list of pretty basic questions - including what tools they used for source control. During this process I encountered people who had somewhat eccentric views about source code control - including arguing pretty passionately against using it. I was somewhat taken aback by this.... So I think asking about how companies do source code control is pretty reasonable - 95% of the time they are probably sensible, but they might uncover somewhere where they have unusual views about how to do things. Edit: I've encountered some people with really odd views about software development, such as one chap who believed that testing caused bugs...
    • jacquesm 4y ago
      I've encountered a company without version control in recent times. Interesting aside: they produced very high quality software, so it's not even a cut-and-dried thing on that front. Personally, I wouldn't get through the day without it but apparently there are people disciplined enough to manage. But I suspect they are quite rare.
      • plugin-baby 4y ago
        Where was the code?
        • jacquesm 4y ago
          Embedded device. Or do you mean storage? Tar files... going to back a decade+.
          • xorcist 4y ago
            Well, that is version control, isn't it? Add some basic tooling about that collection of tar balls and you're half way on re-implementing git.
          • 4y ago
  • YetAnotherNick 4y ago
    There are many teams in big old companies which haven't transitioned to git or any modern source control. I remember hearing this for Oracle, not sure if it is still the case.
    • chrisseaton 4y ago
      The part of Oracle I was in were using Git on BitBucket when I was there years ago. They were on GitHub for a time but decided they didn't like the PR functionality.
      • XorNot 4y ago
        Did they say why? I'm struggling to think of any difference?
        • chrisseaton 4y ago
          Maybe it was some Atlassian plug-in to the PR system?
      • YetAnotherNick 4y ago
        Is it consistent for all teams?
        • chrisseaton 4y ago
          I think different teams do what works for them - Oracle is pretty heterogeneous.
    • jghn 4y ago
      Every time my team is hiring I am always amazed at how many developers have no, or almost no, git experience. People on HN assume some of these things as givens but it's not the case.
      • lakomen 4y ago
  • JustSomeNobody 4y ago
    Source control is a tool I interact with daily. I should be able to ask you about it. I personally don't care which tool you use unless your process around it causes friction for me. I don't want friction from doing source control. That's easily fixable and if the company isn't willing to fix it, I am not willing to waste my time there. How am I supposed to ship if your SC is such a mess?
  • choeger 4y ago
    > There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp. Sorry, but I think you're probably wrong as well. Do you actually sell features? As in: Is your revenue directly tied to the number of shipped features per year? If so, who pays for the perpetual maintenance? Did it ever occur to you that every feature is a liability? Security issues, bugs, incompatibilities and odd side-effects with other features, legal changes all add cost per feature. If you're (like many in the industry) piling features on top of each other because you currently have no idea what your finished product should look like and you're hoping that your feature pile will someday somehow turn into a profitable product, I think you're wrong. And even if it does, you'd better exit shortly after because mid-term maintenance will be a proper nightmare.
    • skrebbel 4y ago
      You're making a whole lot of assumptions there buddy.
    • unoti 4y ago
      > Do you actually sell features? As in: Is your revenue directly tied to the number of shipped features per year? If so, who pays for the perpetual maintenance? I have worked for years in different places where the answer is yes, we sell features. This happens any time you are in a competitive deal where customers want software that does certain things and solicit bids from software providers. Your software does some things out of the box and you need to customize or extend it to do other features the customer wants that the system does not yet currently do. You demo what you have, describe how you would do the rest, and do a bid for total cost to the customer. Your competitors do the same. Maintenance can work different ways. But yes, people pay money for features. And when properly managed, it is possible to make features add up to a product that provides value and earns money.
  • calvinmorrison 4y ago
    That is until you start a new job where they use subversion but people really just copy code around and once in a while a new version gets tagged.
  • OJFord 4y ago
    I can understand 'and why' being tedious, and I've never had any questions come to mind to ask really, but it has occurred to me before that if I joined and then found out they didn't use git... I'm all for 'actually shipping product' but there's enough employers out there that such a fundamental unlikely to change tool is a reasonable deal-breaker. The other thing I thought that about was Windows - using macOS would frustrate me daily but I'd (and have) get by, but Windows I would definitely regret not having checked what I'd be using/whether it was my choice before joining.
    • ryanbrunner 4y ago
      For a lot of candidates, "we don't really view source control as something we need to innovate on and prefer to ship features" is the right answer, and if that's your answer and the person is combative about it, well, that sounds like you just got a pretty clear signal about hiring that person, which is the whole point of interviewing anyway.
      • OJFord 4y ago
        I'm not suggesting being 'combative about it', I just don't want to work somewhere that doesn't use SVC, I'd have to really want to work there for other reasons to learn subversion/mecurial/whatever (though maybe something newer than git, like pijul, would be interesting rather than annoying), isn't it in both our interests that I don't have a nasty surprise after joining? Nor do I want to 'innovate on' on SVC, btw... If anything I'm saying the opposite aren't I? Git's what I know, and it's so fundamental/used so much throughout my day that it's a tool I wouldn't really want to be without. Hard to explain perhaps, considering I wouldn't have a problem with a new language (immediate turn-off when I get recruitment spam looking for a 'python/django engineer' or whatever - yes I have experience doing that but that's not how I'd categorise myself) but it makes sense to me. I just mean, if it hadn't already come up/been mentioned, when they invariably asked 'any questions for us', I'd now (having thought about this before but not interviewed since) at least ask if they could tell me a bit about the hardware the provide and tools/processes they use. Just a question, nothing 'combative' about it.
  • andrew_ 4y ago
    this comes across poor. it makes you sound more like The drummer on a Roman galleon, than someone leading other developers towards a goal. if a perspective developer adds value to your company and your product, but happens to care about things like source control, there may be really good reason why. if you dismiss that because of "we need to ship" then I'd propose that you might have tunnel vision and lack the EQ to value perspectives other than your own.
    • skrebbel 4y ago
      It's not the best comment i ever wrote, but I never said I'd dismiss devs caring about source control. I said that a series of questions like that suggest that the dev might care too much about stuff like that to the detriment of other stuff. If you keep shipping and growing but don't make your internal tooling and processes better, you're going to grind to a halt. If you only make your internal tooling an processes better but not shipping, you're also going to grind to a halt. My argument is that you need a lot of the first and a bit of the, latter. An applicant who nearly only asks detailed technical questions about internal stuff, and makes me defend our decisions when we're not ticking off all the hypes du jour, suggests to me that we're not on the same page wrt where that balance should lie. Yes, we iterate on that stuff. No, not fulltime. PS. I feel the jab about my EQ was unnecessary.
      • andrew_ 4y ago
        In fairness it wasn't a jab, but an objective observation. There were no personal attacks, merely suggestions based on observation. If we can suggest that an attentive list (where we've yet to define if a fictional candidate would expect all items to be addressed) means inherent expectations, it's reasonable to make the same kind of suggestions on your take. Appreciate your clarifications none the less.
    • unoti 4y ago
      I get where you’re coming from, but keep in mind we were talking about the candidate bringing an exhaustive list of such questions. In such a scenario it’s reasonable to suspect the candidate cares more about technical process than providing value for customers.
  • throw827474737 4y ago
    This question can be fine addressesd and be done with in 10 seconds. If you cannot answer this positively quickly I'd doubt your ability to ship a product (long-term). Especially the remark about " obsessing on code/process quality can be useful" .. erm, asking about source control is not obsessing about code/process, it is the bare minimum and more to me like e.g. ask my future truck employer if their trucks have seatbelts.. tbh if I'd hear that from the guy that runs a small startup I'd run .. and that's good, people are different.
    • sumtechguy 4y ago
      "we sometimes check things into sourcesafe but usually keep it on jims computer" That was 3-4 years ago. From a company that was in no way a 'startup'. That tells me they have no release system at all other than the late 80s crowd around a 'blessed' computer and hope it builds right. "have you considered git, svn, perforce anything like that?" "we don't have time for that" That tells me they do not have time to invest in having a good reliable thing for themselves. It tells me that as a developer I will not have any time to fix recurring issues. It is a question you can learn a lot from. Because it is something the developers do day to day. These are not new concepts. These are table stakes at this point. We were doing this sort of thing in the mid 90s. If you are not doing them. You are missing out on some cool debugging/regression/qa tools.
    • jon-wood 4y ago
      I would (and do, when interviewing candidates on the other side of the table) frame this differently. I can more or less assume that a candidate at the level we're hiring has used git, and done some form of code review, so I don't bother asking that particular question. What I do get into is their approach to code review, how they go about handling a pull request, how they'd provide feedback to the submitter, and what particular red flags they're looking for when reviewing code. I indirectly also find out if a candidate hasn't used git, or done code review, but much more usefully I find out whether they're the sort of person who's going to take a quick glance and then throw a "lgtm" comment on the PR, or if they're actually going to review things.
  • onion2k 4y ago
    I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product. Asking a question like that in an interview is less about the answer and more about the ability to answer. Any reasonably competent dev doing the interviewing will be able to rattle off an answer and a valid reason in a few seconds. It's really obvious. It requires no thought. There's no subtle complexity to be explained. If the interviewer can't answer, or they waffle on about complex stuff, then you can know that the company doesn't have the devs who are hands on with the code in the interview process which is a really big red flag.
    • skrebbel 4y ago
      Nice one Can drop the "and why" for that though.
      • sebastianconcpt 4y ago
        Agree, ask them to make them qualify is fine but the why there feels pushing it. Also makes wonder on "why that why?" are you planning to be hired and revolutionize everybody's repo in the first week or you have to decide if you cannot adapt yourself to use git?
      • llbeansandrice 4y ago
        Yeah I think you're just a little caught up in the phrasing (very blunt) and the mostly useless "and why" portion. I've asked this plenty of times in interviews. But I usually wrap it in a general process question to see if devops and builds are a smooth process or a nightmare. Bad source control and devops means shipping features can be impossible.
  • cerved 4y ago
    version control is key to my productivity. If you don't do that well or don't understand it, we're not a good fit
  • michaelt 4y ago
    > There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features Did you consider that a candidate who asks about "pair programming" or "SOC2 compliance" or "SLAs" might be asking that so she can avoid such jobs? Of course, the list is far too long.
    • guhidalg 4y ago
      As a junior, I wouldn’t have understood this comment. 6 years later, I value my time and mental health more than compliance.
  • to11mtm 4y ago
    > I'm obviously cherry picking, but if an applicant asks me a series of questions akin to "what source control tool do you use and why" I'm going to begin doubting that this person can focus on actually shipping product. I'll devil's advocate this. In the .NET world, there are a number of toolsets that... are far from ideal. Either because I know the frameworks are restrictive, or there is a common pathology to see the tools in question abused to a point where forward progress is frequently impeded. An example that comes to mind, 2015-2017 most .NET devs I know would ask questions around whether they were using Dapper, Raw ADO, or EF6, knowing they would be FAR more productive in the former environment than the latter. As a lesser example, I know I'm -far- more productive in Github than Bitbucket for pull requests, BB honestly feels primitive and kinda broken in comparison. It's not a dealbreaker, but if I theoretically had two identical offers in front of me aside from that point... It would help me decide. > There's this whole scene of people who do performative, almost theatrical, quality programming but nigh on forgot how to actually ship features, and questions like those are a hint they might be in that camp. Agreed, There's also the 'blustering arguer' type; a specific type of dev that won't use the tools that are prescribed by an org, yet cannot finish assigned tasks using 'their toolset'. I've only run into a couple of these in my travels, at best they are marginally productive and at worst you are repairing both code and team morale after they go.
  • NullPrefix 4y ago
    It appears that skrebbel's source control is bunch of directories on dropbox. Version increment is made by copying the sources and renaming them to "project new new new", because "project new new" is already in use.
  • PheonixPharts 4y ago
    > to add some context, i run a small startup And you don't understand why developers might be interested in your source control setup and thinking behind dev processes? If your response to a really common and sensible process question is > I'm going to begin doubting that this person can focus on actually shipping product. Then, if I'm interviewing with you, my assumption is going to be that your company way over prioritizes "just ship it!" with a total disregard for technical debt, and has a generally poor engineering culture. Any engineer of any real talent is going to recognize that your dev environment and general software developement practice is in fact a big part of "shipping features" in the long term. The fact that you view this as some practice of "bureaucratic bigcorps" would tell me all I need to know to walk away slowly and politely. So I would say this comment is inadvertently validating that this is in fact a very good question to ask during an interview.
    • skrebbel 4y ago
      I actually agree with you, though i think you missed the "series of questions like" and the "and why" part. My beef is with applicants who think engineering is entirely about process and quality and who forget about business value. Obviously you've been in touch with a lot of businesses where the balance is too far in the other direction which is its own kind of hellscape. I recognize now that my comment makes us seem like such a place but actually we're very much not, I simply had not realized (until reading the replies here) that there were so many companies where even basic stuff like "using something like git" is considered overly fancy. I do still believe that it's a common pitfall for good engineers to obsess too much about tooling and process and too little about customers and end users.
      • politician 4y ago
        I found the list interesting from the perspective of an interviewer: we should have answers for all of these questions, but might selectively reveal them in job postings and across the interview process. We can be proactive about some things and circumspect about others. That said, not everyone who says that they know git can rebase or do a 3-way diff if they get into trouble. There are a lot of git-is-Github in the pipeline right now.
  • whoomp12342 4y ago
    uhh if you use visual source safe, I am out. I will tolerate git and SVN and thats about it.
  • jfabre 4y ago
    If you have trouble finding a job, sure. I use these questions to vet the employer, not the other way around. Mentality like "we have to ship right now" only works for so long and after a while no one is able to ship anymore and life is hell. I turn down offers from companies like that and let the juniors cut their teeth on that kind of company. And to be clear, I would work on a small startup over a large org 9 times out of 10.
  • wildpeaks 4y ago
    The reason is that it's such a basic question that not having an answer is a red flag. For example: "we use Github for source control: it has good security, price is reasonable, comes with a bug tracker and a CI that are easy to use" is more than enough. It's also more than OK to reply "I don't know, but I can find out if you think it's important", they're not performing a power play, they're merely looking for information in the same way they'd look for information from a computer. It's also a way to know if it's a company culture where higher ups frown upon underlings asking pragmatic clarifying questions when assigned a task (another red flag because ego will hinder the productivity because developers will fear angering higher ups and will build the wrong thing, thus losing time and money you can't afford to waste in smaller companies).
  • yCombLinks 4y ago
    You're not getting a lot of agreement in your replies, but I've worked with people exactly like what you're saying. They could spout off some of the most impressive sounding concepts. When the rubber hit the road they produced absolutely nil. But I do think this particular question wouldn't be a good filter for that type of person.
  • stonemetal12 4y ago
    Having worked at places with no source control and visual source safe, I would ask what they use, but not why. Where the latest zip of the project is and if some random zip has a certain bug fix shouldn't be a regular question. I would also ask about a artifact repository like Artifactory, because not having to worry about downloading random dependencies from the internet is nice. Having all your build artifacts in some centralized place is nice. Certainly not a deal breaker if it isn't there, just a nice to have.
  • ChiperSoft 4y ago
    Author of the list here, the list is 9 years old. That question was a lot more relevant in 2011.
• bartvk 4y ago
  Pretty amazing list. There's also funny questions: "tabs or spaces?" is in there. Now that I have a family, I always ask: "when was the last time you worked weekends?" There's a question in the list "What hours does the team work?" but I feel that doesn't quite cover overwork.
  • muzani 4y ago
    About half the people I've worked with prefer to work nights. I think what hours matter a lot to those people. We had one team where standups were 5PM because that's when the managers were about to leave work and that's when the programmers woke up. With remote, it gets messier.
    • bartvk 4y ago
      Very good point indeed. I was in a EU team where it was helpful to start 7 AM, you'd have more contact time with the people based in India. I'm a morning person so it was nice.
• seanhunter 4y ago
  As someone who has recruited hundreds of candidates at this point I would urge caution with lists like this. By all means read the list, but rather than trying to grind through as many of the questions as possible, try to use it as inspiration and think of what you're actually curious about and which might tip you over one way or the other if you're on the fence. It's far better to have a good conversation about 1 thing which might affect your decision than a superficial sprint through a bunch of topics you don't actually care that much about. Secondly, consider that if you do well you are likely to have multiple rounds of interviews. Think about which questions are likely to be most enlightening when you ask each interviewer. Don't shy away from asking 2 people the same question if you think you'll get different perspectives. If you ask a peer engineer the diversity questions you may well get quite a different answer from asking the HR/recruiting person for instance (eg one might give you a cultural insight vs the other might just give you the policy/factual answer). I once interviewed a candidate[1] who had printed off a whole list like this and insisted on grinding through the whole thing. It was weirdly offputting, but he was such a monster programmer that he was already a clear hire. It gave an insight into the thoroughness of his nature though and showed that he was absolutely perfect for the (critical) role we were hiring him for where mistakes were extremely costly. [1] Hi Fluffy! If you see this I hope you're doing well.
  • paskozdilar 4y ago
    > I once interviewed a candidate[1] who had printed off a whole list like this and insisted on grinding through the whole thing. It was weirdly offputting, but he was such a monster programmer that he was already a clear hire. It gave an insight into the thoroughness of his nature though and showed that he was absolutely perfect for the (critical) role we were hiring him for where mistakes were extremely costly. Would you share some more information on what kind of role it was? And what kind of qualities would you look for when hiring someone for that kind of position? I aspire to work in such role (where pedantry is appreciated, instead of tolerated) one day, and I'd be grateful for any such information or hints.
    • Cthulhu_ 4y ago
      I mean I'm reading that and I just wonder if the grandparent only hired one person for that role; if it's that critical, you should never rely on one person. You need a team and thorough QA. It does remind me of this article I once read about how things happened at NASA, with every line of code extensively documented and discussed, and teams competing with each other to find bugs.
• sneak 4y ago
  My girlfriend has been interviewing recently and she asks shops what their Joel score is. If they know, it's a good sign, and if they don't, it makes her look good dropping knowledge. The places she has been talking to went over their scores on the call, which surfaces details about the actual working conditions.
  • versk 4y ago
    The Joel score is 22 years old now and fairly significantly outdated. It predates unit-testing, ci/cd concepts, cloud computing, microservices etc etc. Scoring 12 was perfect in 2000 but its below baseline in 2022.
    • hoosieree 4y ago
      Would "uses microservices" be a positive or negative on a Joel Test today?
      • deleted 4y ago
        [deleted]
      • versk 4y ago
        It wouldn't really make sense as a question on a Joel test seeing as its a design style. A Joel test is more about ways of working.
    • DoctorDabadedoo 4y ago
      Although is a good starting point for things to look for, you might get a pass for things that shouldn't. I used to work at a place that every client project was spun out from a monolithic repo (that continued being developed) by... local copy, sure they were using git, but no libraries, modules, packages, etc. Getting a patch in was ridiculous. So YMMV.
    • sneak 4y ago
      I don't think the score itself is so much used directly as the metric as much as the info about work processes and style that comes out of the ensuing conversation. The integer is mostly irrelevant (unless it's hilariously low).
• keyle 4y ago
  Unless you have the upper hand from the moment you walk in, I'd advise against machine gunning these questions in the interview. Yes a lot of them are important, but you can get a lot of answers by the feel from the interview and the interviewers. I'd recommend to be the guy that can help. Usually interviewers will come forward with what they're trying to fill, what they're lacking... Be that guy. Most places I joined weren't all there in when it comes to all those questions and what they imply. When I join, I try to make the place better, to provide value. That means also raise their street value, by bringing modern techniques, modern thinking etc. Sure, knowing what environment like windows or macos could be a deal breaker, but you can get that answer just by walking in, see what the interviewers are using and what's on the desks. No jobs are perfect and like any relationship, it takes work on both sides. Dream jobs are pretty rare and chances are, you won't get offered one because someone has left it behind...
  • geraldyo 4y ago
    They fully address this in the post
• jacquesm 4y ago
  You should use this list if you don't want to be hired. Any applicant that expects an interviewer to spend the better part of a day or so on answering a laundry list of questions had better be unicorn grade themselves or they'll be looking at another interview shortly. The reason is simple: an interviewer is trying to establish some level of rapport and to try to get a basic idea of whether you are going to be a good fit for the company and the team. If you are going to show up with this list you spell 'trouble' and you won't get to the 10th question before the interview is going to be terminated. But best of luck if you try. If you were to ask questions make sure they are in the ballpark of what is expected for an interview, deal parameters such as salary range, equity, any kind of vesting arrangement, transportation options, a chat with your future colleagues etc are all fair game and you should focus there. If you do want all these questions answered you should approach them sideways, not frontally: ask for a contact within the team that you will be working with and try to establish some kind of rapport before dumping your payload, it will likely have much better results than to show up to an interview with such a detailed list.
  • Trasmatta 4y ago
    Nobody is saying you should ask all these questions. Right there in the description: > This is not a checklist, this is not a shopping list. If you send this entire list to an employer, they probably won't be calling you back. This list is intended to serve as a reference point for things to be aware of during your interview process. Not all of these questions will be relevant to every person or position, you should choose the ones that are relevant to you and what you are interviewing for. It's OK for there to be questions on this list that you personally do not care about.
    • jacquesm 4y ago
      Disclaimers do not change the fact that it is a laundry list. If you dropped half it would still be way over the top.
      • Aeolun 4y ago
        So pick three? I really don't understand the issue a lot of people seem to have with this laundry list. It looks exactly like my list of interview questions I ask candidates. I don't ask all of them, I pick the ones that I think make most sense given their context and experience. Doesn't mean that it's not helpful to have.
• mianos 4y ago
  Quite a lot of detailed questions but I think, over a few interviews, most would be easily covered without even resorting to just reading a huge list Maybe even check the ones off after each interview. There is also something to keep in mind. The interviewer may also simply lie if they wish to retain you. A few years ago I was told I could use a Mac but when I got there I found I could have a Mac on my desk but I could not use it for anything as it was not allowed to be connected to the corporate wifi. Even a brand new one. The other one I have found in conflict is purchasing software. I wanted to use Datagrip as I used it extensively before. It was said that it would be no problem. Over the next year I asked once a month for fun and the answer was yes every time. Sometimes I was asked to provide the cost and details, which I did four times. Nothing ever eventuated and I simply kept paying for myself. Did they lie? Maybe not but it was pretty disingenuous.
• weego 4y ago
  If a developer was asking questions this granular in an interview I'd be very concerned that they're really focused on the wrong things for growth as a person and employee. Ask dealbreaker questions in interviews. If what source control or oss libs we use are a dealbreaker then you're a problem waiting to happen.
  • ethbr0 4y ago
    > If what source control or oss libs we use are a dealbreaker Have you ever worked at a TFS shop?
    • MarcellusDrum 4y ago
      I currently do. It's not perfect, but honestly, I don't understand the hate.
      • glitchc 4y ago
        Wait till you have to deal with a merge conflict.
    • bbarn 4y ago
      Ah, VSS and SVN's bastard love child. Don't miss that.
    • peteri 4y ago
      Depends on the version to be honest. The newer ADO with git as the source control is fine with me but I suspect if the company started with some of the early scrum templates and rolled forward it could be a complete horror show. I wouldn't use it for Linux kernel development, but for a general .net shop it's what I would expect to see. I don't really interact enough with Jira to have a solid opinion. I think the 2005 version source control was awful though, it got better and these days I'd hope everyone was using git.
  • bartvk 4y ago
    > If what source control or oss libs we use are a dealbreaker then you're a problem waiting to happen. Please reconsider this point of view, and here's why. I've actually asked this question :) The reason is, that the company was huge but not in IT. I wanted to know if they actually used source control. Turns out, another team used TFS, but this one didn't. That was useful information.
• karol 4y ago
  All it does is it shows we are still in employee driven market, hence the recession hasn't hit yet.
  • karol 4y ago
    Once this changes the prospective employees will turn to other application strategies such as depicted in the famous graphic "will code html for food".
• drstewart 4y ago
  I can't imagine asking "how verbose is your logging?" in an interview as if that's a question that's germane to whether the position is a good mutual fit.
• deleted 4y ago
  [deleted]
• gbin 4y ago
  So I recruit ... A lot. If a candidate just ask canned questions or kind of not super relevant questions like this I might spot that as a red flag. Also those questions are very developer centric, not company centric Ie. Is this environment good for me developer, which is ok but you need to balance it. For example: what is your current pain points in the company? How do you think I could help your company if I join? ^^ it is a huge red flag if you get BS responses on those as a candidate. Every single company sucks or way or another and if they hire it should be to improve it.
  • bbarn 4y ago
    I think "what are you current pain points" or "What are some of the struggles that you've had in the past" are very good questions to ask. If a manager says everything is great then either they are overhiring, or lying. (with the exception of maybe forming a new product team inside a successful company.) Typically though, it dives into deeper discussions about the product and process that can be very engaging in both directions in an interview.
• brador 4y ago
  If you’re good enough to ask these questions freely at interview without fear you should be applying for a more senior role.
  • sebastianconcpt 4y ago
    Yep.
• bsuvc 4y ago
  These hardly seem like good questions: > What percentage of the company is non-male? > What percentage of the company is non-white? > What percentage of the company is LGBTQ? If those things are important to you, better to ask something less bigot-ey, like: "I like to work with diverse teams. Can you talk about what kind of diversity programs or initiatives the company has?" It's bad form to single out a specific race or gender, even if it is the most hated trio of white, straight, male (/s). It's not the virtue signal you think it is.
  • terryf 4y ago
    Right, I couldn't even answer "What percentage of the company is LGBTQ?" because why would you ask people that specifically?
  • RektBoy 4y ago
    Rofl, only Americans care about this..
    • badpun 4y ago
      It is bizzare. People care about "diversity", but don't ask whether the company sources materials from horrific kobalt mines of Congo, or whether the company is actively working to addict its users, or whether it's doing tax evasion etc. It almost looks like a corporate psy-op - people were made to care about the one "social justice" thing that does not cut into corporate profits that much.
  • blueflow 4y ago
    If they aren't discriminating, what do companies need to know the percentages for? My previously employer advertised the average age of their employees to me during the interview. I later realized they are calculating that metric because they are discriminating against older people. They wanted young, inexperienced flesh like me.
    • respondo2134 4y ago
      Employees at my last company complained loudly when the diversity question was asked and the CHRO responded that they didn't collect that info because it was either misleading or of questionable legality. This was by far the youngest & most diverse group I've ever worked with (and I'm an old, white, straight male) so pick your poison.
• sys_64738 4y ago
  I think most of these need to be up-leveled to being open ended like “tell me about your development process” or “describe my role in the organization”. Even then differing questions will be asked to various interviewers either with you guiding the conversation or asking in Q&A at the end. I mean, is your entire decision going to be made on GIT being used?
  • bdg 4y ago
    Strong agree. It reminds me a bit of the format of interview that unskilled or inexperienced hiring managers come up with: - "How big was your team at your last company?" - "What languages do you use at your last company?" - "Do you prefer to use for..in loops or [].for() notation?" And using the surface answer as the way to make a decision. Being able to navigate a topic from broad-to-specific is a specific skill that is rarely taught and are very lucky if they manage to stumble on to it after enough experience and self-reflection.
  • Aeolun 4y ago
    > I mean, is your entire decision going to be made on GIT being used? The absence of Git is certainly a critical negative factor. I wouldn't work in a company without source control, and these days Git and source control are more or less the same (I guess it's possible they use Mercurial).
    • p_j_w 4y ago
      SVN is also still in use.
      • cerved 4y ago
        yuck
  • Double_a_92 4y ago
    > I mean, is your entire decision going to be made on GIT being used? Absolutely. If a company doesn't use any modern versioning system that's probably one of the biggest red flags there are.
• ChrisMarshallNY 4y ago
  I find that this list[0] is extremely geared towards a fairly specific style/culture/stack kind of thing. Lots of companies will "fail" this list, and it could be a real missed opportunity. SOURCE: I ran an organization that "failed" a good many of these, yet retained top-shelf C++ talent for decades. [0] https://github.com/Twipped/InterviewThis#developer-coordination--team-interactions https://github.com/Twipped/InterviewThis#developer-coordinat...
  • gjulianm 4y ago
    It's not about "failing" or "passing" the question, it's about understanding the company. For example, the "agile" question... You might answer "yes, we do agile" and that might be a good thing for some developers and bad for others (and even that might depend on the position).
    • ChrisMarshallNY 4y ago
      If the question was standalone, I'd agree. However, in the context of all the other questions, I'm not so sure.
      • gjulianm 4y ago
        Well, the list says at the beginning that the point is to choose the questions that matter to you. On time alone, you probably can only ask 3-4 per interview. I've asked similar questions on interviews and the truth is that they reveal a lot of information about the company. For example, asking about work on week-ends, I don't only want the answer but the way they answer is interesting: "we work some week-ends, lately quite a bit due to X, but rest assured all those hours are counted as overtime and compensated accordingly" is far different than "if we need to work week-ends we work week-ends", one tells me they know they're stretched thin but they don't want that to remain permanent, the other tells me I'm going to get fired soon for refusing to work a week-end on short notice.
        • ChrisMarshallNY 4y ago
• bdg 4y ago
  A lot of the comments in here are reacting to the large list of questions being very off-putting. There's a deeper issue here that we still don't have a good answer for: it is incredibly hard to tell what a company is like until you start working there, and asking questions either leads to very surface-level answers or just flat out catfishing candidates. Companies being transparent and detailed about how they operate is the exception. The company gets to spend 3+ hours finding out information about a candidate, but the candidate has little option to discover company culture for themselves. They can snoop around on LinkedIn but this doesn't answer much about culture unless there is someone who is prolifically producing content inside the company. There's glassdoor which might answer part of it but generally the reviews there are extremely shallow and biased by the skills, mindset, and treatment of whoever wrote the review. So what's the answer? I think "ask targeted questions" is fine as long as it is not "ask 100 general questions". I haven't seen a single article on the meta of how to pick what questions to ask or how to get past shallow answers. I also think the entire industry is performing pretty terrible in this space and we don't have a good answer for how to handle it that is common or even well-known. This leads to lost candidates or (intentionally or unintentionally) catfished candidates who will leave after joining.
  • Aeolun 4y ago
    Maybe we can take this list, and make something like Glassdoor where companies, or departments within companies can answer the whole list in one go, then point all the candidates there?
    • sebastianconcpt 4y ago
      The problem with that is that a self-referencing description will be mostly propaganda. It might be a startup based on BS and if manages to get attention, play the virtue-signalling game big time.
    • insomniacity 4y ago
      Stack Overflow Jobs used to do this at a very shallow level.
  • 4y ago
• iamricks 4y ago
  I used this list recently: https://github.com/viraptor/reverse-interview https://github.com/viraptor/reverse-interview
• rednum 4y ago
  Personally, I also ask more questions about on-call: - is there a SLO? - what is the schedule? 24h is no go for me. - is non-business hours on-call compensated (even when there are no pages)? In particular, I strongly believe we (as profession) should push more the employers for the last point. Being oncall during weekend means I need to seriously adjust my plans; need to have corporate devices somewhere close, etc. In particular this also means I don't fully disconnect from work if I have to carry laptop/phone with me. This kind of stress slowly accrues long term. All in all: staying alert for oncall is some sort of work. A physical security guard gets paid for keeping an eye on things even when nothing happens; it's startling that so many devs don't.
  • tomerbd 4y ago
    I would go further and ask for a day off after each on call shift
  • bartvk 4y ago
    That's a very good point. I always ask when they last worked in the weekend, but I didn't consider work expecting you being on-call without mentioning it.
  • neogodless 4y ago
    Never heard of SLO before, but I assume you mean this? https://www.bmc.com/blogs/slo-service-level-objectives/ https://www.bmc.com/blogs/slo-service-level-objectives/ (I've also never done on-call!)
    • rednum 4y ago
      Kinda. In this context I mean "response SLO" - how much time you have between receiving the page and starting debugging stuff. I think it's also important to clarify; I've been on rotations with response SLO ranging from 5 through 30 minutes to unknown: literally my manager couldn't answer the question "so how fast do you expect me to react" (in hindsight, that was a pretty big red flag about how team approaches production that I missed).
  • llbeansandrice 4y ago
• willcipriano 4y ago
  My two most important questions don't appear to be on here. "What has employee turnover looked like?" This is the biggest signal to me, a lot of businesses hire and are unable to retain anyone after the honeymoon period wears off. If you can't keep employees I'm not interested. They also can't really lie about this since once I join the team git blame is going to give away that they had lots of previous employees working on the project who are no longer here. "What would my on call expectations be? Would you expect to reach me out of hours?" They cover monitoring and on call but not as directly as you need to. Devs may not have a explicit on call rotation, but many orgs have implicit on call expectations. Asking directly like this can make the implict explicit. I need to know this to set a price. "We expect you to jump in when there is an issue so we need to be able to reach you" is 24/7/365 on call in effect.
  • bbarn 4y ago
    > "What has employee turnover looked like? I prefer to ask "What's the average tenure on my team, and how does that compare to the rest of the company?"
  • dennis_jeeves1 4y ago
    Good questions. >Asking directly like this can make the implict explicit. I need to know this to set a price. You are sure to be rejected in 99% of the cases, lol. But that's the point, correct?
    • willcipriano 4y ago
      I mean if they aren't talking 200k or more I'm not doing 24/7/365. I haven't found you need to at below that.
• 0xbadcafebee 4y ago
  I want to find any red flags at the company, so I'll straight up ask my interviewer one or two of: - What is the most rewarding part of your job, and what is the most challenging/difficult part of your job? - If you could change one thing about your job/the company, what would it be? - Would you say it's easy or difficult working with your current team? - Are your corporate policies clear & does everyone know what they are? - Are there any major impediments to getting your job done? - Does your team/company have well-organized documentation? - Is it clear how to communicate with other teams? - Do you think management is doing a good job? - How much would you recommend working here? - Are there any major problems here I should know about?
  • Double_a_92 4y ago
    But the interviewer most likely is not doing the same job that you are applying for?
    • 0xbadcafebee 4y ago
      That's fine; the idea is to get an idea what it's like working there in general. If they have problems, I might expect similar problems. All things being equal I'd prefer the job where people are happier and have fewer problems overall.
• respondo2134 4y ago
  A lot of these questions are well-meaning but clumsy or obvious, or even warnings to a hiring manager: * How long am I expected to remain in this position? => This person will be gone within a year. * What will be my day to day responsibilities? How much time do you anticipate I would spend on each one? => This person will consume all your time as a manager. * What are your group's best and worst working relationships with other groups in the company? => This person doesn't understand that job interviews are a first date; you find this out yourself during the marriage. * Diversity Questions: This person doesn't really understand what diversity is, or why it's important. Some of the culture/company questions are quite good, but they're all mixed up with HR questions about insurance and co-pay and dress codes. I don't mean to say these are not imporant, but they are definitely not appropriate in the same conversation as "what's your biggest current challenge and how could I contribute to success?" Rather than a list of questions by topic I think it would make more sense to guide someone through the pretty established interview phases. There's no point asking your HR screener about agile practices, or your technical interviewer about insurance co-pays. You would be far better to sequence your own "deal breakers" from most to least important and make sure you ask them in that order. Also determine what you need, want and can live with, then answer them yourself as you listen & learn.
  • deleted 4y ago
    [deleted]
  • notjustanymike 4y ago
    Had to check again on the diversity questions and yeah...wow. Almost no one has those numbers on hand, nor should they. We typically refer to it as Diversity & Inclusion, and a company's initiatives should include things like a diverse hiring policy, training on unconscious bias, how to identify and resolve in office bullying, anti-harassment training, and more. In an interview I'd want to know what the company has in place AND how seriously the company treats it (because some training is legally mandated). Boiling it down to percentages of demographics is naive.
    • Chris2048 4y ago
      > should include things like .. training on unconscious bias Hell no. If you are talking about "Implicit bias" (IAT), this has dubious scientific support. https://www.wsj.com/articles/the-false-science-of-implicit-bias-1507590908 https://www.wsj.com/articles/the-false-science-of-implicit-b...
• seb1204 4y ago
  I'm surprised to see little about how products are managed/defined. PO/PM.
• 0xbadcafebee 4y ago
  Hey, Everybody complaining about reading this whole list to your interviewer: please read the 2nd and 3rd paragraphs.
• zasdffaa 4y ago
  The one question that would decide everything for me but I can never ask: Are Your Managers Competent.
• witx 4y ago
  > Windows, Mac or Linux? Do I get a choice? Beware that if this is a hard-requirement for you, you might get "cheated" and or disappointed. They might tell you it's all fine that you use Linux, but then you go and see it's not linux-friendly at all as there's a shitload of things that keep breaking or you have to use a specific distro version, due to some required software or configurations the company requires you to use ...
• 5350-uiop-1130 4y ago
  only questions i need: is there mandatory overtime, if so how much, and is it paid? will tell you everything you need to know.
• codingdave 4y ago
  I'd propose that none of the answers to these questions matter. The follow-up question is what matters: "Is it working? And if not, what is the plan to correct it?" You'll get far more insights into asking why and how they make their choices than just asking what their current decisions are.
• photochemsyn 4y ago
  How many of these questions can be answered by the prospective hire before ever entering the interview process? If you take this approach, using lists like this as a guideline, you might be able to find out a lot about the company before the interview, which is a good idea. It'll indicate to the interviewer that you're interested enough in the company to do solid background research, which is likely to be a plus. The relative success of such background research (% of questions that can be answered, for example about testing, source control, company culture, etc.) will in itself tell you a lot about the company, i.e. if they're unusually secretive perhaps most of these questions won't be answerable before the interview. That might or might not be a red flag (Theranos was a rather secretive outfit, for example...). Also, note that some of the questions are phrased in what some will interpret as an unnecessarily antagonistic manner, and some people will confuse directness with arrogance. Others will appreciate the straightforward approach. Figuring out who is which is a common problem.
• wellpast 4y ago
  For codebase ask LOC. Ask them to run cloc on a repo and tell you what that code does for the business. That will tell you so much.
• whoomp12342 4y ago
  awesome
• jfabre 4y ago
  Reading from the comments, I'm astounded that the recruiters seem to think interviewing for a job is a one-way street where only the employer should validate if the employee is a good fit for the employer. I'm literally investing 40+ hours a week of my life into your company for at least the next 2 years and you think I won't vet you before accepting your offer? You need a reality check.
  • rufus_foreman 4y ago
    For the next two years. Companies, in my experience, don't make money off of devs that stay 2 years and then leave. You don't need a reality check, yet.
• lakomen 4y ago
  This list is too much. One can take inspiration from the list but ultimately you want answer to your own questions you have for the recruiters/companies. If I recruited someone and they'd ask me all these questions I would look elsewhere.
• douglaswlance 4y ago
  There's a problem with GitHub lists that accept PRs. They accumulate over time. Almost nothing is removed. No one wants to remove someone else's contribution. This list needs heavy editing, and some form of feedback mechanism by which those questions that perform best are weighted higher.
  • sh4rks 4y ago
    Also, the questions lack context. For example, what answer am I expecting when I ask whether the company is currently profitable?
• bayofpigs 4y ago
• sebastianconcpt 4y ago
  For candidates, reading these questions are a great exercise and depending on where you are in your career, you need some of these. In practice, that list has too many unanswerable questions (framed in a way that can only make the company or its team or its manager look bad). I think this all come from our analytical and correctness bias, and maybe some late bound experimentation plus garbage collection of the details that needs adaptation are a more practical solution. Feeling the vibe suddenly seems important.
• jillesvangurp 4y ago
  The advice with this list should be: you can ask anything you want but not all of it. Pick a few topics that matter the most to you and not randomly. But definitely ask questions. Especially when you have concerns around the topics that those questions cover. You can also highlight your own skills by asking pointed questions about things that relate to those skills. Also, maybe ask open questions rather than closed questions. Several questions on the list are very closed questions. Like what "version control system do you use?" They are not going to give you a lot of insight regardless of the answer and the answer is likely to be not very surprising. That's also a good trick as an interviewer. Ask really broad and open questions and see what comes back. It's not about what you answer but how you answer. If I was interviewing, I'd bounce those questions back. So in case of the version control question, I'd ask some open question about your experience or opinion on that topic.
• deleted 4y ago
  [deleted]
• dustinmoris 4y ago
  If you’ve been in the field long enough you can gauge a company simply by the tools they use and roles they hire for. They have vacancies for DevOps folks? Ok I know that the devs are not owning the full software development lifecycle and have no ownership of their products in production. Do they use Teamns and Azure DevOps? Ok it’s going to be a boring corp that dictates the tools which dev teams have to use from top down, because someone at the C level got a good deal for an entire Microsoft suite and now everyone is stuck with it. Do they only have devs working in a single programming language? Ok so they don’t really explore tech as curiously as they claim and don’t look for the best tool for the job. They make their work for their skills, rather than make their skills for the work they want to do. There are many cues which you get from a company before you speak to an single person. I judge hard, because those cues never lied to me.
• greenail 4y ago
  My rule of thumb has been to stay close to the revenue so perhaps asking if you would be working on topline related projects or bottom line related project. Related is to ask what the top priorities are and to try to understand where your focus would be in relation to the top 3.
• icarusfowl 4y ago
  Some of these are the type of questions you should ask after given an offer and before accepting. Unfortunately the standard interview process does not allow much time for interviewees to ask in depth questions and expect in depth responses.
• greenail 4y ago
  This is a very good question, but you should also dig a few why's into it: "What type of people are successful here? What type of people are not?" I also like to ask: "what's the best thing about working here? followed up with what's the worst thing about working here" You typically get some insight based on how open they are to the last question.
• dangerface 4y ago
  If an applicant asked me these questions the answer would be no to all of them. Do other organisations put that many limitations and control on their developers? Is there any space for developers to take charge of their own projects and have project ownership?
• trunnell 4y ago
  A few of these are good, but others remind me of that "How To Professionally Say..." list that was making the rounds a few months ago, which was actually a list of snarky, passive-aggressive and shockingly unprofessional phrases. By all means, ask your interviewer good questions! But please don't say this: "Does your code review process promote empathy?" "Tabs or spaces?" "Does the company provide snacks and/or drinks?" Ugh. When I was a junior engineer, I thought that the tools I used and the products I worked on mattered most. But now, after two decades, I can see that what actually mattered was the people I worked with. If you're interviewing, focus on the people you meet. Are they kind to you? If you had to correct a mistake of theirs, how do you think they would react? How do they interact with each other? Would you enjoy spending time with them? Do you feel like you might learn something from them? Take these questions (from the article) and focus on the interpersonal parts: * How do you estimate work? * How often does your team interact with other teams? * If we have a very successful year, what would that look like? Some questions I would add: * Can you tell me about someone who was promoted recently? Why were they promoted? * Can you tell me about some feedback you gave someone? How did it help them?
• morelisp 4y ago
  > Does your team encourage the use of SOLID and DRY design principles to avoid cyclomatic complexity? Whenever someone brings up SOLID in their resume or an interview I ask them to explain the L. So far it’s 0 for 3 this year. In this case I would also ask them to define “cyclomatic complexity” in a way this question makes sense, because it’s only weakly correlated with either of those.
• jblow 4y ago
  [Context: I run a video game development studio.] Whenever I interview people I explicitly make a section of the interview where I answer the candidate's questions, just in case it doesn't come up naturally or the candidate is a bit meek in that department. I think this is an important part of the interview. But if a candidate asked a bunch of these questions, it certainly would harm my opinion of them. I do not recommend using these questions as a guide. Why not? For one, a lot of them are petty and kind of annoying, so you will come across as petty and kind of annoying. (Oh my God, if someone asks "tabs or spaces?" that is a no-hire right there.) But also, note that many of these are leading questions for which there is supposedly a definite right or wrong answer ("Do you regularly correct technical debt? Do you use MVC or similar code structuring?" [This second question indicates a serious no-hire.]) Either these questions are appropriate, which implies you know more than the company does about how to develop software, or are at least its peer, in which case why are you interviewing there in a non-executive role, or why are you not off starting your own thing; or they are inappropriate, in which case you are signaling that you are going to be second-guessing everything the company does all the time, in a Dunning-Kruger kind of way, which is not something that anyone wants to deal with. Either way, the attitude here is that the applicant can stand in judgement over the company, comprehensively across all these categories involved in programming, from the outside, with no real knowledge of what happens there day-to-day. This implies that the company cannot have much to teach the applicant or offer in terms of knowledge and technique, because if it could, then the answers to many of these questions would be surprising to the applicant or would even come across as "incorrect". So you're signaling that you think you know as much or more than the company about how to develop software well -- but news flash, most projects developed even with positive answers to all these questions are trash fires anyway. But some projects are very successful, so clearly there are factors much more important than are covered by these questions. If you treat these questions as important, you are signaling that you don't really know there are more important questions (while also being annoying). Lastly, note that a lot of these questions are about minimizing the impact of the job on your life, "work-life balance" kinds of stuff. And there's a paradox here. On the one hand, I am not a fan of crunch or any kind of overworking people, and I do think it's reasonable for many people to avoid jobs that put you into that kind of situation. On the other hand, doing good work, for many people, is a primary vector for finding meaning in life; if you are not interested in investing time, energy and effort into a job, it probably is not meaningful to you, so these questions are kind of a checklist for finding a hollow meaningless job, actually. And if you ask a bunch of these kinds of questions from an employer, even one that is very careful about providing "work-life balance" (btw a phrase I never liked, I think it's a deep misconception, but at least we know what we are talking about), the employer is going to notice you keep asking this stuff and is going to get the feeling that you are someone who doesn't want to work very hard, unless you actively signal something like, I intend to work very hard within company hours but clock out exactly at 5pm, or whatever. But if you don't carefully do this kind of balanced signaling, and instead just ask a bunch of the questions from this list, you'll be giving the impression that you are someone most people don't want to hire, because why are you so preoccupied with minimizing work? It's a job, you are supposed to want to work there. Questions I would recommend in lieu of those on this list: * Why is the work important? What do I get from this job besides money (in terms of skills or other experience)? * How is the company deciding what is "good" or "bad" in terms of the software or the development process? Aesthetically, what is considered good, what is considered bad? * What kinds of decisions do I have the authority to make, and what kinds of decisions am I expected to defer upward? * How closely will I be managed? What size of problem am I expected to solve independently, and what size of problem should be deferred upward? * How far can I rise in my field by doing this job? * How much of my time do I spend programming, and how much in meetings? Note that none of these are questions with a pre-known right answer (except maybe a little bit the meetings one). They are also reasonable questions that should help maintain a good impression.
• ChiperSoft 4y ago
  Heya, I'm TwippedTech, the author of this repo. Every few years somebody spots this and it goes viral on HN again, and I hear all the same complaints that people made the last few times around. I don't know how many disclaimers I have to put on the text to get people to stop whining about the wording of something, or the size of the list, or the implication they would draw from someone asking one of the questions. There's always dozens of "hiring managers" who swear they wouldn't hire anyone who asked things from this list (good, I wouldn't want to work for you anyway). Every question on this list came from somebody's pain point, something that made their job uncomfortable. When a whole bunch of discomforts add up, it leads to an environment you can't stand working in. Nobody is going to reject a job over tabs vs spaces, but it CAN serve as a reminder to ask questions about their code linting and style requirements, and wow can there be surprises in there. You'd be surprised how quickly you can get annoyed when a company's style requirements clash with your natural habits, especially if there are other things making you dislike the job. And please, I am begging people, notice that this repo is almost a decade old. I'd bet a whole lot of people reading HN today weren't even coding when I made the first draft of this list. There are questions in here that probably aren't relevant in today's startup culture, and those questions will seem very dated, but there's also still a lot of very old companies doing things in very old ways, and these questions can be important to have in mind when interviewing with them. Just because you've never worked in anything but git doesn't mean that there aren't still tons of companies out there that never switched off of Subversion, or worse.
• EastSmith 4y ago
  My top question right now: Can I use my own hardware & will you monitor me (time tracking, screenshots, etc.)?
• what-imright 4y ago
  You don’t need this devs just say “I’m Jesus don’t throw your dirty wads of cash at me! You are not worthy of my genius! Money has no power over me! I am GOD now.”