Hacker News Reader

I think people are overly interested in self-promotion in an interview situation. In sales training I did many years ago, there was the maxim that, whoever mentions price first, loses. The better way is to get the person to talk about themself, their needs, the nature of the work, everything you can coax out of them.

In the sales mode (which, of course is what an interview is), the idea is to gather information to understand the real need and configure a product that meets it.

In an interview, that is you. If the job doesn’t explicitly require experience, then it should never be mentioned. In fact, it should be concealed unless, during the information gathering, there is reason to think it is necessary.

Too many of us approach an interview with the idea of “if I can just let them know how good I am”. Far better is, “how can I help them understand how well I fit their needs”.

During the information gathering, ask questions that help the other person actually say things that match your (hopefully narrowly targeted) resume. Not in obvious ways, “Do you use React?” but get them to think it up, “What front end framework do you use?” followed by another question about React when they say they use it.

The point is Focus on Them. Not Yourself. Learn don’t Talk. Fit in, don’t try to impress.

>> In sales training I did many years ago, there was the maxim that, whoever mentions price first, loses.

This is just a popular maxim, but I've found it only really applies when you're trying to sell something very expensive, buy it very cheap or have no idea what the price should be. Most of the time the first price anchors and then the other party negotiates. If you know what you want and have confidence in the general value, go ahead and set an aggressive anchor.

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

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)

>Finding a job through a network might be one solution.

Especially as you get older, especially with a resume that isn't cookie cutter and ticks the right keywords, this becomes more and more important. And it applies even if you're self-employed. Just applying online works a lot better when you have some track record of very specific in-demand skills.

Sometimes I think the best solution would be to avoid that people from the hiring group interview the candidate. This would force the company to hire based on the needs of everyone, not based on who I would like to work with.

If we did that at my company I’d get a bunch of people who are very senior web developers but who don’t know anything about embedded. A better solution is to talk to the hiring committee and make sure everyone is aligned on what to look for, and to only hire team leads who think about building a team in terms of supporting the team’s functions instead of replicating their experience.

Yeah, you pretty much just described some of the worst interview experiences I've ever had. Seeing you write it here like this makes me feel much less alone. Thought I'd say I appreciate it.

Can relate, as well.

I remember applying for an ObjC job, and getting a Swift test, because that was what the guy interviewing me, knew (this was many moons ago, when I wasn't as experienced with Swift, as I am now. These days, I could totally ace it).

In my case, I just got sick of being abused, every time a tecchie got involved, and stopped looking.

In my experience, the (in-house) recruiters, HR, and manager-type folks were great.

However, as soon as one single tecchie got involved, the glaciers started forming. They would poison the whole thing. It didn't matter, whether or not I "passed" the interview. The tecchie made it clear that I would not be welcome, and I won't go, where I'm not welcome.

Same experiences. Technically capable folks with an ego are the most insidious folks I meet.