[HN Gopher] A list of developer questions to ask prospective emp...
___________________________________________________________________
A list of developer questions to ask prospective employers
Author : 0x54MUR41
Score : 346 points
Date : 2022-08-19 11:01 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| trunnell wrote:
| 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?
| bartvk wrote:
| Pretty amazing list. There's also funny questions: "tabs or
| spaces?" is in there.
|
| Now that I have a family, I always ask: "when was the last time
| you worked weekends?" There's a question in the list "What hours
| does the team work?" but I feel that doesn't quite cover
| overwork.
| muzani wrote:
| About half the people I've worked with prefer to work nights. I
| think what hours matter a lot to those people.
|
| We had one team where standups were 5PM because that's when the
| managers were about to leave work and that's when the
| programmers woke up. With remote, it gets messier.
| bartvk wrote:
| 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.
| dangerface wrote:
| If an applicant asked me these questions the answer would be no
| to all of them.
|
| Do other organisations put that many limitations and control on
| their developers?
|
| Is there any space for developers to take charge of their own
| projects and have project ownership?
| seanhunter wrote:
| 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.
| andrew_ wrote:
| 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.
| ziddoap wrote:
| 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.
| ericmcer wrote:
| Leverage, a self taught programmer with no work experience and
| a senior at a FAANG should approach this list completely
| differently.
| alkonaut wrote:
| 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.
| SetTheorist wrote:
| 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.)
| xeromal wrote:
| The repo does say
|
| 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.
| jolen33 wrote:
| lupire wrote:
| paskozdilar wrote:
| > 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.
| seanhunter wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| badpun wrote:
| Linux kernel programming is probably like this. There are no
| automatic tests, so the more pedantic you are, the less bugs
| you'll introduce.
| arwhatever wrote:
| The _fewer_ bugs you'll introduce.
|
| I don't know squat about kernel programming, though. :-)
| danielheath wrote:
| You are also likely introducing bugs which are lesser :p
| robocat wrote:
| Correcting somebody's English is often a form of status
| signalling, and can be taken offensively.
|
| Insert ironic joke here to make an open sandwich.
| dahart wrote:
| 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.
|
| The idea to use "fewer" for countable things was
| someone's personal preference. https://www.merriam-
| webster.com/words-at-play/fewer-vs-less
|
| "This rule is simple enough and looks easy enough to
| follow, but it's not accurate for all usage. The fact is
| that less is also sometimes used to refer to number among
| things that are counted.
|
| "This isn't an example of how modern English is going to
| the dogs. Less has been used this way for well over a
| thousand years--nearly as long as there's been a written
| English language."
|
| See also the list of common counter examples.
| mariodiana wrote:
| 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.
| dahart wrote:
| "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.
| jamessb wrote:
| 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.
| dahart wrote:
| 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.
| rpastuszak wrote:
| > There are no automatic tests
|
| #til and also #wtf
|
| In all seriousness, can you recommend any resources on why
| is that the case and how kernel is tested?
| bruce343434 wrote:
| I can't speak about the kernel but personally I prefer
| proofs of correctness over testing.
| zelphirkalt wrote:
| Those are very hard to achieve though for some non-
| trivial C code.
| zasdffaa wrote:
| 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.
| badpun wrote:
| 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...
| gjulianm wrote:
| There are tests:
| https://www.kernel.org/doc/html/latest/dev-tools/testing-
| ove...
|
| 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.
| q7xvh97o2pDhNrh wrote:
| 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?
| gjulianm wrote:
| > 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.
| nyanpasu64 wrote:
| 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.
| valenterry wrote:
| I don't really agree with that.
|
| 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).
| gjulianm wrote:
| 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.
| valenterry wrote:
| > 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.
| xorcist wrote:
| It's a lot more work to write a perfect bit-for-bit
| emulator for some hardware than to write a kernel driver
| for said hardware.
|
| You could absolutely run tests on emulated hardware, but
| you probably learn more about the emulator than about the
| kernel.
| lupire wrote:
| rpastuszak wrote:
| 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.
| blueflow wrote:
| 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.
| AlotOfReading wrote:
| 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.
|
| [1] https://www.usenix.org/conference/raid2019/presentati
| on/gust...
|
| [2] https://doi.org/10.48550/arXiv.2107.12867
|
| [3] https://www.usenix.org/conference/usenixsecurity20/pr
| esentat...
| gjulianm wrote:
| 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.
| bena wrote:
| 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.
| nyanpasu64 wrote:
| 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.
| winReInstall wrote:
| The tests were the friends we made along the way, and
| inside all of us all along >D
| silvestrov wrote:
| accounting is another job where mistakes can be very costly
| monetary, customer relationship or law.
|
| Until you have worked with (internationonal) accounting,
| you don't realize how complex it can be.
| [deleted]
| wsostt wrote:
| 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.
| [deleted]
| chiefalchemist wrote:
| 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.
|
| *If they give you sufficient time for questions.
| time_to_smile wrote:
| > 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.
| chiefalchemist wrote:
| It's sadly funny how often I've been asked for code samples
| and/or a code test from companies that have zero presence
| on GitHub or GitLab.
| macintux wrote:
| 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.
| chiefalchemist wrote:
| Yeah, that's a problem :)
|
| 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.
| cratermoon wrote:
| 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.
| cecilpl2 wrote:
| 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.
| sneak wrote:
| My girlfriend has been interviewing recently and she asks shops
| what their Joel score is. If they know, it's a good sign, and if
| they don't, it makes her look good dropping knowledge. The places
| she has been talking to went over their scores on the call, which
| surfaces details about the actual working conditions.
| versk wrote:
| 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.
| DoctorDabadedoo wrote:
| Although is a good starting point for things to look for, you
| might get a pass for things that shouldn't. I used to work at
| a place that every client project was spun out from a
| monolithic repo (that continued being developed) by... local
| copy, sure they were using git, but no libraries, modules,
| packages, etc. Getting a patch in was ridiculous. So YMMV.
| sneak wrote:
| 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).
| hoosieree wrote:
| Would "uses microservices" be a positive or negative on a
| Joel Test today?
| [deleted]
| versk wrote:
| It wouldn't really make sense as a question on a Joel test
| seeing as its a design style. A Joel test is more about
| ways of working.
| keyle wrote:
| Unless you have the upper hand from the moment you walk in, I'd
| advise against machine gunning these questions in the interview.
|
| Yes a lot of them are important, but you can get a lot of answers
| by the feel from the interview and the interviewers.
|
| I'd recommend to be the guy that can help. Usually interviewers
| will come forward with what they're trying to fill, what they're
| lacking... Be that guy.
|
| Most places I joined weren't all there in when it comes to all
| those questions and what they imply. When I join, I try to make
| the place better, to provide value. That means also raise their
| street value, by bringing modern techniques, modern thinking etc.
|
| Sure, knowing what environment like windows or macos could be a
| deal breaker, but you can get that answer just by walking in, see
| what the interviewers are using and what's on the desks.
|
| No jobs are perfect and like any relationship, it takes work on
| both sides. Dream jobs are pretty rare and chances are, you won't
| get offered one because someone has left it behind...
| geraldyo wrote:
| They fully address this in the post
| rednum wrote:
| Personally, I also ask more questions about on-call:
|
| - is there a SLO?
|
| - what is the schedule? 24h is no go for me.
|
| - is non-business hours on-call compensated (even when there are
| no pages)?
|
| In particular, I strongly believe we (as profession) should push
| more the employers for the last point. Being oncall during
| weekend means I need to seriously adjust my plans; need to have
| corporate devices somewhere close, etc. In particular this also
| means I don't fully disconnect from work if I have to carry
| laptop/phone with me. This kind of stress slowly accrues long
| term. All in all: staying alert for oncall is some sort of work.
| A physical security guard gets paid for keeping an eye on things
| even when nothing happens; it's startling that so many devs
| don't.
| tomerbd wrote:
| I would go further and ask for a day off after each on call
| shift
| bartvk wrote:
| That's a very good point. I always ask when they last worked in
| the weekend, but I didn't consider work expecting you being on-
| call without mentioning it.
| neogodless wrote:
| Never heard of SLO before, but I assume you mean this?
|
| https://www.bmc.com/blogs/slo-service-level-objectives/
|
| (I've also never done on-call!)
| rednum wrote:
| Kinda. In this context I mean "response SLO" - how much time
| you have between receiving the page and starting debugging
| stuff. I think it's also important to clarify; I've been on
| rotations with response SLO ranging from 5 through 30 minutes
| to unknown: literally my manager couldn't answer the question
| "so how fast do you expect me to react" (in hindsight, that
| was a pretty big red flag about how team approaches
| production that I missed).
| llbeansandrice wrote:
| 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.
| icarusfowl wrote:
| 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.
| jacquesm wrote:
| 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.
| JustSomeNobody wrote:
| 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.
| Trasmatta wrote:
| Nobody is saying you should ask all these questions. Right
| there in the description:
|
| > This is not a checklist, this is not a shopping list. If you
| send this entire list to an employer, they probably won't be
| calling you back. This list is intended to serve as a reference
| point for things to be aware of during your interview process.
| Not all of these questions will be relevant to every person or
| position, you should choose the ones that are relevant to you
| and what you are interviewing for. It's OK for there to be
| questions on this list that you personally do not care about.
| jacquesm wrote:
| Disclaimers do not change the fact that it is a laundry list.
|
| If you dropped half it would still be way over the top.
| Aeolun wrote:
| 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.
| jacquesm wrote:
| Three would be fair. Out of 251...
| OJFord wrote:
| 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.
| marcinzm wrote:
| 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.
| zelphirkalt wrote:
| 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.
| buro9 wrote:
| 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.
| sebastianconcpt wrote:
| 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).
| jacquesm wrote:
| 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).
| dsr_ wrote:
| "Why are you hiring for this role?"
|
| - 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.
| ryanbrunner wrote:
| 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.
| schwartzworld wrote:
| 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.
| cholantesh wrote:
| 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.
| Double_a_92 wrote:
| 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.
| bodge5000 wrote:
| 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.
| jacquesm wrote:
| 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.
| confidantlake wrote:
| 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.
| vsareto wrote:
| 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.
| greenail wrote:
| 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.
| wellpast wrote:
| For codebase ask LOC. Ask them to run cloc on a repo and tell you
| what that code does for the business. That will tell you so much.
| witx wrote:
| > Windows, Mac or Linux? Do I get a choice?
|
| Beware that if this is a hard-requirement for you, you might get
| "cheated" and or disappointed. They might tell you it's all fine
| that you use Linux, but then you go and see it's not linux-
| friendly at all as there's a shitload of things that keep
| breaking or you have to use a specific distro version, due to
| some required software or configurations the company requires you
| to use ...
| morelisp wrote:
| > 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.
| mouzogu wrote:
| only questions i need: is there mandatory overtime, if so how
| much, and is it paid?
|
| will tell you everything you need to know.
| mianos wrote:
| 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.
| dustinmoris wrote:
| 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.
| codingdave wrote:
| 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.
| EastSmith wrote:
| My top question right now: Can I use my own hardware & will you
| monitor me (time tracking, screenshots, etc.)?
| bayofpigs wrote:
| [deleted]
| weego wrote:
| 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.
| bartvk wrote:
| > 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.
| ethbr0 wrote:
| > _If what source control or oss libs we use are a dealbreaker_
|
| Have you ever worked at a TFS shop?
| peteri wrote:
| Depends on the version to be honest.
|
| The newer ADO with git as the source control is fine with me
| but I suspect if the company started with some of the early
| scrum templates and rolled forward it could be a complete
| horror show.
|
| I wouldn't use it for Linux kernel development, but for a
| general .net shop it's what I would expect to see. I don't
| really interact enough with Jira to have a solid opinion.
|
| I think the 2005 version source control was awful though, it
| got better and these days I'd hope everyone was using git.
| MarcellusDrum wrote:
| I currently do. It's not perfect, but honestly, I don't
| understand the hate.
| glitchc wrote:
| Wait till you have to deal with a merge conflict.
| bbarn wrote:
| Ah, VSS and SVN's bastard love child. Don't miss that.
| gjulianm wrote:
| 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.
| willcipriano wrote:
| My two most important questions don't appear to be on here.
|
| "What has employee turnover looked like?" This is the biggest
| signal to me, a lot of businesses hire and are unable to retain
| anyone after the honeymoon period wears off. If you can't keep
| employees I'm not interested. They also can't really lie about
| this since once I join the team git blame is going to give away
| that they had lots of previous employees working on the project
| who are no longer here.
|
| "What would my on call expectations be? Would you expect to reach
| me out of hours?" They cover monitoring and on call but not as
| directly as you need to. Devs may not have a explicit on call
| rotation, but many orgs have implicit on call expectations.
| Asking directly like this can make the implict explicit. I need
| to know this to set a price. "We expect you to jump in when there
| is an issue so we need to be able to reach you" is 24/7/365 on
| call in effect.
| bbarn wrote:
| > "What has employee turnover looked like?
|
| I prefer to ask "What's the average tenure on my team, and how
| does that compare to the rest of the company?"
| 0xbadcafebee wrote:
| I want to find any red flags at the company, so I'll straight up
| ask my interviewer one or two of: - What is the
| most rewarding part of your job, and what is the most
| challenging/difficult part of your job? - If you could
| change one thing about your job/the company, what would it be?
| - Would you say it's easy or difficult working with your current
| team? - Are your corporate policies clear & does everyone
| know what they are? - Are there any major impediments to
| getting your job done? - Does your team/company have well-
| organized documentation? - Is it clear how to communicate
| with other teams? - Do you think management is doing a good
| job? - How much would you recommend working here? -
| Are there any major problems here I should know about?
| Double_a_92 wrote:
| But the interviewer most likely is not doing the same job that
| you are applying for?
| 0xbadcafebee wrote:
| 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.
| karol wrote:
| All it does is it shows we are still in employee driven market,
| hence the recession hasn't hit yet.
| karol wrote:
| Once this changes the prospective employees will turn to other
| application strategies such as depicted in the famous graphic
| "will code html for food".
| respondo2134 wrote:
| 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.
| emaginniss wrote:
| For the diversity questions, are we assuming that your employer
| asks who you like to bang when you get onboarded?
| notjustanymike wrote:
| Had to check again on the diversity questions and yeah...wow.
| Almost no one has those numbers on hand, nor should they.
|
| We typically refer to it as Diversity & Inclusion, and a
| company's initiatives should include things like a diverse
| hiring policy, training on unconscious bias, how to identify
| and resolve in office bullying, anti-harassment training, and
| more. In an interview I'd want to know what the company has in
| place AND how seriously the company treats it (because some
| training is legally mandated).
|
| Boiling it down to percentages of demographics is naive.
| Chris2048 wrote:
| > should include things like .. training on unconscious bias
|
| Hell no. If you are talking about "Implicit bias" (IAT), this
| has dubious scientific support.
|
| https://www.wsj.com/articles/the-false-science-of-
| implicit-b...
| Chris2048 wrote:
| 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.
| [deleted]
| drstewart wrote:
| 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.
| sebastianconcpt wrote:
| For candidates, reading these questions are a great exercise and
| depending on where you are in your career, you need some of
| these.
|
| In practice, that list has too many unanswerable questions
| (framed in a way that can only make the company or its team or
| its manager look bad).
|
| I think this all come from our analytical and correctness bias,
| and maybe some late bound experimentation plus garbage collection
| of the details that needs adaptation are a more practical
| solution.
|
| Feeling the vibe suddenly seems important.
| [deleted]
| gbin wrote:
| So I recruit ... A lot. If a candidate just ask canned questions
| or kind of not super relevant questions like this I might spot
| that as a red flag.
|
| Also those questions are very developer centric, not company
| centric Ie. Is this environment good for me developer, which is
| ok but you need to balance it.
|
| For example:
|
| what is your current pain points in the company?
|
| How do you think I could help your company if I join?
|
| ^^ it is a huge red flag if you get BS responses on those as a
| candidate. Every single company sucks or way or another and if
| they hire it should be to improve it.
| bbarn wrote:
| I think "what are you current pain points" or "What are some of
| the struggles that you've had in the past" are very good
| questions to ask. If a manager says everything is great then
| either they are overhiring, or lying. (with the exception of
| maybe forming a new product team inside a successful company.)
| Typically though, it dives into deeper discussions about the
| product and process that can be very engaging in both
| directions in an interview.
| brador wrote:
| If you're good enough to ask these questions freely at interview
| without fear you should be applying for a more senior role.
| sebastianconcpt wrote:
| Yep.
| bsuvc wrote:
| These hardly seem like good questions:
|
| > What percentage of the company is non-male?
|
| > What percentage of the company is non-white?
|
| > What percentage of the company is LGBTQ?
|
| If those things are important to you, better to ask something
| less bigot-ey, like:
|
| "I like to work with diverse teams. Can you talk about what kind
| of diversity programs or initiatives the company has?"
|
| It's bad form to single out a specific race or gender, even if it
| is the most hated trio of white, straight, male (/s). It's not
| the virtue signal you think it is.
| notRobot wrote:
| 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.
| badcppdev wrote:
| What would be a good response to those questions? Or would
| you phrase the questions slightly differently to how it's
| worded in the list?
| naavis wrote:
| But why would an employer keep tabs on the gender identities
| or sexual orientations of their employees?
| 0xbadcafebee wrote:
| For "demographic workforce data" it's legally required:
| https://www.eeoc.gov/employers/eeo-1-data-collection
|
| Also in order to establish the level of diversity in the
| company, they need to count how many of each kind of person
| there is.
| bsuvc wrote:
| > each kind of person
|
| Everyone in their respective buckets, amirite?
| naavis wrote:
| Okay, that covers gender as far as I can tell. But how
| about sexual orientation?
| 0xbadcafebee wrote:
| 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/...
|
| Many companies ask the information optionally
| (https://www.thehrcfoundation.org/professional-
| resources/self...) in order to provide appropriate
| benefit plans, as LGBTQ individuals may have specific
| health concerns that non-LGBTQ people don't have.
| SamoyedFurFluff wrote:
| 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.
| the_doctah wrote:
| >diverse workplaces are always more welcoming (or at least
| less likely to be outright hostile) to someone like me.
|
| No, they are just more willing to hire you for reasons other
| than your actual merits as an employee.
| 8note wrote:
| That's even more the case for non-diverse workplaces, where
| skin colour is considered an important merit
| david38 wrote:
| 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.
| self_awareness wrote:
| 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...
| marcinzm wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| marcinzm wrote:
| 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.
| ajsnigrutin wrote:
| > It's asked for every candidate that interviews
|
| Seriously? This is like a huge NO-NO here... like asking
| a woman if she's planning to get pregnant and stuff like
| that.
|
| I don't have to lobby, since it's illegal here already.
| But most of our worker protection laws were written in
| socialist times.
| blueflow wrote:
| If they aren't discriminating, what do companies need to know
| the percentages for?
|
| My previously employer advertised the average age of their
| employees to me during the interview. I later realized they are
| calculating that metric because they are discriminating against
| older people. They wanted young, inexperienced flesh like me.
| respondo2134 wrote:
| 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.
| blueflow wrote:
| > i'm an old, white, straight male
|
| 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.
| terryf wrote:
| Right, I couldn't even answer "What percentage of the company
| is LGBTQ?" because why would you ask people that specifically?
| RektBoy wrote:
| Rofl, only Americans care about this..
| badpun wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| bbarn wrote:
| Furthermore, what company in it's right mind has data on sexual
| orientation? Are you asking in the annual engagement survey?
| [deleted]
| jillesvangurp wrote:
| 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.
| zasdffaa wrote:
| The one question that would decide everything for me but I can
| never ask: Are Your Managers Competent.
| jfabre wrote:
| Reading from the comments, I'm astounded that the recruiters seem
| to think interviewing for a job is a one-way street where only
| the employer should validate if the employee is a good fit for
| the employer.
|
| I'm literally investing 40+ hours a week of my life into your
| company for at least the next 2 years and you think I won't vet
| you before accepting your offer?
|
| You need a reality check.
| sys_64738 wrote:
| 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?
| Double_a_92 wrote:
| > I mean, is your entire decision going to be made on GIT being
| used?
|
| Absolutely. If a company doesn't use any modern versioning
| system that's probably one of the biggest red flags there are.
| bdg wrote:
| Strong agree. It reminds me a bit of the format of interview
| that unskilled or inexperienced hiring managers come up with:
| - "How big was your team at your last company?" - "What
| languages do you use at your last company?" - "Do you
| prefer to use for..in loops or [].for() notation?"
|
| And using the surface answer as the way to make a decision.
| Being able to navigate a topic from broad-to-specific is a
| specific skill that is rarely taught and are very lucky if they
| manage to stumble on to it after enough experience and self-
| reflection.
| Aeolun wrote:
| > I mean, is your entire decision going to be made on GIT being
| used?
|
| The absence of Git is certainly a critical negative factor. I
| wouldn't work in a company without source control, and these
| days Git and source control are more or less the same (I guess
| it's possible they use Mercurial).
| p_j_w wrote:
| SVN is also still in use.
| cerved wrote:
| yuck
| ryanbrunner wrote:
| 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.
| adrianmsmith wrote:
| > 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.
| whoomp12342 wrote:
| awesome
| what-imright wrote:
| 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."
| jblow wrote:
| [Context: I run a video game development studio.]
|
| Whenever I interview people I explicitly make a section of the
| interview where I answer the candidate's questions, just in case
| it doesn't come up naturally or the candidate is a bit meek in
| that department. I think this is an important part of the
| interview. But if a candidate asked a bunch of these questions,
| it certainly would harm my opinion of them. I do not recommend
| using these questions as a guide.
|
| Why not? For one, a lot of them are petty and kind of annoying,
| so you will come across as petty and kind of annoying. (Oh my
| God, if someone asks "tabs or spaces?" that is a no-hire right
| there.)
|
| But also, note that many of these are leading questions for which
| there is supposedly a definite right or wrong answer ("Do you
| regularly correct technical debt? Do you use MVC or similar code
| structuring?" [This second question indicates a serious no-
| hire.]) Either these questions are appropriate, which implies you
| know more than the company does about how to develop software, or
| are at least its peer, in which case why are you interviewing
| there in a non-executive role, or why are you not off starting
| your own thing; or they are inappropriate, in which case you are
| signaling that you are going to be second-guessing everything the
| company does all the time, in a Dunning-Kruger kind of way, which
| is not something that anyone wants to deal with.
|
| Either way, the attitude here is that the applicant can stand in
| judgement over the company, comprehensively across all these
| categories involved in programming, from the outside, with no
| real knowledge of what happens there day-to-day. This implies
| that the company cannot have much to teach the applicant or offer
| in terms of knowledge and technique, because if it could, then
| the answers to many of these questions would be surprising to the
| applicant or would even come across as "incorrect". So you're
| signaling that you think you know as much or more than the
| company about how to develop software well -- but news flash,
| most projects developed even with positive answers to all these
| questions are trash fires anyway. But some projects are very
| successful, so clearly there are factors much more important than
| are covered by these questions. If you treat these questions as
| important, you are signaling that you don't really know there are
| more important questions (while also being annoying).
|
| Lastly, note that a lot of these questions are about minimizing
| the impact of the job on your life, "work-life balance" kinds of
| stuff. And there's a paradox here. On the one hand, I am not a
| fan of crunch or any kind of overworking people, and I do think
| it's reasonable for many people to avoid jobs that put you into
| that kind of situation. On the other hand, doing good work, for
| many people, is a primary vector for finding meaning in life; if
| you are not interested in investing time, energy and effort into
| a job, it probably is not meaningful to you, so these questions
| are kind of a checklist for finding a hollow meaningless job,
| actually. And if you ask a bunch of these kinds of questions from
| an employer, even one that is very careful about providing "work-
| life balance" (btw a phrase I never liked, I think it's a deep
| misconception, but at least we know what we are talking about),
| the employer is going to notice you keep asking this stuff and is
| going to get the feeling that you are someone who doesn't want to
| work very hard, unless you actively signal something like, I
| intend to work very hard within company hours but clock out
| exactly at 5pm, or whatever. But if you don't carefully do this
| kind of balanced signaling, and instead just ask a bunch of the
| questions from this list, you'll be giving the impression that
| you are someone most people don't want to hire, because why are
| you so preoccupied with minimizing work? It's a job, you are
| supposed to want to work there.
|
| Questions I would recommend in lieu of those on this list:
|
| * Why is the work important? What do I get from this job besides
| money (in terms of skills or other experience)?
|
| * How is the company deciding what is "good" or "bad" in terms of
| the software or the development process? Aesthetically, what is
| considered good, what is considered bad?
|
| * What kinds of decisions do I have the authority to make, and
| what kinds of decisions am I expected to defer upward?
|
| * How closely will I be managed? What size of problem am I
| expected to solve independently, and what size of problem should
| be deferred upward?
|
| * How far can I rise in my field by doing this job?
|
| * How much of my time do I spend programming, and how much in
| meetings?
|
| Note that none of these are questions with a pre-known right
| answer (except maybe a little bit the meetings one). They are
| also reasonable questions that should help maintain a good
| impression.
| lakomen wrote:
| 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.
| bdg wrote:
| 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.
| p0nce wrote:
| > it is incredibly hard to tell what a company is like until
| you start working there
|
| Sometimes the dumpster fire is visible right from the
| interview.
| Aeolun wrote:
| Maybe we can take this list, and make something like Glassdoor
| where companies, or departments within companies can answer the
| whole list in one go, then point all the candidates there?
| sebastianconcpt wrote:
| The problem with that is that a self-referencing description
| will be mostly propaganda. It might be a startup based on BS
| and if manages to get attention, play the virtue-signalling
| game big time.
| insomniacity wrote:
| Stack Overflow Jobs used to do this at a very shallow level.
| llbeansandrice wrote:
| 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.
| denimnerd42 wrote:
| 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.
| llbeansandrice wrote:
| 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.
| fortpoint wrote:
| +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.
| douglaswlance wrote:
| There's a problem with GitHub lists that accept PRs. They
| accumulate over time. Almost nothing is removed. No one wants to
| remove someone else's contribution.
|
| This list needs heavy editing, and some form of feedback
| mechanism by which those questions that perform best are weighted
| higher.
| sh4rks wrote:
| Also, the questions lack context. For example, what answer am I
| expecting when I ask whether the company is currently
| profitable?
| ChrisMarshallNY wrote:
| I find that this list[0] is _extremely_ geared towards a fairly
| specific style /culture/stack kind of thing.
|
| _Lots_ of companies will "fail" this list, and it could be a
| real missed opportunity.
|
| _SOURCE: I ran an organization that "failed" a good many of
| these, yet retained top-shelf C++ talent for decades._
|
| [0] https://github.com/Twipped/InterviewThis#developer-
| coordinat...
| gjulianm wrote:
| It's not about "failing" or "passing" the question, it's about
| understanding the company. For example, the "agile" question...
| You might answer "yes, we do agile" and that might be a good
| thing for some developers and bad for others (and even that
| might depend on the position).
| ChrisMarshallNY wrote:
| If the question was standalone, I'd agree. However, in the
| context of all the other questions, I'm not so sure.
| gjulianm wrote:
| Well, the list says at the beginning that the point is to
| choose the questions that matter to you. On time alone, you
| probably can only ask 3-4 per interview. I've asked similar
| questions on interviews and the truth is that they reveal a
| lot of information about the company. For example, asking
| about work on week-ends, I don't only want the answer but
| the way they answer is interesting: "we work some week-
| ends, lately quite a bit due to X, but rest assured all
| those hours are counted as overtime and compensated
| accordingly" is far different than "if we need to work
| week-ends we work week-ends", one tells me they know
| they're stretched thin but they don't want that to remain
| permanent, the other tells me I'm going to get fired soon
| for refusing to work a week-end on short notice.
| ChrisMarshallNY wrote:
| Fair point.
| greenail wrote:
| 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.
| seb1204 wrote:
| I'm surprised to see little about how products are
| managed/defined. PO/PM.
| 0xbadcafebee wrote:
| Hey, Everybody complaining about reading this whole list to your
| interviewer: _please read the 2nd and 3rd paragraphs._
| iamricks wrote:
| I used this list recently: https://github.com/viraptor/reverse-
| interview
| photochemsyn wrote:
| 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.
| skrebbel wrote:
| 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.
| choeger wrote:
| > There's this whole scene of people who do performative,
| almost theatrical, quality programming but nigh on forgot how
| to actually ship features, and questions like those are a hint
| they might be in that camp.
|
| Sorry, but I think you're probably wrong as well. Do you
| actually _sell_ features? As in: Is your revenue directly tied
| to the number of shipped features per year? If so, who pays for
| the perpetual maintenance? Did it ever occur to you that every
| feature is a liability? Security issues, bugs,
| incompatibilities and odd side-effects with other features,
| legal changes all add cost _per feature_.
|
| If you're (like many in the industry) piling features on top of
| each other because you currently have no idea what your
| finished product should look like and you're hoping that your
| feature pile will someday somehow turn into a profitable
| product, I think you're wrong. And even if it does, you'd
| better exit shortly after because mid-term maintenance will be
| a proper nightmare.
| skrebbel wrote:
| You're making a whole lot of assumptions there buddy.
| unoti wrote:
| > 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.
| jfabre wrote:
| 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.
| switch007 wrote:
| Ah the cliche "I'm a hiring manager and I wouldn't hire this
| person" comment.
|
| I think you've not considered the reason behind the question
| and jumped to conclusions.
|
| Eg if the say subversion and it's a massively distributed team,
| the developer is not going to have a fun time. It isn't a first
| class citizen when it comes to third party tools either. These
| are real issues.
| gregors wrote:
| While that's true, there are work arounds. Github does
| support Subversion. Having found myself on a team (in the
| past) that was tied to an outdated version control solution
| (source safe), you can still use Git locally to facilitate
| branches, rebasing and most everything else. Thankfully
| that's a rare occurrence these days.
|
| https://docs.github.com/en/get-started/importing-your-
| projec...
| Trasmatta wrote:
| That's an odd one to cherry pick. There's nothing performative
| about source control. It's one of the most important tools for
| actually shipping software.
| woutr_be wrote:
| I was going to say; I would ask this, as a lead up to CI/CD,
| and how they feel about developers shipping features
| continuously, or if there's any process to actually ship what
| I've build.
| technion wrote:
| I can see the concern though. If you say something like "we
| invested in a large workflow involving Gitlab/Gerrit/anything
| else" and a potential applicant without any context expects
| you to go on the defense about why you aren't just using
| Github, I can see that person being hard to work with. I'm
| particularly noting the "and why" part here.
| ryanbrunner wrote:
| The problem isn't the question there though, the problem is
| an invented scenario that happens due to the response. The
| followup to that response could easily also be "Oh cool,
| how does that workflow work? Why did you go in that
| direction? What do you want to improve about it?"
| skrebbel wrote:
| The performative part is engaging in endless discussions and
| iterations about internal tooling
| chrisseaton wrote:
| > 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.
| Anon1096 wrote:
| 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.
| ryathal wrote:
| 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.
| skrebbel wrote:
| 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.
| yCombLinks wrote:
| 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.
| throw827474737 wrote:
| This question can be fine addressesd and be done with in 10
| seconds.
|
| If you cannot answer this positively quickly I'd doubt your
| ability to ship a product (long-term).
|
| Especially the remark about " obsessing on code/process quality
| can be useful" .. erm, asking about source control is not
| obsessing about code/process, it is the bare minimum and more
| to me like e.g. ask my future truck employer if their trucks
| have seatbelts.. tbh if I'd hear that from the guy that runs a
| small startup I'd run .. and that's good, people are different.
| sumtechguy wrote:
| "we sometimes check things into sourcesafe but usually keep
| it on jims computer"
|
| That was 3-4 years ago. From a company that was in no way a
| 'startup'.
|
| That tells me they have no release system _at_ _all_ other
| than the late 80s crowd around a 'blessed' computer and hope
| it builds right.
|
| "have you considered git, svn, perforce anything like that?"
| "we don't have time for that"
|
| That tells me they do not have time to invest in having a
| good reliable thing for themselves. It tells me that as a
| developer I will not have any time to fix recurring issues.
| It is a question you can learn a lot from. Because it is
| something the developers do day to day.
|
| These are not new concepts. These are table stakes at this
| point. We were doing this sort of thing in the mid 90s. If
| you are not doing them. You are missing out on some cool
| debugging/regression/qa tools.
| jon-wood wrote:
| 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.
| calvinmorrison wrote:
| That is until you start a new job where they use subversion but
| people really just copy code around and once in a while a new
| version gets tagged.
| wrycoder wrote:
| It's an easy question that could elicit an interesting
| response.
|
| For example, they could be using an internal CVS repo. Or, they
| could be using GitHub.
| muzani wrote:
| 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.
| rthomas6 wrote:
| That would drive me crazy. I would've left this picture in
| the breakroom.
|
| https://ashtonmedia.com.au/wp-
| content/uploads/2015/11/Busy-c...
| arwhatever wrote:
| The team you describe exudes some hardcore woodcutter vibes.
| kleiba wrote:
| "For the first 10 years of kernel maintenance, we literally
| used tarballs and patches, which is a much superior source
| control management system than CVS is."
|
| Linus Torvalds
| jefftk wrote:
| This is mostly about how bad CVS is, and how poorly it
| works for distributed development.
| dahart wrote:
| 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.
| wrycoder wrote:
| 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.
| yccs27 wrote:
| 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".
| muzani wrote:
| 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.
| sidlls wrote:
| Linus isn't right about everything.
| dsr_ wrote:
| Then he wrote git.
| switchbak wrote:
| If you haven't used CVS, his comment would sound crazy.
|
| They did use BitKeeper as well for a time, it's just that
| CSV/SVN weren't up to the task, so they did the best they
| could at the time.
| sidlls wrote:
| I used CVS. And worse.
| mejutoco wrote:
| 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.
| rmnclmnt wrote:
| WhatsApp for versioning, first time I hear, that's a new one!
|
| (After all why not, there is even e2ee built-in!)
| wildpeaks wrote:
| 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).
| OJFord wrote:
| I can understand 'and why' being tedious, and I've never had
| _any_ questions come to mind to ask really, but it has occurred
| to me before that if I joined and then found out they didn 't
| use git... I'm all for 'actually shipping product' but there's
| enough employers out there that such a fundamental unlikely to
| change tool is a reasonable deal-breaker.
|
| The other thing I thought that about was Windows - using macOS
| would frustrate me daily but I'd (and have) get by, but Windows
| I would definitely regret not having checked what I'd be
| using/whether it was my choice before joining.
| ryanbrunner wrote:
| For a lot of candidates, "we don't really view source control
| as something we need to innovate on and prefer to ship
| features" is the right answer, and if that's your answer and
| the person is combative about it, well, that sounds like you
| just got a pretty clear signal about hiring that person,
| which is the whole point of interviewing anyway.
| OJFord wrote:
| 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.
| PheonixPharts wrote:
| > to add some context, i run a small startup
|
| And you don't understand why developers might be interested in
| your source control setup and thinking behind dev processes?
|
| If your response to a really common and sensible process
| question is
|
| > I'm going to begin doubting that this person can focus on
| actually shipping product.
|
| Then, if I'm interviewing with you, my assumption is going to
| be that your company way over prioritizes "just ship it!" with
| a total disregard for technical debt, and has a generally poor
| engineering culture.
|
| Any engineer of any real talent is going to recognize that your
| dev environment and general software developement practice is
| in fact a big part of "shipping features" in the long term. The
| fact that you view this as some practice of "bureaucratic
| bigcorps" would tell me all I need to know to walk away slowly
| and politely.
|
| So I would say this comment is inadvertently validating that
| this is in fact a very good question to ask during an
| interview.
| dahart wrote:
| 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.
| flerchin wrote:
| 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.
| [deleted]
| grayclhn wrote:
| 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.)
| dahart wrote:
| 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.
| skrebbel wrote:
| I actually agree with you, though i think you missed the
| "series of questions like" and the "and why" part. My beef is
| with applicants who think engineering is entirely about
| process and quality and who forget about business value.
| Obviously you've been in touch with a lot of businesses where
| the balance is too far in the other direction which is its
| own kind of hellscape.
|
| I recognize now that my comment makes us seem like such a
| place but actually we're very much not, I simply had not
| realized (until reading the replies here) that there were so
| many companies where even basic stuff like "using something
| like git" is considered overly fancy.
|
| I do still believe that it's a common pitfall for good
| engineers to obsess too much about tooling and process and
| too little about customers and end users.
| politician wrote:
| 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.
| PheonixPharts wrote:
| > 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.
| feoren wrote:
| > "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.
| [deleted]
| [deleted]
| raverbashing wrote:
| Oh no that's a very useful answer
|
| It tell you how up with the times (or not) their company is
|
| ClearCase has been a very good indicator the place is a
| dumpster fire
| bart_spoon wrote:
| It's not a bad question. There are still enough companies not
| using source control that the question is necessary.
| jraph wrote:
| 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.
| onion2k wrote:
| _I 'm obviously cherry picking, but if an applicant asks me a
| series of questions akin to "what source control tool do you
| use and why" I'm going to begin doubting that this person can
| focus on actually shipping product._
|
| Asking a question like that in an interview is less about the
| answer and more about the ability to answer.
|
| Any reasonably competent dev doing the interviewing will be
| able to rattle off an answer and a valid reason in a few
| seconds. It's really obvious. It requires no thought. There's
| no subtle complexity to be explained. If the interviewer can't
| answer, or they waffle on about complex stuff, then you can
| know that the company doesn't have the devs who are hands on
| with the code in the interview process which is a _really_ big
| red flag.
| skrebbel wrote:
| Nice one
|
| Can drop the "and why" for that though.
| llbeansandrice wrote:
| 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.
| sebastianconcpt wrote:
| 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?
| arethuza wrote:
| A few years back I worked for a large company that had, for
| various reasons, dependencies on software products produced by
| a lot of different suppliers. We wanted to do a "sanity check"
| on how good these companies were so we could identify where the
| risks were.
|
| So I came up with a list of pretty basic questions - including
| what tools they used for source control.
|
| During this process I encountered people who had somewhat
| eccentric views about source code control - including arguing
| pretty passionately _against_ using it. I was somewhat taken
| aback by this....
|
| So I think asking about how companies do source code control is
| pretty reasonable - 95% of the time they are probably sensible,
| but they might uncover somewhere where they have unusual views
| about how to do things.
|
| Edit: I've encountered some people with _really_ odd views
| about software development, such as one chap who believed that
| testing caused bugs...
| jacquesm wrote:
| 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.
| wildpeaks wrote:
| 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.
|
| Accessibility is good for business.
| politician wrote:
| Were you able to inquire about their approach to backups in
| general?
| jacquesm wrote:
| Tapes.
| politician wrote:
| 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.
| plugin-baby wrote:
| Where was the code?
| jacquesm wrote:
| Embedded device. Or do you mean storage? Tar files...
| going to back a decade+.
| xorcist wrote:
| Well, that _is_ version control, isn 't it?
|
| Add some basic tooling about that collection of tar balls
| and you're half way on re-implementing git.
| OJFord wrote:
| I think GP meant the source, like where/how was it
| stored?
| jacquesm wrote:
| Already added that in edit.
| OJFord wrote:
| Yeah just saw that, it was just 'embedded device' when I
| replied.
| jacquesm wrote:
| You must have hit that comment seconds after it was first
| posted because that edit was done right after I first
| wrote it. Sharp timing :)
| arethuza wrote:
| Or in the case of one of the people I spoke to zip files,
| lots and lots of zip files.
| calvinmorrison wrote:
| 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?
| dahart wrote:
| 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?
| jacquesm wrote:
| 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.
| calvinmorrison wrote:
| 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.
| drdec wrote:
| RCS was available in 1982 and SCCS was available in 1972.
| wrycoder wrote:
| 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]
|
| [0]
| https://en.wikipedia.org/wiki/Concurrent_Versions_System
| [1] https://en.wikipedia.org/wiki/Revision_Control_System
| [2]
| https://en.wikipedia.org/wiki/Source_Code_Control_System
| [3] https://www.openbsd.org/anoncvs.html
| jacquesm wrote:
| 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.
| efficax wrote:
| 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.
| alistairSH wrote:
| 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?
| ozim wrote:
| If they depend on people being disciplined and not making
| mistakes - I would not like to join such a company as a
| newbie.
|
| They have to have tough time hiring anyone or retaining
| newbies, even if it is about experienced people.
| YetAnotherNick wrote:
| 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.
| jghn wrote:
| Every time my team is hiring I am always amazed at how many
| developers have no, or almost no, git experience.
|
| People on HN assume some of these things as givens but it's
| not the case.
| lakomen wrote:
| I have almost no git experience.
|
| I know how to add, commit and push, but that's it. For
| anything else I have to use a search engine or tool like
| git-cola.
|
| I liked hg/mercurial better, but no one uses that.
|
| And all the little error messages of git, change a file
| BOOYA you can't pull anymore and have to jump through
| hoops. I don't like git.
| chrisseaton wrote:
| The part of Oracle I was in were using Git on BitBucket when
| I was there years ago. They were on GitHub for a time but
| decided they didn't like the PR functionality.
| XorNot wrote:
| Did they say why? I'm struggling to think of any
| difference?
| chrisseaton wrote:
| Maybe it was some Atlassian plug-in to the PR system?
| YetAnotherNick wrote:
| Is it consistent for all teams?
| chrisseaton wrote:
| I think different teams do what works for them - Oracle
| is pretty heterogeneous.
| cerved wrote:
| version control is key to my productivity. If you don't do that
| well or don't understand it, we're not a good fit
| michaelt wrote:
| _> There 's this whole scene of people who do performative,
| almost theatrical, quality programming but nigh on forgot how
| to actually ship features_
|
| Did you consider that a candidate who asks about "pair
| programming" or "SOC2 compliance" or "SLAs" might be asking
| that so she can _avoid_ such jobs?
|
| Of course, the list is far too long.
| guhidalg wrote:
| As a junior, I wouldn't have understood this comment.
|
| 6 years later, I value my time and mental health more than
| compliance.
| stonemetal12 wrote:
| Having worked at places with no source control and visual
| source safe, I would ask what they use, but not why. Where the
| latest zip of the project is and if some random zip has a
| certain bug fix shouldn't be a regular question.
|
| I would also ask about a artifact repository like Artifactory,
| because not having to worry about downloading random
| dependencies from the internet is nice. Having all your build
| artifacts in some centralized place is nice. Certainly not a
| deal breaker if it isn't there, just a nice to have.
| ChiperSoft wrote:
| Author of the list here, the list is 9 years old. That question
| was a lot more relevant in 2011.
| to11mtm wrote:
| > 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.
| whoomp12342 wrote:
| uhh if you use visual source safe, I am out.
|
| I will tolerate git and SVN and thats about it.
| andrew_ wrote:
| this comes across poor. it makes you sound more like The
| drummer on a Roman galleon, than someone leading other
| developers towards a goal. if a perspective developer adds
| value to your company and your product, but happens to care
| about things like source control, there may be really good
| reason why. if you dismiss that because of "we need to ship"
| then I'd propose that you might have tunnel vision and lack the
| EQ to value perspectives other than your own.
| skrebbel wrote:
| It's not the best comment i ever wrote, but I never said I'd
| dismiss devs caring about source control. I said that a
| series of questions like that suggest that the dev might care
| too much about stuff like that to the detriment of other
| stuff.
|
| If you keep shipping and growing but don't make your internal
| tooling and processes better, you're going to grind to a
| halt. If you only make your internal tooling an processes
| better but not shipping, you're also going to grind to a
| halt. My argument is that you need a lot of the first and a
| bit of the, latter. An applicant who nearly only asks
| detailed technical questions about internal stuff, and makes
| me defend our decisions when we're not ticking off all the
| hypes du jour, suggests to me that we're not on the same page
| wrt where that balance should lie. Yes, we iterate on that
| stuff. No, not fulltime.
|
| PS. I feel the jab about my EQ was unnecessary.
| andrew_ wrote:
| In fairness it wasn't a jab, but an objective observation.
| There were no personal attacks, merely suggestions based on
| observation. If we can suggest that an attentive list
| (where we've yet to define if a fictional candidate would
| expect all items to be addressed) means inherent
| expectations, it's reasonable to make the same kind of
| suggestions on your take.
|
| Appreciate your clarifications none the less.
| unoti wrote:
| 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.
| JustSomeNobody wrote:
| 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?
| NullPrefix wrote:
| 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.
| ChiperSoft wrote:
| Heya, I'm TwippedTech, the author of this repo.
|
| Every few years somebody spots this and it goes viral on HN
| again, and I hear all the same complaints that people made the
| last few times around. I don't know how many disclaimers I have
| to put on the text to get people to stop whining about the
| wording of something, or the size of the list, or the implication
| they would draw from someone asking one of the questions. There's
| always dozens of "hiring managers" who swear they wouldn't hire
| anyone who asked things from this list (good, I wouldn't want to
| work for you anyway).
|
| Every question on this list came from somebody's pain point,
| something that made their job uncomfortable. When a whole bunch
| of discomforts add up, it leads to an environment you can't stand
| working in. Nobody is going to reject a job over tabs vs spaces,
| but it CAN serve as a reminder to ask questions about their code
| linting and style requirements, and wow can there be surprises in
| there. You'd be surprised how quickly you can get annoyed when a
| company's style requirements clash with your natural habits,
| especially if there are other things making you dislike the job.
|
| And please, I am begging people, notice that this repo is almost
| a decade old. I'd bet a whole lot of people reading HN today
| weren't even coding when I made the first draft of this list.
| There are questions in here that probably aren't relevant in
| today's startup culture, and those questions will seem very
| dated, but there's also still a lot of very old companies doing
| things in very old ways, and these questions can be important to
| have in mind when interviewing with them.
|
| Just because _you 've_ never worked in anything but git doesn't
| mean that there aren't still tons of companies out there that
| never switched off of Subversion, or worse.
___________________________________________________________________
(page generated 2022-08-19 23:02 UTC)