[HN Gopher] Questions to ask a prospective employer during a job...
___________________________________________________________________
Questions to ask a prospective employer during a job interview
Author : ingve
Score : 91 points
Date : 2022-09-04 16:45 UTC (6 hours ago)
(HTM) web link (nibblestew.blogspot.com)
(TXT) w3m dump (nibblestew.blogspot.com)
| hx2a wrote:
| I always ask a direct question about ethics. Something like,
| "tell me about the kinds of ethical problems that this team is
| faced with and how you handle them." Good answers involve
| speaking up about the problem right away & not try to hide
| anything and being transparent with relevant entities. Bad
| answers are things like "there haven't been any ethical
| problems," because that most likely signals that ethical problems
| are being ignored or overlooked.
| sfg wrote:
| What kinds of ethical problems do teams suffer in your
| experience?
| nickdothutton wrote:
| 1. What happens in a day/week in the life of this job? Generally
| interviewers cant think fast enough to lie convincingly in answer
| to this question, by giving you a rose-tinted fantasy. Here is
| where you hear that the _real_ duties dont match the job
| description they are handing out. 2. What did the last guy die
| of? Similarly, throws interviewers (assuming this is not a newly
| created role). They will find it hard to deflect or lie
| convincingly under pressure. It doesn't matter what they say (to
| some extent) what matters is how they handle the question. Keep
| it breezy, smile, don't be afraid of silence while they sweat.
| throwyawayyyy wrote:
| Sorry for being a bit snarky here, but I did chortle when "You
| might also note that Google does give all their developers root
| access to their own dev machines" (which is true) is followed by
| things like "Anything under 10 minutes is good" for running the
| CI pipeline (not true anywhere I've been at Google) or "The steps
| should be 'do a git clone...'" (also not true at Google).
|
| Being slightly less snarky, this is a very prescriptive list that
| includes questions which, were I asked them as an interviewer,
| I'd consider red flags. "Does this team or any of the related
| teams have a person who actively rejects proposals to improve the
| code base?" is a BAD question to ask in an interview. What answer
| could an interviewer give? Yes? No? It depends? An example: a
| junior engineer comes in, says we should rewrite the server in
| kotlin, starts working on it, then is shot down by a senior
| engineer. Is the senior engineer "actively rejecting a proposal
| to improve the code base"? Arguably, yes. Are they wrong to do
| so? Again, arguable. It depends. Code health is a means to an
| end, not the end itself...
| shultays wrote:
| I think it is better to have a person that says no to such
| large refactors, compared to a place where devs go wild with
| such "improvements". Most devs are not great at timeboxing
| themselves or at seeing full impact of their refactorings
| rzzzt wrote:
| Maybe there should be a person on each team who actively
| rejects proposals (can also be multiple people on rotation).
| The nemesis!
| BlargMcLarg wrote:
| To me, the fact such a question is seen as 'bad' feels very
| strange, when interviewers routinely ask questions of similar
| intent (read: questions which can be very open-ended, require
| the opposite party to be vulnerable and can be interpreted in
| many ways). If you as an interviewer would consider it a bad
| question, I would hope you hold the same standard for the
| questions you ask yourself.
| filoleg wrote:
| Just because "interviewers routinely ask questions of similar
| intent" doesn't mean that it is acceptable or should be
| treated as the norm. It all heavily depends on how your
| company designs their interview process and guidelines for
| it.
|
| At every company I've worked so far where I was involved in
| interviewing, leading and ill-intended questions like that
| were explicitly prohibited, and that was stressed plenty of
| times during the interview training. There might have been
| other things about the process as a whole that I thought
| could and should be definitely improved, but the
| "disingenuous questions from the interviewers" was never one
| of them.
|
| But on the flip side, I've interviewed at plenty of companies
| (as a candidate) over the years, and I definitely was asked
| those types of questions at more than one place.
|
| So you are correct, it is common, and it sucks to be on the
| receiving end of it. But doing that exact same thing back to
| them as a candidate isn't going to solve your problem. The
| solution is to not work for companies that are ok with their
| interviewers asking those types of questions (as much as you
| can afford to do so).
|
| Think about it for a minute, what are you trying to achieve
| by asking back those leading and ill-intended questions? If
| you somehow still want to work for the company, then asking
| those questions back probably isn't the smartest idea. And if
| you don't want to work for them after they asked you those
| questions, then why waste energy on arguing back and trying
| to make some point.
|
| A no is a no, your outcome of not working for them would be
| just the same, so why do the extra work[0]. It isn't like
| they are going to take that feedback earnestly and change
| anything for you. If you truly want to make something out of
| it, it would be much better to instead warn other candidates
| (aka your friends who might think of applying, if someone on
| HN asks about interviewing at the company, etc.) about it.
|
| 0. note: venting out your frustration is a valid enough of a
| reason.
| majormajor wrote:
| I haven't personally been in any interviews where I was asked
| something so opinionated, like being asked "do you write bad
| code?" straight-up. These questions are very leading and
| direct, not open-ended at all - look at how limited the set
| of "right answers" is for most of them.
|
| A question like:
|
| > "Does this team or any of the related teams have a person
| who actively rejects proposals to improve the code base?"
|
| is a flag because it implies that the person asking the
| question thinks _their_ definition of "improve the code
| base" is the only one that matters. It also is asked in a way
| that suggests a lack of maturity around disagreement and
| communication.
|
| "If someone sees something they think would improve the code
| base, what should they do to try to get that done?" would be
| a _much_ improved version.
|
| > "Suppose the team needs to start a new web service like a
| private Gitlab, add new type of CI to the testing pipeline or
| something similar. Could you explain the exact steps needed
| to get it fully operational? Please list all people who need
| to do work to make this happen (including just giving
| authorization), and time estimates for each individual step."
|
| This one is less of a "bad question" _if you 're OK with
| filtering out places that don't work that way_ (a place that
| spins up random new infrastructure shit in a couple days
| super frequently seems like a terrible each-service-is-a-
| special-snowflake hard-to-maintain/hard-to-debug/hard-to-
| improve sort of hell, IMO) but if you're just more interested
| in process and bureaucracy, I'd suggest something more like
| "what are your thoughts on standardized shared infrastructure
| and tooling vs specialized things per-project?"
|
| EDIT: actually, to borrow a page from some frequent advice
| for _interviewers_ - for bonus points you can rewrite both of
| those "better" versions to ask for specifics, along the
| lines of "can you tell me about a time someone on the team
| proposed a code improvement change that was controversial."
| Only ask for the vaguer "philosophical approach" part if they
| can't give you a specific story.
| BlargMcLarg wrote:
| I don't agree with the question, but take away the reason
| the author is asking them, and the question is far more
| open-ended to the one being asked. That's the problem: it's
| a direct question which has too many possible answers which
| helps neither the party answering (because what should they
| answer?) nor the party asking (because even the answers not
| 100% on the mark can be interpreted in many ways). Plus,
| it's a horrible premise to set the other party up for
| failure to begin with.
|
| When you view it from that angle, the majority of questions
| in interviews are pretty similar. You can't tell whether
| the opposing party is expecting a perfect answer, or is
| lenient enough to take a chance with anything which isn't
| perfect.
|
| The problem with your changes, however, is that you take
| away the very thing that the author puts in for a reason.
| Removing the _directness_ means the opposing party is now
| given more of a chance to provide a complete nothingburger
| of an answer which is likely half-true, and half- "what the
| world is this place actually?" That's not necessarily an
| improvement when you take into account all other aspects of
| interviewing. The only definite benefit you gain, is not
| causing bad blood by appearing combative over
| collaborative.
|
| Ultimately, what people want is transparency. That
| transparency is very hard to tell from the side of
| candidates. Formulating questions to allow 'best case
| answers' doesn't work as it allows the company to oversell
| itself. Formulating questions directly doesn't work because
| the interviewer gets a bad taste in their mouth. But the
| silly thing is, lots (the majority?) of interviewers
| certainly have their fair share of horrible practices which
| continue to exist today. The only reason they exist, is due
| to their power in the market.
| majormajor wrote:
| Where I disagree with you there is about the utility of
| directness vs concreteness.
|
| "Does this team or any of the related teams have a person
| who actively rejects proposals to improve the code base?"
|
| This leaves an unscrupulous interviewer a too-obvious
| answer: "no." They aren't going to want to admit someone
| "actively reject improvements" and lying in interviews is
| not uncommon.
|
| Asking for a specific story raises the skill bar for an
| effective lie. If someone is smooth enough to come up
| with a convincing, compelling story on the fly you sadly
| will struggle to catch them out with any questions.
|
| Fall back to a more open-ended discussion if they don't.
| This is less good, but a longer discussion, similarly,
| should make it easier to spot a liar than in a single-
| word "no." _Every word the interviewer says is
| opportunity to gain more insight on what it would be like
| to work with them._
|
| Even that fallback is information you gain, though. "Can
| you tell me about a time someone on the team proposed a
| code improvement change that was controversial?" If the
| answer is "I can't think of anything immediately, but I'd
| probably do something like...[whatever]" then that's
| curious - it could suggest a few things. Maybe the
| systems are so simple that nobody thinks its worth
| bothering with changing. That could be bad for a
| candidate looking for a challenge. Maybe nobody on the
| team is empowered to make suggestions and all design is
| coming top-down from the boss. That would also be bad.
| (And the original yes/no question misses this case too:
| nobody on the team might do that, because only the boss
| is making the calls, and nobody else has made those
| suggestions, but gives you less answer to follow up on.)
|
| You can try to dig in more with additional questions,
| depending on which of those (or other) impressions you
| get from their answers.
| BlargMcLarg wrote:
| You're only tackling what you gain from your changes, not
| what you lose.
|
| Digging in requires people to spend more time. Most
| interviews are already massive and exhausting. Candidates
| in general aren't looking for longer interviews, they are
| looking for shorter interviews. Your changes propose even
| longer interviews when the number one complaint is the
| sheer length and volume of interviews.
|
| Most candidates are not amazing at interviewing or
| figuring out people, let alone when they spend most of
| their time doing other things at the day/week of
| interviewing. The majority of candidates are either
| tired, inexperienced, or both. Increasing the volume of
| information isn't a strict gain under conditions which
| are true far too often, and can even be a loss.
|
| Lying isn't uncommon, but I'd think twice about whether
| saying "no" is really that much easier than weaving an
| elaborate half-truth. At the same time, most candidates
| will be treading a fine line between not getting on the
| interviewer's nerves, and figuring out what is actually
| happening. Navigating social dynamics is difficult for a
| reason.
|
| >it could suggest a few things
|
| That's the entire problem. I reckon this is part of the
| reason why author is so direct in their questions. They
| don't want to deal with multiple possible answers and
| spending more time figuring out the answer. They want a
| 'is this company worth my time' checklist which doesn't
| take multiple hours to fill.
|
| For obvious reasons, that checklist isn't going to work
| for the majority of people (you named several reasons
| yourself). But changing the questions isn't going to help
| reach the intended goal either.
| etothepii wrote:
| While many on here complain about the length and amount
| of interviews I think that's because they get nothing
| from it. They already know how great they are!
|
| Adding an extra 15 minutes at the end of a 7 hour
| interview process to find out if this is a place you
| might actually enjoy working seems like a no-brainier.
| I've also seen it make leaving much easier.
|
| If you did ask (in a more polite and helpful manner than
| proposed by the OP) questions like these and the hiring
| manager lied to you moving on will _feel_ much easier.
| arcticbull wrote:
| > is a flag because it implies that the person asking the
| question thinks their definition of "improve the code base"
| is the only one that matters. It also is asked in a way
| that suggests a lack of maturity around disagreement and
| communication.
|
| The flag for me is that they routinely fail to get
| alignment from their co-workers before they begin
| potentially contentious changes. It's a sign of maturity to
| identify stakeholders, drive towards consensus and ensure
| alignment before beginning on any such project.
|
| I highly recommend this [1] as a framework for resolving
| such issues - and also it's a super strong answer if you're
| asked how you personally resolve such issues within an
| organization during an interview. The core principle is
| that people care more about the decision maker hearing out
| their idea, and understanding it, than they do about their
| idea being picked. The focus is on hearing people out. IME
| it's very effective even with, er, prickly personalities.
|
| [1] https://review.firstround.com/square-defangs-difficult-
| decis...
| geofft wrote:
| The blog post makes it clear that there's an intended single
| correct answer to this question, "No, a person who does this
| specific thing does not exist." It doesn't give room for
| "Yes, and I think they're right to do so, and here's why" -
| or even "No, but there's a person who ships their own stuff
| without review all the time."
|
| I think you could ask it in an open-ended way (though maybe
| phrased more like "What's the most difficult part of getting
| code improvements shipped" or "How does your team tend to
| balance the merits of making big changes" or "What is good
| and bad about your code review process") and it'd be a fine
| question.
| BlargMcLarg wrote:
| I'll articulate. The question is indeed asked with intent,
| but to the one answering, it comes across as something that
| can have a lot of answers as GP shows. At the same time,
| any answer can likely be interpreted in many ways, too. It
| opens up a lot of potential variations which, if you're
| looking for a specific answer and aren't very adaptable,
| sets the other party up for failure.
|
| It's the same issue which many traditional questions asked
| by interviewers have. They are at best "okay" when asked
| with an open mind. At worst, they are beyond worthless and
| create bad blood, as the other party is set up to fail.
| throwyawayyyy wrote:
| To expand on why I think it's a bad question, "Yes, and I
| think they're right to do so, and here's why" is probably
| the best response I could come up with, and makes the
| interview adversarial for no good reason. It becomes an
| argument about the premise of the question. Putting the
| interviewer _or_ the interviewee on the defensive helps
| neither.
|
| Added: I realise I'm being adversarial myself here too :).
| You are correct, in that the questions could be reworded in
| better ways. Agree on that!
| throwyawayyyy wrote:
| It's a fair point -- and there are plenty of standard
| interview questions which fall squarely into that bucket.
| E.g. "Tell me your greatest weaknesses" is a horrible
| question that I for one never ask.
| NikolaNovak wrote:
| They seem fairly closed rather than open questions. They imply
| they are running a closed checklist for purpose of insta-
| rejection, as opposed to being curious or open minded or
| wanting to know more / initiate a conversation. At worst, it
| reads as simply a list of bad experiences.
|
| And that's fair. Reading HN, impression (correct or not) is
| that a lot of folks are expert enough, highly paid enough,
| demanded enough, to afford to be arrogant aholes. And that's,
| again, fair enough!
|
| On the other hand, some employers can _also_ afford to do their
| own rejection checklist, and being an arrogant ahole may be on
| it. It ultimately always comes down to what your priorities
| are.
| gregmac wrote:
| > "Does this team or any of the related teams have a person who
| actively rejects proposals to improve the code base?" is a BAD
| question to ask in an interview. What answer could an
| interviewer give?
|
| If I was asked this, I'd respond with "can you give an example
| of what kind of improvements you mean?" and discuss from there.
|
| I'd also ask something like "What's the experience you had that
| caused you to ask that question? What did you propose, and why
| did it get rejected? What would you do differently if you could
| go back and do it over?".
|
| This kind of discussion is what gives me the most insight into
| a candidate. Things like: Have they grown, maybe even see
| things differently now? Did they dig to fully understand why it
| was rejected? Did they learn how to better interact with their
| team? Would they propose smaller, iterative changes? Did they
| figure out how to justify technical changes against business
| value?
|
| Hint: an answer that is basically "my team was just idiots and
| couldn't see my brilliance" is almost certainly going to result
| in a "no hire" from me.
| karaterobot wrote:
| It sounds like they're trying to identify whether there is an
| egomaniac or monomaniac with veto power on the team or not,
| which is a good thing to know, and a legitimate thing to want
| to find out before joining. I think the question is poorly
| phrased, because it leaves open the line of follow-up
| questioning you offered. It would have been better to ask
| something like "if I had an idea for how to improve the code
| base, can you describe the process for getting approval to
| implement it?"
| arcticbull wrote:
| This is one of those things where you set out to learn
| something useful but your question makes it look like
| you're a dick at your old job and that you lack the self
| awareness to realize it's your fault your coworkers are mad
| at you.
|
| As someone who has interviewed easily a thousand engineers
| of all seniorities over the last 10 years (2-3 per week
| since 2012) my gut reaction would be "this candidate
| doesn't know how to work with others" - my next thought
| would be "I bet they allow code review to become
| architecture review and then get mad when people aren't
| happy with their code because they failed to get alignment
| first."
|
| Now whether or not that's true of this particular candidate
| it drives the conversation negative pretty quickly and then
| they have to string together the right set of answers to
| follow-on questions to avoid this becoming a red flag. It
| also puts the interviewer in a mode of looking for other
| red flags they might not have even paid attention to. The
| candidate is now on the defensive instead of projecting a
| positive image as @gregmac pointed out.
|
| I would re-frame this question something like:
|
| > How do you think about the role of code review in your
| organization? Do you distinguish between code review and
| architecture review? Are ICs encouraged to obtain alignment
| before they get started? How would your team handle/resolve
| a situation where someone failed to get alignment in
| advance? Do you have an example of when this happened and
| how it was resolved?
|
| To me this says "I've seen this happen before (+1) and it
| sucks (+2), do you have a culture of letting this happen
| (+5)?" not "my coworkers are mad at me (-5) but I haven't
| figured out why (-5) so it's probably their fault (-5)"
| haha.
|
| [edit] I should say if I catch a candidate making an
| obvious mistake like this and they successfully clear that
| red flag, I will advise them not to frame their question
| like that in the rest of their interviews - but I doubt
| most interviewers are as friendly.
| zhala wrote:
| > "Anything under 10 minutes is good" for running the CI
| pipeline (not true anywhere I've been at Google) or "The steps
| should be 'do a git clone...'" (also not true at Google).
|
| Are these both true/common in the industry? At least where I
| work CI takes at most a couple minutes (depending on what all
| you're doing in your docker file) and likewise you can just
| pull and run CI locally on your machine for nearly any repo.
| thfuran wrote:
| Our test suite takes about 30 minutes, but that's running
| across like 20 nodes. It's not practical to run locally,
| though individual test cases can be.
| shultays wrote:
| It can take up to an hour at where are work. Each commit
| requires a bumch of compliation for different targets and
| some unit tests
|
| AND after the commit and all that there are many more tests
| at farms that can take a lot more depending size of queue
| SpicyLemonZest wrote:
| Times above 10 minutes are very common and really unavoidable
| for some kinds of systems. You can mitigate the impact on the
| practical develop loop with effort (caching parts of the
| build, splitting off slower tests), but if you're building
| something like a database 10 minutes just isn't enough time
| to validate your change hasn't broken anything.
| onion2k wrote:
| _Does this team or any of the related teams have a person who
| actively rejects proposals to improve the code base?_
|
| On the basis that no one should have unilateral power to reject
| features, regardless of whether it improves anything or not, it
| seems quite of that the straightforward answer is a simple
| "No". If the candidate withdraws their application on the basis
| of that then both sides have won.
| majormajor wrote:
| As a non-Googler I'm very curious how much Google lets you
| check out onto your dev machine. I'm assuming it's less than
| "oh, yeah, just clone locally that shard of the prod gmail DB
| to debug that weird thing," but I would love to know how much
| less.
|
| Some of the companies I've worked that let me do the most with
| my machine were also the strictest about "real" work and data
| remaining _off_ of personal machines in favor of remote (and
| non-admin) access to shared resources.
|
| Assuming that developers can never be privacy, confidentiality,
| or other sorts of information security/compliance risks is
| silly.
|
| I think a much better question would be "how are information
| security and privacy controls implemented" so you know if it
| meshes with how you want to work and what you think is
| appropriate for the sorts of data involved. Super-draconian
| policies for trivial data would be frustrating - but super-lax
| ones for sensitive customer personal information would be its
| own different red flag.
| throwyawayyyy wrote:
| > I think a much better question would be "how are
| information security and privacy controls implemented"
|
| Agreed, that's a great question to ask.
| rwiggins wrote:
| Well, for starters there isn't just one dev machine :-) You
| at least have a laptop and a workstation. Possibly several of
| each. I believe there is no code at all stored on laptops,
| barring some exceptions.
|
| I am not entirely sure 'check out' is an applicable concept
| to the tech stack. There's quite a lot of (public)
| information in this article in the 'Background' section:
| https://cacm.acm.org/magazines/2016/7/204032-why-google-
| stor...
|
| In particular, look for the keyword 'CitC' in the article.
| The tl;dr though is that the tooling presents a view of the
| monorepo where 'everything' is available (excluding the
| protected sections) - while keeping the actual files off of
| workstations. (Although there's probably caching?)
|
| Disclosure: I work at Google.
| Vaslo wrote:
| As someone who doesn't work in IT, that question about admin
| rights is huge. I work in finance - is it common to not be given
| admin right to your pc as a developer? I always assumed you folks
| did but maybe the lockdown is just as excessive for you.
| c0nsumer wrote:
| It depends on who in IT.
|
| IT is big and broad and depending on the company you can have
| all sorts of folks -- even developers -- who never have an
| actual need to change admin-level stuff on their own machines.
| Not everyone in IT is doing systems-level stuff that needs
| admin rights.
|
| Having as few people in a company with admin rights to their
| machine is very helpful for securing machines. Sure, some will
| need it, but limiting it to only those with an actual need,
| really reduces risk.
| isbvhodnvemrwvn wrote:
| And there's proactive and reactive approach to it as well.
|
| With reactive, you elevate your rights when you feel the need
| to, and your actions are recorded and then maybe reviewed by
| someone. It's not much more annoying unless you need admin
| rights frequently (which should not be the case, really).
|
| With proactive, you need a ticket and only then, maybe, you
| get to use admin mode, or someone else is going to do things
| for you, maybe correctly.
| topkai22 wrote:
| At the large tech company I work at, we get two machines- one
| for day to day dev work and one for sensitive tasks. I get full
| admin on the day to day dev box and can do all sorts of email
| and collaboration on it, but I can't do certain administrative
| functions or access some types highly sensitive data. The admin
| box is severely locked down, uses a different identity, but
| lets me edit shared services and access sensitive data. It can
| be annoying, but it feels about the right level of paranoia to
| me.
| viraptor wrote:
| If someone clicked looking for a longer / less opinionated list,
| I'm collecting those at https://github.com/viraptor/reverse-
| interview
| greybox wrote:
| A lot of these are fine for web development jobs, but for other
| kinds of software EG AAA Games, Real Time, Control / Monitoring
| software with specific deployment environments, Payments
| processing etc.. these won't be applicable.
|
| I am someone who's worked in a few of these industries over the
| years, let me list a few examples of the kind of places where the
| answers you get to these questions won't indicate goodness or
| badness of the employer.
|
| "Do developers in your organization have full admin rights on
| their own computer?" For security critical applications, often
| no. For obvious reasons. For payments software, the company may
| be compliance mandated to not give you full permissions either.
|
| "Are developers free to choose and install the operating system?"
| For games. Especially PC games, no. If you're developing for
| windows, you'll develop on windows, often with VC++. (maybe if
| you're using Unity, you're CI pipeline will produce builds for
| you)
|
| "How long does it take to run the CI for new merge requests?" In
| game development, it's not unheard of for a full release build to
| take an entire day. Games are complicated, often requiring a lot
| of libraries that are cached, but still need to be downloaded
| onto a fresh instance where a build will take place. This takes a
| long long time.
|
| "How many different IT support organizations do you have. Where
| are they physically located?" Mastercard has its IT support
| organization located in the US. Even for it's UK offices. Tickets
| still get solved quickly even at awkward times in the morning for
| GMT employees.
|
| In short, most of these are only applicable to web development
| outfits. There's nothing wrong with that, web dev jobs are the
| majority of jobs. But just be aware that this is baised towards
| that.
| geofft wrote:
| I asked two questions the last time I interviewed which are
| wholly unrelated to anything on this list, and they found me a
| place I was happy enough with that I haven't looked again in 5+
| years.
|
| To engineers - how do you feel about management / the practice of
| management at this company, especially compared to other places
| you've worked? I was looking for an answer that indicated that
| management wasn't just where they put engineers who wanted a
| promotion, and also that the company's processes realized that
| management was a skill you could be good or bad at just like
| engineering.
|
| To managers - how is diversity on your team? The answer was
| universally some variant of "it could be better," but I got a lot
| of mileage from seeing whether it was a thing they were defensive
| about and whether they thought they actually could concretely
| make progress.
|
| All the technical stuff follows from whether the company has
| reliably competent managers who believe both that they ought to
| make things better and that they are realistically able to. There
| are other specific questions you can ask to answer it; I just
| happened to use these two (and I certainly have no idea if
| they're the best, but they did work). Every bad technical answer
| can be fixed by people who want to fix it; at the same time,
| every good technical answer can go bad without people who care to
| keep things fixed.
| neilv wrote:
| Some of these questions are phrased as expensive compliance
| interrogations... as if they're coming from the kind of
| bureaucracy and authoritarianism that the questioning seeks to
| avoid.
| aaronbrethorst wrote:
| My go to is always "What are your most and least favorite parts
| about working here?"
| chopete3 wrote:
| Heres where you should work based on the favorable/simple answers
| expected on those 10 questions.
|
| 8-10 : Start up
|
| 5-7 : Small Company
|
| 3-4 : Medium ($5B+)
|
| 1-2 : Large ($25B+)
|
| 0 : Very Large
|
| Otherwise you are interviewing at a wrong company.
|
| ---
|
| 1. Do developers in your organization have full admin rights on
| their own computer?
|
| 2. Are developers free to choose and install the operating system
| on their development machines?
|
| 3. How long does it take to run the CI for new merge requests?
|
| 4. Could you explain the process one needs to follow to get that
| fixed and how long does it approximately take?
|
| 4. Could you explain the procedure needed to get a new USB?
|
| 5. Could you explain the exact steps needed to get the code
| built?
|
| 6. Can you build the code and run tests on the local machine as
| if it was a standard desktop application?
|
| 7. Does this team or any of the related teams have a person who
| actively rejects proposals to improve the code base?
|
| 8. How many different IT support organizations do you have. Where
| are they physically located?
|
| 9. Could you explain the exact steps needed to get it fully
| operational?
|
| 10. Do you have a mandatory web proxy that everyone must use and
| enumerate all pieces of security and tracking software you have
| installed on employees' computers.
|
| </sarcasm>
| dmitrygr wrote:
| What does "getting a new Universal Serial Bus" even mean?
| schwartzworld wrote:
| If you read the article, you would know he left out the word
| "hub"
| orev wrote:
| This list smacks of a developer prima donna mentality and if you
| think most of those rationale explanations are reasonable, you're
| more likely to be a liability to the organization and not a team
| player. Companies have numerous goals, responsibilities, and
| compliance requirements that you don't get to ignore or avoid
| simply because Steve Ballmer chanted about "developers" on stage
| that time.
|
| What would you think about a business person who thought testing
| was a waste of time because it slows down releases? Or they don't
| want to use an issue tracker because it just easier to tell you
| something in the hallway? Those thing slow them down, so why
| bother?
| zamalek wrote:
| > This list smacks of a developer prima donna mentality
|
| The reality is that the market for good developers is so
| competitive that they could just walk out and find 10 other
| places with better answers to these questions.
|
| > testing was a waste of time because it slows down releases?
|
| Not a single question is anagolous to this. Developers want a
| fast CI process (and testing can be fast, given adequate time
| allocated to improving CI) because developers are happiest when
| they are productive. What type of business person would say
| "no" to employees who only want to be productive? Apparently,
| the majority. The problem is when micro-management ends up
| prioritizing tracking work over doing work. It might help to
| listen to people who are passionate about shipping product,
| instead of shipping metrics.
|
| Although it is a software concept, these questions guage the
| degree of accidental vs. essential complexity within an org.
| Silhouette wrote:
| _The reality is that the market for good developers is so
| competitive that they could just walk out and find 10 other
| places with better answers to these questions._
|
| That may have been the case in certain parts of the world for
| the past few years. The next year or two might bring some
| rude awakenings for mid-to-senior devs who are only a few
| years in and have never seen things any other way.
|
| I was trying to work out how many of these questions a
| candidate could ask me - with the attitude implied by the
| tone and phrasing in the article - before I immediately
| terminated the interview and no-hired them. They might get
| away with one or two of the ones with reasonable underlying
| points with the benefit of the doubt about the attitude
| problem but I doubt they'd get past that. If they really can
| get hired at 10 other places instead then good for them but
| somehow I doubt that would actually be true for this kind of
| person. No-one wants a toxic prima donna on the team.
| zamalek wrote:
| > reasonable underlying points with the benefit of the
| doubt about the attitude problem
|
| So asking about CI times, code review process, admin
| rights, being able to run tests locally, and operating
| system choice would likely result in a terminated
| interview? I think the questions would be working perfectly
| in that scenario.
| dasil003 wrote:
| > _The reality is that the market for good developers is so
| competitive that they could just walk out and find 10 other
| places with better answers to these questions._
|
| Sure, but will that be a better place to work?
|
| Ultimately there are many failure modes for software
| engineering teams, and grilling the interviewer with a series
| of highly-specific workflow questions is not likely to yield
| much insight. If the team is really as dysfunctional as the
| author fears, then you're not likely to get an answer that is
| on the same wavelength as you anyway.
|
| You're better off asking things a little higher level and a
| little more open-ended and then reading between the lines. So
| for example, instead of:
|
| > _Does this team or any of the related teams have a person
| who actively rejects proposals to improve the code base?_
|
| You could ask:
|
| > _What are the biggest problems in the code base currently?_
|
| You can then engage in a dialogue and probe into details
| organically. This will yield much more fruit than asking a
| question to which the obvious answer is "no, of course not".
| zamalek wrote:
| I definitely agree with your ideas. I aimed only the refute
| the concept of "developer prima donna."
|
| Just like any codebase will _forever_ contain some amount
| of accidental complexity, so will any org. It 's all about
| whether it is being tackled or embraced. While these
| questions may not be perfect, accidental overcomplexity can
| (probably will) make your job miserable.
| michaelt wrote:
| _> Sure, but will that be a better place to work?_
|
| If an employer doesn't give developers local admin rights
| on their machines, I'm quite certain it's not going to be a
| better place to work _for me_.
| ThrowawayTestr wrote:
| Idk, not having admin rights is super annoying.
| Xylakant wrote:
| I agree, but having them is also a huge liability. I'm always
| happy to have less privileges because it limits the damage I
| can accidentally cause. If someone competently manages my
| machine so that I can do my work without requiring root
| privileges, that works for me.
|
| The actual question I'd be interested in is how do developer
| convenience and security stance balance against each other,
| and how are the inevitable conflicts resolved.
| beeforpork wrote:
| Well, I kinda like it -- less things to care about, more
| reason to leave at 5.
|
| But it's counterproductive for the company, and some
| experiments a developer may want to quickly do will never be
| done at all. It kills a lot of creativity. The same holds, of
| course, for restricting internet access so a dev might never
| find out whether an interesting looking github tool really is
| good (for doing productive work!). Also, the company probably
| wants their products to run on a diverse zoo of machines and
| OS versions prior to release.
|
| So why a company would take away such access on dev machines
| is a mystery to me -- probably misguided (and futile)
| attempts to keep in 'control'.
| lmeyerov wrote:
| Free drinks and fast CI don't solve a broken company, product, &
| team. The former you can always fix on your own, but not the
| latter
|
| Two+ years of your life have much more important questions than
| staging servers, such as:
|
| * "Is the company profitably growing at > 50% YoY" <- is it
| winning?
|
| * "What will it take for the next 100X in growth?" <- will it
| keep winning?
|
| * "What happens if the next fundraising round doesn't land?" <-
| is it a wobbling VC trick?
|
| * "For this job, what will I own, and what skills do I need to be
| successful at that?" <- will you succeed?
|
| * "What percent of the team has been there more than 1yr, and
| more than 2yrs? Why do people stay vs leave?" <- is it a healthy
| environment?
| rroot wrote:
| You can't fix a broken CI in a broken company, product, & team.
| But I get what you're saying.
| lmeyerov wrote:
| The good news is you can totally fix a broken CI in a working
| company, product, & team, so those are the more important
| things to ask about
| [deleted]
| robertlagrant wrote:
| > Suppose the team needs to start a new web service like a
| private Gitlab, add new type of CI to the testing pipeline or
| something similar. Could you explain the exact steps needed to
| get it fully operational? Please list all people who need to do
| work to make this happen (including just giving authorization),
| and time estimates for each individual step.
|
| Time estimates for each step? What on earth?
| siliconpotato wrote:
| This question would be a big red flag for me. I don't wanna
| hire someone who goes and makes all these skunkworks projects
| under the radar without following standard good practice. The
| next thing you know, it's part of the infrastructure, and isn't
| backed up or documented, or contains private keys and nobody
| else knew about it
| gregmac wrote:
| Things like CI times and build process strike me as
| opportunities. If they're bad, there's a spot you can contribute
| and make it better.
|
| A core piece of that is figuring out if they're open to spending
| times on improvements like these, and figuring out why they
| haven't: recognition of a problem? Expertise to fix it? Constant
| time crunch? No prioritization input from dev team?
|
| A question might be something along the lines of "As a team would
| you spend 3x once to save x time for every subsequent
| sprint/release after that? What's the last example of where you
| did this?" This applies to CI/build process, unit testing, other
| automated testing, deployments, etc.
| JustLurking2022 wrote:
| Full admin is a non-starter for regulatory reasons in some
| industries (e.g. finance). Also, at Google, developer laptops are
| essentially untrusted - all code lives in the monorepo target
| than being cloned locally, so there's nothing of much value on
| the device.
| codingdave wrote:
| This list is asking about specific symptoms of larger problems
| about which they may be concerned. To which I'd just recommend -
| don't be coy. If you want to know what the experience is like
| being a developer there, just ask directly -- Don't symptom-
| check.
|
| If I were asked these questions, I'd cut them off and ask them to
| tell me what they are afraid of - we all have our own fear and
| anxieties about starting in new environments, but I'm far more
| likely to hire someone who can open a dialogue about their
| concerns than someone who just picks aspects of past experiences
| and grills me about them. Not only will the interview get more
| directly to the point, such a conversation will show they are
| able to talk through whatever problems may arise in the future.
| Kwpolska wrote:
| > Too slow of a CI means that instead of submitting small,
| isolated commits people start aggregating many changes into a
| small number of mammoth commits because it is the only way to get
| things done.
|
| I don't understand the point here.
|
| 1. `git commit` and `git push` are two separate steps, you can
| commit often, but you can push once every few hours, assuming
| your computer won't catch fire in the meantime.
|
| 2. If your CI builds every single commit pushed to a branch
| (instead of just building at every push), that's a very weird CI
| config.
|
| 3. Where is the slowdown? Is it because your commit is waiting in
| a queue behind other commits?
| rroot wrote:
| The fundamental problem with slow CI is developer's own context
| switch.
|
| If CI notifies me an hour later that my changes fail CI, I have
| might have to abandon my flow, sort out the failure and
| commit/push again. Then get back into whatever I was doing.
| This can be very taxing for developer's time and mental well
| being.
| kaoD wrote:
| I think they mean isolated PRs. Been there, done that.
| roflyear wrote:
| Meaning, PRs are generally bad to require to do a build?
| [deleted]
| webel0 wrote:
| I think that some of these questions are quite important.
| However, I think that all of them could be interpreted as
| "missing the forest for the trees" sort of questions. Therefore,
| I don't tend to ask them in interviews.
|
| If you do ask these questions, at what point in the interview
| process (or within a given interview) do you ask them?
| twodave wrote:
| I have had to answer a lot of these questions before, but not for
| a potential hire. These are the kinds of questions auditors tend
| to ask during due diligence of a software org (especially the
| "give me time estimates" type questions). Usually in an audit
| type setting these answers aren't readily available because there
| are limitless ways to ask these questions and supporting data to
| request. An organization isn't typically going to spend that
| level of effort to satisfy one obviously pretentious candidate.
| skhavari wrote:
| I find these much better questions to ask a prospective employer
| during a job interview: https://github.com/viraptor/reverse-
| interview
| t8sr wrote:
| As others point out, some of these are quite naive. (E.g. at many
| companies you have a large monorepo, so the "git clone" comment
| is silly, etc.)
|
| What really gets me, though, is the tone. There's a nice way to
| probe for organizational problems like too much bureaucracy
| without coming across like a jerk. If someone showed this lack of
| self-awareness and basic social skills in an interview, I can
| promise they'd be a strong no hire.
| saiya-jin wrote:
| Yeah the tone has some arrogance thats for sure. Maybe it would
| be a wet dream of some startup CTO but in some bigger, more
| stable and older corporations this would just trigger Next!
| response.
|
| The author is clearly experienced in very narrow set of IT
| reality and not much more, he would fall into promising junior
| category if he would skip the arrogant part.
|
| For each question, I would point out our massive set of
| existing rigid processes and give back immediately: how would
| you improve on that while still being compliant on them?
| Companies are not there to baby sit juniors with big egos, they
| have products to deliver that mostly uses IT just as part of
| the overall process. They like improvements, but only those
| that keep things working seamlessly, on budget and time.
| civilized wrote:
| I agree that the way the answers are evaluated is too narrow
| and simplistic. That said,
|
| > coming across like a jerk... lack of self-awareness and basic
| social skills
|
| I see things very similarly, but from the other side of the
| table.
|
| If an organization is uncomfortable with me asking direct-but-
| polite questions about potentially negative aspects of working
| there, and asking such questions gets me labeled as a jerk,
| that organization is too culturally dysfunctional for me to
| work for.
| t8sr wrote:
| The issue is not with being direct, but with instructing the
| interviewer to "please list the exact steps and time
| estimates for each." It smacks of self-importance and
| arrogance, and the way it's phrased strongly suggests the
| author thinks they are the smartest and always right.
|
| By the way, I looked this guy up, and his experience looks
| like it's extremely limited to basically a couple of SMBs and
| some consulting. I have no idea where he gets the confidence
| to comment on the industry, having basically never worked in
| it.
| exabrial wrote:
| "Is this Position a backfill for someone that left? If so, why
| did they leave?"
| [deleted]
| nojito wrote:
| This post should be exhibit A on why software engineering/dev
| managers get paid so well.
___________________________________________________________________
(page generated 2022-09-04 23:00 UTC)