Live data from Hacker News

When hiring senior engineers, you’re not buying, you’re selling

hiringengineersbook.com

681–690 of 694 posts

Re: When hiring senior engineers, you’re not buying, you’re selling

#681

Earlier quoted context omitted.

If they understand their friend's work deeply, doesn't that imply they've done something comparable themselves?

No, let me give a specific example. Imagine you're interviewing a candidate and they're talking through how to design an analytics service. They begin talking about e.g. database architecture, and how this type of data is most appropriate for a star schema. They start talking about the tradeoffs of row versus column orientation. They mention they'll need to do indexing for performance and talk about the index space v…

I came multiple times across similar individuals as you have just described. They are very good at talking in details about a tech subject, charismatic, defensive and argumentative all day long over their solution even though it does have lots of holes. But when it comes to actually implementing a task. They usually fall short. They will quickly grap an existing/similar solution from ie github., spend many hours trying to understand it, Then copy-pasted and present it as their work (half-baked solution)

Even though the whole thing could be very simple. Another thing is, they will come up with reasons that the issues with the user story/task for code/solution is due to environment or some other reasons like tools, framework, scalability and "bs".

Re: When hiring senior engineers, you’re not buying, you’re selling

#683
post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

To be honest, I don't think your questions were good enough to filter out the smooth talkers. I was in a senior position at a successful agency and was hired before they changed their interview style to match the eye-rolling "technical interview" that is now gold standard. I repeatedly argued they were getting too many false negatives and only a certain kind of developer with this style, but they believed "if Google…

I really wish more interviews asked these questions. They're not only good questions for the reasons you mention, but for the interviewee (at least for me) they tend to be pretty low-stress to answer. Those sort of questions are, after all, something that I might be asked to do or think about during my everyday duties at a new company.

I always sigh in relief when a company I'm interviewing with asks me something like that vs something like "implement x algorithm to solve y niche computer science problem you probably learned in college at some point".

Re: When hiring senior engineers, you’re not buying, you’re selling

#684

Earlier quoted context omitted.

I disagree. If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. It comes down to interest. A good senior got that way because they like solving challenging problems. They are not inte…

I agree with your comments, but let me share my 2c on "trendy framework bs". Most of interviews I've done to candidates ended up in discussing technology trends and googling around for cool open source projects, libraries and so. This, to me, is a good indicator - as long as you bring them up when discussing relevant problems, this means you thought about a problem and researched prior art to avoid re-inventing the w…

Reinventing the wheel is a cliche I have grown to detest. I have found that cliche is abused 9 times out of 10 to avoid the deep dive into a problem. On the other hand, approaching the problem again allows the developer to consider the precision of current solutions or consider a simpler solution. Good seniors aren’t afraid of making decisions.

Re: When hiring senior engineers, you’re not buying, you’re selling

#685

Earlier quoted context omitted.

That was not my experience. Google was pretty inflexible and offered me (with 16 years of experience) well under $300k for an L4 position. A month later Twitter offered me 35% more than Google's best and final offer for a more senior position. I didn't even have to negotiate or mention the rejected Google offer. Oh, I should add that, in my case, the downlevelling was up front. The recruiter wouldn't even put me in f…

I don't know the details of your experience (were all 16yrs of experience as a SWE demonstrating a deep technical expertise?), but Google puts engineers with even 2-3years of experience on an L4-interview loop. If you knew that you were being slotted for L4 upfront why did you even bother interviewing? I've seen L4s rack up multiple job offers from different companies and use that as leverage to negotiate; they've al…

> I don't know the details of your experience (were all 16yrs of experience as a SWE demonstrating a deep technical expertise?), but Google puts engineers with even 2-3years of experience on an L4-interview loop.

It's all engineering, and the majority (10+) was pure software engineering.

> If you knew that you were being slotted for L4 upfront why did you even bother interviewing?

I didn't find out until late in the process, I thought I was going to get a better offer than I did, and I was trying to correct the mistake I had just made by accepting the job I was then in. I only realized my mistake after the offer came in and I considered what dropping back to L4 would mean.

> I've seen L4s rack up multiple job offers from different companies and use that as leverage to negotiate; they've all been offered $300k+ or more.

That would have been nice, but I barely had time to keep up with one company process at a time without arousing suspicion. I was close with Facebook, but I decided before the actual interview that I wasn't going to take L4 at any price. Facebook rejected me anyway, so it wouldn't have mattered in the end.

Re: When hiring senior engineers, you’re not buying, you’re selling

#686
post #568
post #283

Earlier quoted context omitted.

I hear what you're saying, but I think you're maybe creating a straw man argument here. A smooth talking engineer isn't one who sounds like a used car salesperson or is just hyped about the latest trendy framework. There are people who can talk through challenging problems at their former companies and how the problems were solved. They can tell you everything you'd want to hear because it's true. Except…they didn't…

These problems are very simple to solve. Get them to go into detail. Get them to explain their thought process while looking to solve the issue. If you feel that they're talking about a problem someone else solved, ask them that directly. (Did you work with others? etc) If they're lacking on the technical details either it's been a long time ago or they didn't do it.

> explain their thought process while looking to solve the issue

I would think they and their colleagues discussed alternatives together, collaboratively in for example a Slack chat — so an interviewee can give you good replies about the thought process and alternative solutions that were considered and discarded. I would assume. Or maybe the interviewee him/herself came up with ideas, that his/her colleagues realized weren't going to work, and explained why, for him/her. Then s/he might be really good at describing the thought process.

Re: When hiring senior engineers, you’re not buying, you’re selling

#687
post #606

Earlier quoted context omitted.

> If they understand their friend's work deeply, doesn't that imply they've done something comparable themselves? Imagine you're interviewing a candidate and they're talking through how to design an analytics service. They begin talking about e.g. database architecture, and how this type of data is most appropriate for a star schema. They start talking about the tradeoffs of row versus column orientation. They mentio…

Well, do you think my comment demonstrates deep understanding of database design? I don't feel I have deep understanding of databases, but I can certainly talk to you about very basic things like indices and joins. Basically it's like someone else said. They read a book and know a lot of answers, but they can't do the most basic implementation of a solution.

Well, do you think my comment demonstrates deep understanding of database design?

No, it seems about on about the same level as being able to paraphrase the abstract of a paper about the system. I would not take it as showing that someone has read past the first page. A high-level overview just isn't enough for that. You have to ask your own probing questions too. Limiting the conversation to the particular problems they bring up is essentially taking them at their word when they claim to be skilled. I've seen lots of occasions where trying to drill down for a bit more detail on some part of what they talked about consistently came up empty (without going anywhere near sitting down at a computer to write a fizzbuzz equivalent).

Re: When hiring senior engineers, you’re not buying, you’re selling

#688
post #673

Earlier quoted context omitted.

and don’t forget the reverse problem mentioned originally: false negatives. you can have someone who is a whiz at practical and specific solutions, who thinks critically and analytically and just gets an enormous amount done WELL. And empowers those around them to boot! they have the reverse problem to speaking about other peolle’s work as their own. instead, they speak of their own work as teamwork. this effects man…

The problem with hiring is that a false positive is much more damaging than a false negative. Getting the group of people together to vet a candidate is expensive; recruiters are expensive; for the candidates, taking the time off is typically pulling from a very limited bucket of just a few weeks every year; flying people in to interview is expensive; and ultimately, to go through all that and hire someone bad makes…

The "find a reason to say no" can be very damaging as well if taken to the extreme.

I've seen people that were entirely qualified for the position be rejected at the company I work for because they made some totally understandable mistake - I'm talking about people that took the time off to take a 5-hour on-site coding assignment, and made a mistake but would have had a passing (and possibly good) grade on an academic evaluation.

And now we have 5 open positions and nobody hired for them.

Re: When hiring senior engineers, you’re not buying, you’re selling

#689
post #610
post #426

Earlier quoted context omitted.

The subject of what constitutes an engineer or what entitles a professional to the "engineer" title has been discussed ad nauseum here on HN. Spoiler: "engineer" as a title for someone who does computer programming and software development without a license is perfectly fine and acceptable in the USA. In Canada, however, it's probably not.

You say the USA as a whole, but IIRC there are a couple states that do require it to be able to use the title "Software Engineer".

Those states you mention do require it, but what I was getting at is that in general terms Americans don't blink when someone refers to an engineer without reference to licensing.

Re: When hiring senior engineers, you’re not buying, you’re selling

#690

Earlier quoted context omitted.

Do you give them "their" tooling? I can set up a project of the type you describe in about five seconds, because I have a template for it in my IDE. The best defaults for this that I've seen are provided by IntelliJ (do you provide this in interviews? It seems legally challenging to do) and would probably take me 5-10 minutes to navigate. I think Java depends much more heavily on powerful tooling to do the heavy lift…

If they're coming in, I'll hand them a laptop with the project set up and ready to go, with IntelliJ running. If they're normally an Eclipse user I'll swap to Eclipse shortcuts and help them manage the IDE as we go. If it's remote, I'll ask them to share their screen with me with a project set up and ready to go, having emailed them a copy of the interface we're going to implement about 30 minutes before the intervie…

Fair enough, seems like you're giving them a fair shake.
Post reply on HN