A list of developer questions to ask prospective employers
github.com
github.com
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.
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.
They seem well aware of what you're talking about.
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.
The desirable qualities (besides being a very good programmer) for such a role include:
1)Being very calm and having exceptional judgement in a crisis. Crises happen a lot.
2)Being sufficiently frightened of breaking things that you proceed with caution
3)Being good enough and having enough confidence in your abilities that you actually manage to get things done in spite of the very significant consequences of mistakes.
EDIT: The wizards are out there, for example https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r..., but they're not evenly distributed, and perhaps the insane cutting-edge code they write (and the less insane code I write) isn't necessarily dependable, since by definition they lie on the edge of human understanding.
#til and also #wtf
In all seriousness, can you recommend any resources on why is that the case and how kernel is tested?
However, the kernel is fairly hard to test because it's the kernel:
- A lot of code paths are fully dependent on hardware that can't be mocked. How would you test the bootloader, for example? Or code that depends on a certain processor architecture? The only way is to actually run the code on that hardware.
- Similarly, it's hard to test the drivers. A lot of them are made by vendors, and the only way to test is against the devices themselves. Even if you could emulate the device and connect that to the driver, there's a lot of things that you won't cover (the communication path, the device misbehaving...)
- It's hard to test things that the runtime depends on. For example, if you try and test the memory subsystem, how do you manage the memory to actually run the tests?
Kernel testing is hard for the same reasons kernel development alone is hard, you're building the thing that all other tools require to run.
> - A lot of code paths are fully dependent on hardware that can't be mocked. How would you test the bootloader, for example? Or code that depends on a certain processor architecture? The only way is to actually run the code on that hardware.
My incorrect assumption was that one could run those tests in some sort of a virtualised environment where the host VM provides the tested component with the correct virtual hardware. The "hardware" itself contains mocks the test can access to run assertions. In other words, testing would involve checking the side effects. Come to think of it, that doesn't sound very practical. In fact, it sounds almost impossible to scale.
I realize that's not perfect -- not even close -- and I'm sure smarter people than me have considered that idea and rejected it. But, out of curiosity, I wonder if you know the reason why it wouldn't help at least add some marginal value?
Yeah, sure it is hard or even harder. But think about browsers. We run applications and we want to make sure they look and behave the same, but there are so many OS, browsers, versions, devices, ...
So do we have to buy a laptop for each? Maybe in the past, but today we "just" emulate it. The same can be done with kernel testing. Assume that the whole kernel runs emulated (which is the hard part) and then test the outout of that (in the emulator).
I wonder how Microsoft does this with Windows? A friend of mine worked on Intel GPU drivers and they had entire farms of PCs where the tested driver would be installed on top of fresh Windows installation. For kernels, you’d probably need something like that, but times a thousand…
I don’t know squat about kernel programming, though. :-)
The idea to use “fewer” for countable things was someone’s personal preference. https://www.merriam-webster.com/words-at-play/fewer-vs-less
“This rule is simple enough and looks easy enough to follow, but it's not accurate for all usage. The fact is that less is also sometimes used to refer to number among things that are counted.
“This isn't an example of how modern English is going to the dogs. Less has been used this way for well over a thousand years—nearly as long as there's been a written English language.”
See also the list of common counter examples.
Fewer emphasizes number; less emphasizes quantity. So, I would ask myself if I prefer saying the number of bugs or the quantity of bugs, and then choose accordingly. I prefer number, here. On account of that, I prefer fewer.
As to myriad, though it can be used as a noun (and apparently its use as a noun predates its use as an adjective), written language for the past 150-plus years prefers the adjective. (When Garner is talking about written language, he's talking about quality writing.)
I'm not saying you're wrong. But, style is as much about a sense of style as anything. Keeping language from going to the dogs requires a bit of dressing up.
It’s fine to hone your style and exercise your own preference, I have absolutely nothing against that. Correcting people is something completely different.
I think the relevant part of the "Exceptions to the Rule" section on that page is:
> The use of less to modify ordinary plural count nouns (as in "made less mistakes") is pretty rare in writing and is usually better avoided, though it does occur frequently in speech.
The exceptions (refering to distances/sums of money/units of time and weight/ statistical enumerations, phrases like "or less", and uses of "less" immediately following a number) aren't relevant here.
But both are "fine" in that they will be correctly understood.
> both are “fine” in that they will be correctly understood.
Agree! So much! I would go further, because I think this is the most important point: there is not a way to misunderstand the use of “less” in this context, which means that correcting people is purely pedantic, and not a functional issue or helping avoid potential misunderstanding.
Not only that, but sometimes people use “less” rather than “fewer” intentionally for countable things than can have a qualitative weight to them, as @danielheath pointed out. If the parent was trying to say that the bugs themselves could be both fewer in number, and also less damaging in scope, then less and fewer have two different meanings, and less is the more correct word to use.
> use of less […] is pretty rare in writing and is usually better avoided
Yes, I chose to emphasize that the rule is not absolute. Lots of people claim the rule is absolute, and a correction implies that point of view. My point is that even if using ‘less’ is better avoided, unsolicited corrections in public are also better avoided, because the rule is not absolute and in this case cannot be mistaken or misunderstood.
Worth noting that HN comments are not formal writing, and social media by and large is closer to informal speech, so the snippet you quoted can be viewed as validating use of less in this specific case.
Insert ironic joke here to make an open sandwich.
Until you have worked with (internationonal) accounting, you don't realize how complex it can be.
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.
"How you hire is whom you hire."
Along the same lines, for the candidates, I might now have to add:
"The question you ask* are as important as the answers you give."
That said, unfortunately, quite often the candidates' side of the process is a second class citizen. If I had $20 for everytime the candidate was tossed token "We have 5 minutes...got any questions..."* I'd have Bezos' FY money.
And now we're back to where we started: How you hire is whom you hire.
*If they give you sufficient time for questions.
One thing I find increasingly strange is that it is extremely taboo for the candidate to ever ask any technical questions of their interviewers of the same variety the candidate is asked.
As I've grown more senior in my experience it has become increasingly important to me that my peers and coworkers are as technically competent as they expect me to be.
An example: I was interviewing at a company that has the reputation being fairly elite. The role wasn't my ideal role, but given the reputation of the company I would happily take a less desirable role if the team was truly world class and passionate about engineering.
While some of the interviewers were clearly excellent, there was one point in the process where I was being grilled on Python internals. It became increasingly clear that the interviewer's depth of knowledge was very likely limited to the set of questions they were asking me. The topic of threading in Python came up, and so I gave usual mentions of the GIL and IO bound vs CPU bound tasks, the trade off of multiple processing versus threads etc.
However I personally find the design decisions behind the GIL really interesting since it brings up a nice discussion around memory management in Python. I brought some of this up causally at the end just to chat with the interviewer a bit, but it was clear that this well outside of their understanding of the interviewer.
I just find it odd that it's fine for companies to aggressively grill you on a range of topics and walk through complex algorithms cases, but you aren't really supposed to try to get a feel for how technically skilled your potential new colleagues are.
But, to your point, the companies that I've enjoyed the most are ones where a technical discussion (rather than grilling) naturally breaks out during the interview.
I wasn't certain whether he was trying to avoid being asked questions, but the questions he asked were insightful and useful to help evaluate him.
The solution is simple. Make the meeting more conversational, at least initially.
It's a form of dating, if you will. No one wants to be interrogated. No one wants to do all the talking or all the listening. Yet most inteviews are some derivation of what would be a bad date by most reasonable accounts.
More eHarmony. Less Tinder.
p.s. I'd even recommend that prior to the first meeting, the company send an email / docs titled FAQs that covers the obvious stuff. Is it a new position or a back fill? How long is it open? Next steps in the process? Not only does this inform the candidate it's great context, it shows a level of thoroughness and processionalism, etc.
But I've never considered asking a full interview worth of questions over multiple sessions. "As much as, if not more than" seems really exaggerated. That implies that candidates are asking 30-60 minutes of questions straight, then doing it again a week or two later. Maybe even asking the employer to do a take-home? I can't imagine the look on an interviewers face if I asked them to do a take-home.
I got 10 different answers but with several common themes and threads running through them. Each individual is biased by their own experiences and perspective, but the commonalities are what speak to the culture.
No one person's answer was sufficient to give me a clear picture of the truth.
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.
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.
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.
No, I didn't miss these, those are the most important part of the interview.
Here's two example answers to demonstrate the importance of the "why":
"We use git because everyone else does" is the definition of cargo culting, good you use git but not great reasoning.
"We don't use git because it turns out 98% of our code changes are to XML, and we've found git for XML means even the simplest merge is a nightmare", code base sounds terrifying but that answer tells me engineers working there are thoughtful about their process.
The series of questions that logically follow very is natural stuff like "do you use CI/CD?", "how are PRs handled?", "what are code reviews like?" these are basic questions that give me as an engineer as sense of what the overall technical culture is like. And to your point, the more clearly the interviewer can answer these it means the less time it takes to get changes shipped to prod. Engineers asking these questions aren't bike shedding, they're making sure they are going to a good environment where they can focus on writing code and shipping features.
Frankly if conversations like this aren't part of your standard interviews then it doesn't sound like a very mature engineering culture. If you're uncomfortable with these conversations, that is an incredible red flag.
I disagree with this, and Git isn't even my favorite source control system (Mercurial is). Using the same thing everyone else does has very clear benefits: new hires will already know how to use it, most CI/CD tooling out there expects it, StackOverflow will have more posts about it, you'll be able to fork libraries from GitHub and host them locally without having to migrate source control or use two systems, etc. etc. There are lots of reasons to use the same tools as everyone else besides cargo-culting.
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.
To me the reasons that question should be asked carefully are that:
You’re interviewing to join a company that works a certain way and (unless it’s a startup) does so successfully enough to pay a salary. There are many valid ways to do source control, and a lot of people like to moralize their favorite one and make bad assumptions about how a company runs based on whether they use git or Perforce or Subversion.
The important question is just whether the company uses source control, and that’s what the Joel Test this question was borrowed from asks. Asking which one is fine, but requesting justification for it is the part that could come off as naive and/or condescending. That part of the question to me feels somehow a tad aggressive, and it feels focused on details that matter far less than whether the product ships or not.
Given a random interview at any size company, chances are high that the person you ask did not make the source control decision, and does not know why it was chosen. They might want to rationalize or justify something, but in any case, it’s probably not going to change, and it doesn’t really matter why it was chosen.
(Nothing against fossil, it sounds lovely. But there needs to be a good reason to choose a niche product here.)
When Joel wrote the Joel Test, git use was nowhere near as widespread as it is today. Doesn’t it predate GitHub? I mostly feel like the likelihood of this particular question being helpful in an interview is near zero, since nearly everyone’s on git for code anyway (or Perforce if there’s binary content.) I see comments here from people experiencing odd setups, but I’m pretty sure that is not the norm today.
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.
(After all why not, there is even e2ee built-in!)
https://ashtonmedia.com.au/wp-content/uploads/2015/11/Busy-c...
Linus Torvalds
WhatsApp is absolutely terrible for source control as you end up with people accidentally downloading an old version or not uploading a recent version.
Something like FTP or an external hard drive might have been a reasonable alternative. But today, might as well use Git.
Git is better for distributed development and pushing to upstream via layers of review/approval.
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.
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...
You can especially see it now with long COVID reducing mental capacities short or long term: processes that were designed to require only low mental load (thanks to automation and tools) didn't break and business continued to operate smoothly.
Accessibility is good for business.
They have to have tough time hiring anyone or retaining newbies, even if it is about experienced people.
I don’t know exactly what is cut and dry, but as I age it’s endearing to hear young people having trouble imagining effective collaboration before git. That says something very good about the tools we have now, and I hope they keep improving. But the days before git and even before CVS or email or internet weren’t quite the Stone Age some people imagine, there was plenty of effective collaboration, so maybe you can take that knowledge and do some research to answer your question. Knowing that effective collaboration is possible by copying code around, what then is truly important? We’re collaborating faster and on a larger scale now, it’s getting better, but it was exciting then (possibly more than today) and working well enough to get us to where we are now, right?
RCS was an alternative to SCCS, which was written for the IBM System/370 in 1972.[1][2]
All of these are very workable for software development by a co-located group of engineers. They are full-featured, not "limited". CVS is currently used by OpenBSD.[3]
[0] https://en.wikipedia.org/wiki/Concurrent_Versions_System [1] https://en.wikipedia.org/wiki/Revision_Control_System [2] https://en.wikipedia.org/wiki/Source_Code_Control_System [3] https://www.openbsd.org/anoncvs.html
I wonder what happens when the "source master" receives everybody's tarballs at the end of the work week? Manually inspect them all and manually merge the source files? Or, pick one at random and tell the engineers to merge on their own next week?
Add some basic tooling about that collection of tar balls and you're half way on re-implementing git.
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.
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.
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.
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.
https://docs.github.com/en/get-started/importing-your-projec...
And I am ok with managers filtering out people who ask questions.
From both perspectives, mission accomplished.
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.
Can drop the "and why" for that though.
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.
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.
My comment isn't about source control. It's about warning applicants not to over-obsess about technical details when other stuff influences job happiness much more than git vs mercurial.
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.
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.
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.
6 years later, I value my time and mental health more than compliance.
Of course on should only pick questions that really matters to them / which may trigger an interesting talk.
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.
How am I supposed to ship if your SC is such a mess?
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).
People on HN assume some of these things as givens but it's not the case.
I know how to add, commit and push, but that's it. For anything else I have to use a search engine or tool like git-cola.
I liked hg/mercurial better, but no one uses that.
And all the little error messages of git, change a file BOOYA you can't pull anymore and have to jump through hoops. I don't like git.
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.
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.
Appreciate your clarifications none the less.
For example, they could be using an internal CVS repo. Or, they could be using GitHub.
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
I will tolerate git and SVN and thats about it.
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.
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.
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.
In our interview process we have an informal session totally dedicated to answering the candidate's questions about anything. The setup is simple, two of our engineers and the candidate hop on a call (or meet in person) and just talk.
Many of the folks who have accepted our offers refer back to that session as the thing that really sealed the deal for them.
I don't have great insight into the meta for picking the right questions, but I feel like people really don't take advantage of their power in job-hunting. Ask to talk to an engineer currently on the team. Ask to talk to someone more customer-facing to talk about the product and the business (especially if it's a small company). Or don't if you don't care about those things.
These lists are a useful tool in figuring out what you might care about or not care about. I think that's the best insight into what meta to follow: some introspection on your values. Finally, as with anything else, it's an iterative process. You won't get everything right the first time and the target moves as your values do.
Early this year I spent 3 or 4 months job searching for my next role and ended up not taking any of the 3 offers because something seemed off at all of them. After I got the offers the recruiters turned into used car salesmen which was also a different, terrible experience. So even if you do end up with the insight it can be a gigantic waste of time.
I just don't really understand not asking a question whose answer is highly valuable to you because you're worried about getting red-flagged by the company. I also don't really get pursuing offers from companies you don't care about unless there are heavy job market pressures eg being a new grad/looking for your first job in the industry. Even then, the idea is to just get your first job, so your values are different than when you're more senior.
Recruiters can absolutely be awful. I've straight up ghosted multiple because they were unable to take "no" for an answer.
Sometimes the dumpster fire is visible right from the interview.
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.
- 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.
Good-ish example: - On-call T1 was mostly business hours - T2 during off-hours/weekend - Decently large rotation so you're on-call less frequently than every ~6 weeks
Bad Example: - Escalation goes to another team that likely doesn't know much about the system - T1 24hrs/day - Small team so on-call is fairly frequent
Both of these are still not good examples though. There's no compensation for the on-call hours. The team in my "good" example recognized heavy on-call load and was okay with taking some time off after a heavy on-call week "off books" but that's flimsy at best.
I think this would be a great case for a union personally. Engineers have done very well but I don't think there's enough desire to fix this without a centralized coordinator like a union.
https://www.bmc.com/blogs/slo-service-level-objectives/
(I've also never done on-call!)
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).
- "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?"
Absolutely. If a company doesn't use any modern versioning system that's probably one of the biggest red flags there are.
I think it's up to every candidate to decide what's important to them. There are so many jobs, candidates can be choosy, so they might as well find a company that fits them. For the candidate that loves Git and absolutely requires it to be used for them to be fulfilled, it's a good question to ask. It's hardly going to be difficult for a candidate to find a company which answers yes to that particular question, so might as well ask and then skip a company that says no.
I agree a lot of these are extremely specific, but I think there's probably a middle ground where questions can be probing without being extremely specific.
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.
> 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.
If you dropped half it would still be way over the top.
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.
The point of it is just a list of suggestions, use none even, just ideas/inspiration for what you might want to ask. As someone who can never think of any questions in the moment (and interviewers have seemed to think that's not a good sign in the past, small sample size though and I may be misreading), I appreciate it.
The first question: "Why are you hiring for this role?"
What signal are you getting from the reply? Why is a certain reply important?
When interviewers interview they are not focusing on the questions... they're focusing on the signals and how these contribute to a decision. If I have a question and I cannot determine what the question tells me, what the signal is... I bin the question.
Without "Why ask these questions"... this list is not very useful and really signals a disinterest in the company, role.
My tip would be to ask questions that reflect what you care about. If you've been burned by work/life balance, ask about work/life balance. If you've experienced discrimination, ask about diversity, policies... hell, ask to see the policies as you want to know it's a safe workplace. If you've done dull tasks, ask about the work in question and whether it takes you in a direction you want to go in.
Know why you're asking questions... don't just ask questions.
- Good: We are growing and need more capabilities.
- Very good: We are developing a new X and are hiring to support that.
- Okay: We are replacing headcount.
- Bad: The department is chronically understaffed and overworked; you're going to help out.
- Very bad: Everybody starts in this department and the turnover is high.
You generally won't get a straight answer in the bad/very bad line, but you should talk to prospective coworkers to see if they agree.
When I'm hiring, I assume that most non-core questions represent exactly what you suggest: trying to avoid prior bad experiences. When I'm being interviewed, I suspect that non-core questions are trying to avoid prior bad hires.
You see this a lot, companies with insane hiring processes so they "only get the best", and then won't even do the basics on their end like listing the salary.
Ideally companies would be up-front and transparent about all of these but none of the companies that I've looked at over the last 15 years had the foresight to prepare an information package that would answer the bulk of these.
Incidentally, that's a thing I could really get behind: to standardize a list (possibly this one) and to get companies that are on the market to pre-emptively answer them so that employees would have a fair shot at comparing companies on their own time.
Honestly, it's not uncommon to have 4 interviews at a company, and each person asks "do you have any questions for me?" A list like this is a good source of questions for these stages. Obviously, you shouldn't ask every single one, but when you meet with people on your prospective team, you should have SOME questions to ask them and this list is as good a resource for that as any.
If for example you're asking for a take home assignment or a multi-hour technical interview, it's not unreasonable at all to ask for a largish list of questions.
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-coordinat...
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.
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.
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.
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.
This list needs heavy editing, and some form of feedback mechanism by which those questions that perform best are weighted higher.
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?"
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?
"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.
I prefer to ask "What's the average tenure on my team, and how does that compare to the rest of the company?"
>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?
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.
- 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?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.
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 ...
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.
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.
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.
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.
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.
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.
You'll get far more insights into asking why and how they make their choices than just asking what their current decisions are.
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...
If I recruited someone and they'd ask me all these questions I would look elsewhere.
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?
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.
But also, those questions are very useful to know what working for the company might be like. For example, my perception of the company depending on some answers:
- You don't use source control: the company doesn't really care about the development process. Very likely to be missing other development tools, and my job is going to be harder than it needs to be.
- You use Subversion: A signal that the company might be stagnated on legacy practices, systems and tools.
- You don't use OSS libs: the company tends to reinvent the wheel. Unless there's a good reason, looks like I am going to fight internal teams for getting standard features to the shared libraries, and my job is going to be harder because it looks like the process to get already-written code onto the company codebase is hard or even impossible.
Those signals are going to go into my decision process. Maybe not a dealbreaker, but might make a difference when comparing to other offers.
And yes, when people have asked me those things, I've been happy to respond. In fact, it shows me that they know what they want and probably have experience in those tools and the advantages/drawbacks of each approach.
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.
Have you ever worked at a TFS shop?
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.
will tell you everything you need to know.
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.
> 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.
I am male. If I suspect that will be a problem, no hire.
I am Latino. If you insist I call myself LatinX, no.
I appear white to other whites. If you try to lecture me on the issues Latinos face, thinking I’m white and from the US, no way.
It happens, but is usually some laughable SJW who thinks they know my culture without knowing my culture. If this were a interview setting, then a hard no.
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.
Same thing as with diversity metrics: This should not quality or disqualify you from anything, why did you feel the need to mention it?
This makes me feel some sort of uneasy. I wouldn't want to be around people who judge me or people in general by random things that "happened" to them at birth.
Oh wait, the list actually has a question about the skin color...
Seriously?
Companies shouldn't care about any of this data, neither sexual orientation, nor race or gender... just pick the best candidate, no matter those factors, and you're done.
Discrimination is a federal and state crime with severe penalties if either the state or individuals sue. I believe companies are in fact legally required to collect this information. If you don't want companies to protect themselves then go lobby your government representatives to not make it a crime.
edit: I also made no comments on companies using this to make hiring decisions. Interesting how you jump from a candidate making their own decision to not join a company to that.
Seriously? This is like a huge NO-NO here... like asking a woman if she's planning to get pregnant and stuff like that.
I don't have to lobby, since it's illegal here already. But most of our worker protection laws were written in socialist times.
Edit: that’s not to say all companies with large engineering departments filled with one kind of gender/race/sexuality are always bad. But it should be examined to ensure it isn’t a result of a legally vulnerable workplace.
Also in order to establish the level of diversity in the company, they need to count how many of each kind of person there is.
Everyone in their respective buckets, amirite?
No, they are just more willing to hire you for reasons other than your actual merits as an employee.
* 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.
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.
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-b...