6 ms·

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"

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...

majormajor 4y ago
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 4y ago
  > 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 4y ago
  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-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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.
  - 4ad 4y ago
    But how do you actually edit files in your local text editor? The article mentions FUSE for Linux. Is this also used for macOS?
    - rwiggins 4y ago
      Usually, devs use one of Google's web-based code editors. No local editor at all. The web editors are pretty well integrated with the rest of the dev stack... and they just work. CitC workspaces aren't mounted on laptops, so no MacOS support. I think sshfs is permitted if you want to use something like Emacs or Vim on your laptop rather than on your workstation. I've never tried at Google, but previous experience with sshfs tells me the performance probably wouldn't be great. Maybe some tweaks help. Honestly, these days I'm much less willing to tinker endlessly to get the 'perfect' setup.
- sgtnoodle 4y ago
  When I was there, you could have whatever on your workstation inside the office. No source code was allowed on any mobile device, though. For a while I would use sshfs into my workstation when coding on my laptop. Google's version control system is pretty fancy, though, moreso than simply just storing files on your local filesystem (client in the cloud). At some point it became easy to write code in a browser based text editor, and I did that both on my laptop and on my workstation; it had the best code search integration.
- deleted 4y ago
  [deleted]
- btgeekboy 4y ago
  > I think a much better question would be "how are information security and privacy controls implemented" I don't work for Google, but if I was asked that question, I'd be afraid of giving an answer that would violate my NDA. You'd probably get a vague answer like, "Those policies and processes do exist, but I'm not at liberty to go into them right now. Why do you ask - is there something specific I can address?"
BlargMcLarg 4y ago
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.
- majormajor 4y ago
  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.
rzzzt 4y ago
Maybe there should be a person on each team who actively rejects proposals (can also be multiple people on rotation). The nemesis!
gregmac 4y ago
> "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 4y ago
  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 4y ago
    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 4y ago
> "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 4y ago
  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.
- SpicyLemonZest 4y ago
  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.
- shultays 4y ago
  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
onion2k 4y ago
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.
shultays 4y ago
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
NikolaNovak 4y ago
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.

majormajor 4y ago

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 4y ago
> 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 4y ago
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-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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.
- 4ad 4y ago
  But how do you actually edit files in your local text editor? The article mentions FUSE for Linux. Is this also used for macOS?
  - rwiggins 4y ago
    Usually, devs use one of Google's web-based code editors. No local editor at all. The web editors are pretty well integrated with the rest of the dev stack... and they just work. CitC workspaces aren't mounted on laptops, so no MacOS support. I think sshfs is permitted if you want to use something like Emacs or Vim on your laptop rather than on your workstation. I've never tried at Google, but previous experience with sshfs tells me the performance probably wouldn't be great. Maybe some tweaks help. Honestly, these days I'm much less willing to tinker endlessly to get the 'perfect' setup.
sgtnoodle 4y ago
When I was there, you could have whatever on your workstation inside the office. No source code was allowed on any mobile device, though. For a while I would use sshfs into my workstation when coding on my laptop. Google's version control system is pretty fancy, though, moreso than simply just storing files on your local filesystem (client in the cloud). At some point it became easy to write code in a browser based text editor, and I did that both on my laptop and on my workstation; it had the best code search integration.
deleted 4y ago
[deleted]
btgeekboy 4y ago
> I think a much better question would be "how are information security and privacy controls implemented" I don't work for Google, but if I was asked that question, I'd be afraid of giving an answer that would violate my NDA. You'd probably get a vague answer like, "Those policies and processes do exist, but I'm not at liberty to go into them right now. Why do you ask - is there something specific I can address?"

BlargMcLarg 4y ago

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.

majormajor 4y ago
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.

rzzzt 4y ago

Maybe there should be a person on each team who actively rejects proposals (can also be multiple people on rotation). The nemesis!

gregmac 4y ago

> "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 4y ago
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 4y ago
  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 4y ago

> "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 4y ago
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.
SpicyLemonZest 4y ago
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.
shultays 4y ago
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

onion2k 4y ago

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.

shultays 4y ago

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

NikolaNovak 4y ago

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.