Hacker News Reader

Comment by throwyawayyyy | Hacker News Reader

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

View on HN

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

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?"

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.

Does it at all strike you as weird that in the case where your process is giving a false signal you're suggesting how the other person should act differently?

He or she was offering an alternative approach to obtain the same information that is less confrontational.

As framed originally, the interviewee sounds like a dick.

He is impersonating one party and telling you how that person will clearly get a false signal from your actions. What do you expect him to do? To tell the party that isn't part of the conversation how to improve?

You can't control the hiring company's process, who the company picks as an interviewer and you don't know what else is going on in their day/life - but what you can control are your questions so you can project a positive image no matter what. I'm helping you here. My reframe isn't just "how to sound less like a dick" - although there is that - it's also a way to demonstrate maturity and positive signal at the same time which helps ensure you're leveled appropriately too.

Interviewing may be a craps shoot, but you can always adjust the odds in your favor.

> You can't control the hiring company's process

You can. You're an interviewer. Lost of people on this site are interviewers.

I get that your advice is more useful to interviewers. I get the stuff about maturity, and so on. No reason to bring it up again.

What you don't seem to get is that every bit of your comments take the side of the interviewer as an immutable force that must be adapted to by the interviewee. If a few tweaks can have such a big impact on a classifying mechanism, maybe there's something wrong with the mechanism.

At the very least I just want to point out that you could have the reaction "This makes me realize the mistakes in my interviewing and how I will change and suggest others do." vs "Here's how candidates should act differently to not give a negative impression to important people like me."

> "Here's how candidates should act differently to not give a negative impression to important people like me."

I'm only important in the sense that my job is to obtain a fair and consistent evaluation of someone along a defined set of criteria - to see if there's a good mutual fit! I want a candidate to succeed once hired, so I'm looking for signals that they would succeed. A mis-hire sucks because getting fired sucks. That's why I'm also looking for signals they would not succeed. A lot of the time we try and avoid false-positives at the cost of false-negatives.

We're looking for certain things, and in the scope of just a 45m or 1h window it's really hard to get a complete picture of who someone is. This is also why have multiple interviewers ask many different kinds of questions.

I'm quite sympathetic to your position and I'm always super active in hiring wherever I work. I built our Mobile Staff+ interview loop at my current employer and trained up a most of the interviewers!

I do my best to make the process suck less for all involved, but folks like me won't always be on the other side. Even at employers you'd otherwise love! That's why I was hoping to provide some quick tips to eliminate potential roadblocks no matter who you find yourself up against.

There is a name for this technique, but I forget the exact term. Something about Rabbis who always answer a question with another question. When two Rabbis discuss, this often ends in "question volley" ad infinitum. This has been humorously played upon in a game (called The Shivah) who used it as an equivalent to Monkey Island's Insult Swordfight, where if you failed to answer a question with a question you'd "lose" the point.

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.

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.

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.

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.

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.

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.

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.

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

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.

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!

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.

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.

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.

Obviously I did not tackle it because of some ideal to fight fire with fire. I'm tackling it as people seem to forget something very obvious:

Most red flags are entirely dependent on your position in the market.

The less fortunate (people in careers with low demand, juniors, etc.) do not have the luxury to ask most of these questions, let alone vet for every red flag.

My point is to illustrate the absurdity most people face and how normalized it is from the employer's side. If devs are already ridiculed as Prima Donna's by their peers merely for proposing such a list, I'd expect those same people to think twice and critique the status quo too. Yet, developers are more often tone policing each other rather than handling the same standards for employers, from my experience.

Author wouldn't even be blogging this if they only had a portion of the power they have now.

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

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.

> I think a much better question would be "how are information security and privacy controls implemented"

Agreed, that's a great question to ask.

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.

But how do you actually edit files in your local text editor? The article mentions FUSE for Linux. Is this also used for macOS?

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.

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.

> 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?"

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

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.

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.

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

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.

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

Reply on news.ycombinator.com