Hacker News Reader

Comment by aleph_minus_one | Hacker News Reader

> but when you get a tech lead with 9y exp interviewing someone with 15y exp, it's weirder. Some put you on a pedestal, some get insecure and treat you like some dragon to be slain.

The explanation is very simple: software development is divided into an insane amount of distinct "subgroups"/"subcultures". If you looking for someone experienced, you actually look for someone "experienced in the respective subculture".

If you now have some chandidate who is experienced in a very different subculture, he will either be a beginner in "your" subculture (will he like this role and payment?), or the department culture has to be adjusted more to "his subculture", which implies the the interviewing person will loose power.

View on HN

We normally define senior engineers as those who have permissions to change the culture. Junior engineers are usually technically skilled; heck, they'll usually score better on the tests. But they lack the tribal knowledge. They'll come in and say we need more DRY and SOLID and we need to follow Google's code style, and people will roll their eyes.

But for seniors, it's literally the job. These guys who built payment gateways moving billions of dollars. The security folks who deal with millions of automated attacks a year. The guys who delivered AAA games without crunch time. They reduced crash rates from 5/month to 5/year. Reduced build times by 10x, doubled productivity, etc.

You shouldn't be leashing them and telling them to be humble. You want them to come in, tell us how to do things better. Nearly every senior we hired is like this.

The most senior staff engineers are the ones who come in and give us really bold ideas. e.g. Write less tests. Stop using feature flags. Write less docs. Change performance reviews. Run all QA testing in production, using real money.

I think everyone is bound to push back on these ideas, but they should be listening to them. Bad interviews are unidirectional.

Could you elaborate on "stop using feature flags"? How is that considered bad (as long as you clean them up when their purpose is done)?

Feature flags are not 100% reliable. They tend to be booleans of two different values. We've had complications on the null path, e.g. we assumed all mobile use would be either from Android or iOS, but sometimes an Android device refuses to identify as Android.

The fallback has to be handled properly. We make sure the default is the one with least risk and have to audit this regularly to fit the current state of the product. Yes, they're tech debt, there's also management overhead for this, and they should be regularly cleaned up. There was a habit of using it as a hack for unprepared releases, so we put some bureaucracy to make sure it's properly thought out.

They're also a security risk; hackers can just send a false flag, so we have to consider whether this is safe.

A lot of the use of feature flags is because a customer asked for a certain feature. For these, it's usually better to just hardcode it to if (customer===A)

Reply on news.ycombinator.com