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.
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.
> 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.
He was looking after and developing a key set of extremely sensitive servers (custom key/value stores that served all the global risk and pricing infrastructure for a major investment bank).
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.
For the longest time I viewed kernel programming as an exalted realm of "optimized bare-metal software written by visionaries and wizards" (like operating system core developers of the Dave Cutler variety). Having had the misfortune of dabbling in reverse-engineering Windows drivers and debugging in-tree Linux kernel drivers, I now believe they're often messy hackjobs written by low-paid average-skilled embedded developers, no less fallible than the average enterprise Java programmer (https://blog.ffwll.ch/2022/08/locking-hierarchy.html expresses a similar sentiment). And I feel the maintainers are sometimes spread far too thin (Dmitry Torokhov manages a good chunk of Linux's entire input system, no wonder he lets mistakes slip by in the touchpad driver, I'm just disappointed I reported a bug to the mailing lists and never got a reply after like a month).
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.
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.
Interesting, I quickly checked the source before posting that comment and didn't find any, but I was expecting them to be co-located for some reason. Thanks for sharing.
> - 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.
Virtual Machines are a really poor rip-off of the original thing. Users rarely notice tho because the kernel hides that away.
Like GP said, real hardware is difficult to mock good enough to be useful for testing. If you try it in practice, your emulator will only be one bullet point in the list of platforms to support...
I had to attempt to write an interface to the floppy and serial controller for IBM PC compatibles to learn this.
The direction people are moving towards is re-hosting and directed emulation, where you run the code in an environment where the analysis tools are better and emulate just enough of the platform that the code thinks it's executing natively. Some of the published work even looks at the expectations encoded in the source to emulate what it's expecting from the "hardware". Since the HW is fake, testing new configurations is just a config change away. Take a look at [1], [2], [3] for published work. I also have a tool that's used in a couple companies able to rehost simpler linux device drivers and embedded firmware without source code modifications. Everything's encoded as DT files, so you can just use the configs already in the kernel tree and even do fun things like simulating physical hardware in a game engine.
I know some developers test with VMs with emulated architectures, but it almost requires manual testing and seeing how things work. As you say, it's fairly impractical and impossible to scale, you can't really get too much useful information out of VM memory and registers.
Not to mention, if the emulation isn't 100% accurate, you could still run into something odd. Especially if you only emulate what's in the spec and not the actual hardware.
Naive question: Couldn't you manually test against the hardware/devices, confirm the code is passing, identify the salient behavior that is hardware-specific and needs to remain invariant under refactoring, and write unit tests for just that?
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?
> identify the salient behavior that is hardware-specific and needs to remain invariant under refactoring, and write unit tests for just that?
I don't think you really can. There will be things that can be different between runs (e.g., a DMA transfer) and not necessarily mean bugs. I don't think there are many fully stateless drivers where that kind of effort would both cover a significant part of hardware behavior and yield good enough code coverage.
Can you record the register writes, DMA transfers of a successful run, then run the kernel in an emulated environment and ensure it makes the same writes, and presents the same results to userspace given the same data returned back? This is probably a lot more practical for a mouse than a high-bandwidth webcam or display where the "expected" logs can run into the megabytes or gigabytes for a few seconds of recording.
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).
Browser and kernel development couldn't be more different.
> Maybe in the past, but today we "just" emulate it.
"Just emulating" is almost impossible. For testing to be actually reliable, you'd need to recreate all the hardware behavior in code. OS virtualization relies on re-exposing the hardware and kernel primitives to VMs, no VM is reimplementing the Intel architecture for memory management, for example.
> then test the outout of that (in the emulator).
Another hard topic. What's the output of a kernel? In an emulator the only thing you have is access to the memory areas (RAM, screen, devices). You can't really rebuild the state of the kernel, or access internal structures that tell you information about how it is. If you're lucky and advanced enough in the boot sequence that the kernel has configured the serial port for comms and debugging, you might be able to get some information, but not that much, and it'd still be impossible to test certain parts of the boot sequence.
> OS virtualization relies on re-exposing the hardware and kernel primitives to VMs, no VM is reimplementing the Intel architecture for memory management, for example.
That's fair. But in the same way that the VM relies on that the host OS handles operations correctly, the kernel can assume the same, as long as there is a clean separation (so that one kernel doesn't influence the other).
Of course, if you have a bug in the (old/other) kernel that influences the tests themselves then that wouldn't work, but I would say that this probably makes up a very small minority of cases.
Just like if Intel runs tests for their CPUs on other CPUs and those other CPUs are buggy...
> Another hard topic. What's the output of a kernel
The kernel has an interface and if I ask it to write something and then read it back, I have an expectation about what happens. I don't need to care about the state of the kernel (neither should I) as long as the result is good. Only for certain performance-relevant things I can see that this might be a problem.
> and it'd still be impossible to test certain parts of the boot sequence
I'm neither a kernel nor a browser developer ;) but I would be interested in an example. You are probably right, but I fail to see what that would be.
Yeah I think that's true. From my experience it's the same for testing software in general - you can mock things but having actual tests that test the behaviour of dependencies is tricky since you have to emulate those for your tests and that can be a lot of work.
But since it covers your for all future changes, it might still be worth it, because otherwise you either have to manually retest with actual hardware or accept a higher risk of bugs.
Last I checked, the testing strategy was „all maintainers’ computers should be on the nightly build and report bugs/crashes they experience”.
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…
If you haven't any experience of doing proofs of correctness, it may be worth getting some before being certain about what you prefer. Proofs are hard. Proofs of something like the kernel... dream on.
Time to unlearn some things about English that aren’t true. Less is fine to use. Also, myriad can be a noun, literally has always been used figuratively, responding to ‘how are you?’ with ‘I’m good’ is perfectly fine. I’ve tried correcting people too, but the older I get, the more I find out that it’s me who’s wrong and policing language is almost never correct.
“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.”
This is what I can gather about "fewer versus less" and "myriad" from my Garner's Modern English Usage.
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.
“This isn’t an example of how modern English is going to the dogs.”
It’s fine to hone your style and exercise your own preference, I have absolutely nothing against that. Correcting people is something completely different.
arwhatever made a specific comment about the use of "less mistakes" vs "fewer mistakes", not a broader claim about the use of fewer/less for countable/uncountable amounts.
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.
I don’t follow your distinction about broad vs specific. The specific correction was offered based solely and entirely on the general rule of thumb, no? What other line do you see here?
> 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.
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.
For hiring orgs, I have a phrase that I repeat quite often on LinkedIn:
"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.
> quite often the candidates' side of the process is a second class citizen
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 conducted an interview recently where I started by giving the candidate time for questions, and he occupied nearly all of the allotted time that way.
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.
Absolutely. I've done a lot of interviews for different companies, and it is clear when someone is asking a pre-canned list of questions vs. someone who has real questions and genuine interest. I wouldn't give a no-hire recommendation just because someone did that, but it is definitely off-putting. Genuine questions asked out of interest can lead to an interesting discussion which could give a boost to a candidate. (Obviously, actual skills are the most important thing, but when choosing between a couple of candidates, both seeming fits for a role, it could tip the scales.)
These days the companies are interviewed just as much as, if not more than, the candidates. It's the new reality, or at least current reality. Pushing back against it will push that position to the bottom of the pile for (anecdotally) many candidates.
I've certainly gotten into the habit of "interviewing the interviewer", in a reasonable sense. After all I'm looking to see if the job suits me just as much as the employer wants to make sure I suit the job.
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.
This is the best interpretation of this list. It’s a great guide to understand what topics you care about. Maybe there are a couple questions in here that would raise red flags for you. You should pursue those as conversation points.
Hi don't think anyone would want or need to plow through 100-200 questions but I'd certainly not take a job without getting good, clear answers to perhaps 30 of these.
It's also possible to get answers to many of these questions just by talking to your interviewer, no need to go asking questions in interrogation style, or as a candidate you might get answers to them as part of the interview process. Many of the questions about the company can (and probably should) be something you research before interviewing, or even applying.
Another way to phrase this is that yoo met someone who was so much more talented than you expected and understood (in one dimension), that you almost rejected them to cover up your insecure ego, instead of being open to learning from someone who behaved differently. Congratulations on overcoming and making the right decision.
The last interview loop I went through, I met with 10 different people along the way. I asked every single one of them "What are the qualities that make for a successful engineer at XYZ"?
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.
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.
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 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.
> i think you missed the "series of questions like" and the "and why"
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.
> "We use git because everyone else does" is the definition of cargo culting
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.
They may use git, but that doesn't mean they use git correctly. You would have to ask a lot of questions to uncover this during an interview. I've personally witnessed a variety of bizarre workflows, individuals who don't know how to do merges, people who haven't learned how to cherry-pick, so they copy stuff manually. I could go on. It's not git specific. I saw similar troubles in the subversion days, and CVS days before that.
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.
FWIW, my flippant gut reaction was the same as parent’s, but really none of us needs to jump to logical extremes or put up straw men, the better thing to do than make assumptions about the other person is to have a conversation and ask about it, right?
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.
I would for sure want to know why a company was using svn or fossil for source control (just to take two examples)… there might be good reasons, but either one suggests that the company may not be making the right trade-offs.
(Nothing against fossil, it sounds lovely. But there needs to be a good reason to choose a niche product here.)
I happen agree with those two specific examples for specific reasons. I’m less sure about the suggestion that a niche tool needs to be justified. Why does there need to be a good reason? I’ve had jobs with in-house source control tools, and there were perfectly fine reasons for them at the time, and the companies were IMO making better trade offs than people choosing the thing everyone else was using.
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.
If y'all aren't using git then I can end the interview quickly and save everyone some time. I will never get the 3 years of my life back that I got suckered into working with RTC.
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.
"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."
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".
It probably wouldn't have been as bad if the emails didn't run out of space every week or so.
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.
Patches over email with a strict process (like one benevolent dictator approving each one) is much much better than random snippets of code (or I suspect vague descriptions of it) via whatsap message. Maybe I am adding too much to what OP said though.
True, and I agree. But at the same time, distributed development on the scale of the Linux kernel wasn’t that common in CVS’s time. CVS was adequate for it’s day. I’m glad we have git now, and I’m never going back to CVS, but at least it was source control and did it’s job just fine in lots of companies, right? My first real job was all CVS, and I don’t remember major problems. I feel like git didn’t reduce the number of issues as much as it enabled workflows we didn’t have before. All in all, I think I’ve watched more people lose data with git than with CVS, just because git is complicated so when things get messed up, some people nuke their repo rather than fix it, and because git stash is dangerous.
I always liked CVS better than Subversion. Merging was easier, and admin could manually fix the repo, if you broke it. I think OpenBSD is still using CVS.
Git is better for distributed development and pushing to upstream via layers of review/approval.
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...
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.
Relying solely on developer discipline is a risky bet, there is always a chance the developer will forget something or external events will cause them to be distracted just long enough to skip an important part.
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.
It is cut and dry. You need to be effective at collaborating with other people. I use git for everything even my own projects. How can you collaborate copying code around effectively?
All git really does is copy code around for you. ;) It’s certainly nice that it keeps track of the code it copies around, but I’m sure you’re aware that before git, Linus and everyone developing Linux collaborating extremely effectively by emailing code patches around.
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?
Well, version control wasn't always a thing and people got by just the same. So I can see how it could be done but the key is 'effectively' and the ability to quickly review and accord changes to a larger code base as well as to compare versions in a divide-and-conquer manner to see where a particular issue got introduced is priceless. So it would be a bit like trying to drive with the handbrake on, you can do it but it isn't an advantage.
Having Googled it, CVS came out in 1990, and there wer other pre cursor systems. So, pre-widespread internet and collaboration, yes, maybe people had some limited control systems that worked, but I don't think it even comes close.
CVS came out in 1986, and it is built on top of RCS, which dates to 1983.[0]
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]
And the car was invented in the early late 1800's and yet there are people who use bicycles.
The date when something is invented or comes into common usage does not automatically imply that everybody should use them. Though in the case of version control there are no good reasons not to use it that I'm aware of, even so, some people don't seem to require it to be able to be both productive and qualitatively at a very high level.
everyone has a copy. you email patches to someone whose job it is to review them and maintain the release version. they publish that to everyone else who uses it to replace their local version. repeat.
So they DO have source control. It's just 100% manual instead of (partially) automated.
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?
Gotcha. Yeah, it makes sense from their perspective to not use version control if they're journalling everything already. I can imagine the thought is what's the point of the extra process. I don't feel that way personally, but I see the point.
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.
"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 atall 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 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.
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.
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.
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.
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.
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?
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.
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.
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?"
> 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.
I said "a series of questions akin to", not "this single question". Please don't take my words out of context.
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.
I think "what source control tool do you use" is fine, it's the "and why" where I start to think that you're asking the question to be combatative. I agree if you're expecting a couple word answer like Github etc, then perfectly good question to ask.
The why can be really important though. We do X because Google does it, or something like that is often a red flag because they have some insanely convoluted process that they don't need. knowing that things are selected that fit the size and scale of where a company is or will be soon is important.
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.
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.
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.
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.
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.
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.
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?
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).
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
+1 on this answer. Ideally any interviewer intentionally sets aside time to answer your questions. If it's a total one way street that'll tell you something about the company.
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.
Every interview process I've had after I got my first job I was able to talk to basically anyone I wanted and set up extra calls just to ask about the company, process, product, etc.
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.
Still, there's some questions you'd want to ask that would be an immediate red flag but regardless of answer outcome you still want a job offer since you are interviewing multiple places in parallel and you don't know how picky you can be. You end up not asking those questions because they'd put your "culture fit" at risk. You can ask other questions and try to read between the lines but bottom line it's tough to know exactly what you're getting into no matter how much access you get.
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've personally never experienced this sort of thing. It's entirely possible I'm a combination of lucky and privileged (eg I'm NT as far as I know). That aside, I feel like you need to determine what your values are and pursue lines of questioning along those. They should be things that are near deal-breakers.
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.
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?
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.
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.
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.
I agree. I think on-call is a big gotcha of the industry and different companies I've been at wildly succeed or fail at this. Some of it can be more team-driven even if corporate isn't on board.
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.
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).
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.
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?
> 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).
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.
> I mean, is your entire decision going to be made on GIT being used?
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 think the problem with open-ended questions is that it gives the person asked the opportunity to focus exclusively on the positive. With a question like "tell me about your development process", it's broad enough that it would be easy to miss what they aren't focusing on.
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.
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.
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.
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.
Do you look at every 'awesome list of JS frameworks' or whatever and assume everyone else looking at it is shipping some insane Frankenstein's app that uses every single one?
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.
Usually it's 3 questions per interviewer with 6 rounds that comes out to around 20 questions. I think a list of 251 to choose from is pretty fair in that regard.
The list is also not useful without knowing what to do with the reply.
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.
Yes, very good point. With every question on our DD questionnaires there is a 'reason' field, which outlines specifically why we are asking the question and what the expected responses are (though sometimes an answer can be quite surprising requiring a dynamic modification of the follow up questions).
Is not that it can be disinterest in the company role, but the candidate's radar is reading the company signals that confirm they work in a way that that candidate knows he doesn't like or want or be willing to work (he can decide later).
Not that I disagree, but if the interviewer expects the candidate to spend the better part of a week proving that they know how to code, whats so outrageous about asking for a day?
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.
Typically companies have the pick of the litter unless you are exceptionally skilled and/or already have a super good reputation the power dynamic is - unfortunately - in favor of the company and ignoring that fact is likely going to be counterproductive.
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.
I still get bombarded with recruiter emails and I'm mediocre. I probably won't work at a top company, but I won't be making less than $100k ever again.
I am not so sure about this. I am just an average developer, no superstar. Recently did a job search and got a few offers but decided to not take any of them.
I wouldn't expect a recruiter to even know many of these. Code review process? Version control? Meeting frequency? How much spaghetti code do you have? Recruiters aren't tech people and things like meetings and code review culture can vary from team to team.
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.
But those things should be important to any professional developper! Like I would absolutely 100% not work for a company that doesn't use proper version control.
There are a lot of technical questions there, yes, but plenty of non-technical ones. That being said, yeah, a recruiter isn't always going to have great pertinent insight to offer about the organization, and they might also be coached to give a particular set of replies. OTOH, the author specifies that not all the questions are going to be suitable to the initial interview, which would be the only one held with a recruiter anyway.
An interview is a two way street. An interviewer should be capable of knowing answers to most questions regarding the potential position in the organization. Of course there is a limit and asking more could come across as petty. But then again applicants try to find the best place to work for themselves. An employer demands them to spend roughly 1/3 of their day working there, so lots of questions should be answered, if asked. An applicant may come with previous experience of not so nice places to work at and might want to prevent going into another place, where it is not so nice.
I do think it's good advice to keep a largish list of questions to a more advanced stage (doesn't need to be at the point of offer necessarily, but anything before an in-person or equivalent interview shouldn't demand too much time), but after that I think it's a reasonable ask that a company put about as much effort selling themselves as the interviewee does.
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.
Anything you posted in your job listing is fair game. You post your tech stack? I'm asking about it. I also want to talk to a developer at the same level as I'll be at so I can ask them what a typical day to day is.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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 ...
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...
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.
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.
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.
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.
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.
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).
Once this changes the prospective employees will turn to other application strategies such as depicted in the famous graphic "will code html for food".
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.
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?
> 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.
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.
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.
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...
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.
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.
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.
This is a fairly limited point of view. For starters, you need to realize that the candidate is probably interviewing for more companies and having more offers. If the offers are similar enough, I might end up making a decision based on which source control you use or on whether you use libraries I don't like or not.
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.
> 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.
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.
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.
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.
Yea, if someone came in with that agenda right off the bat, I would drop them immediately. That person spends too much time on social media and if they’re going to get triggered or make a crusade over such social issues as me using traditional terms, not being on a DEI crusade myself, then they’ll be a distraction.
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.
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.
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.
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.
Yes, those questions are hilarious. As a person on the hiring end of the interview, I really don't care about anyone's sexual preferences and I don't want to care. It's like stating "I want to work only with people with black hair". It's really a bad filter to use.
Oh wait, the list actually has a question about the skin color...
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.
It's kind of inappropriate to ask someone if they're LGBTQ+ as well; they'll tell you if you want to, but you shouldn't keep statistics or records of it.
If I was a woman or LGBTQ or non-white I'd definitely want to know those specific numbers since it may materially impact my experience at the company. That said for larger companies you can just google this information.
So, you want companies to gather sexual orientation info from employees, store it in their HR database, and then do yearly analysis ("this year, we lost two gays and one lesbian, but gained two trans people and one bisexual")?
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.
They already store it. It's asked for every candidate that interviews. So why should't a candidate get the info if it helps their decision>?
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.
As an LGBT non-white non-man, they seem like perfectly reasonable questions to me. In my experience, diverse workplaces are always more welcoming (or at least less likely to be outright hostile) to someone like me.
I think it’s a useful sanity check. Let’s say you have an engineering department of, say, 5 teams. All of the leads are straight white cis men. That’s could very well be because it’s a small company yadda yadda. But it’s good to keep track of it as the company grows to 10, 15, 20 teams. If your engineering department large and you have literally no minorities or what minorities you hire quickly quit, that should be a red flag that something is going wrong with your company culture. Otherwise you’ll end up having a hit piece about how an engineering director sexually harassed women and HR covered for it (NYT about Uber, Google has had this scandal, blizzard is being investigated right now, riot games had a piece published, etc.)
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.
It's not clear. Technically LGBTQ is a protected class now, so it would make sense that EEOC would collect that data now. But some employment attorneys suggest there are better ways to collect this workplace data. https://www.shrm.org/resourcesandtools/legal-and-compliance/...
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.
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.
Asking "What will be my day to day responsibilities?" is reasonable, maybe just phrase it "what percentage of my time will I spend on X" rather than absolute.
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.”
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.