"Tell me about the most complicated projects you contributed a significant part of the design, implementation to, or ideally both."
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
Finally, since you now understand the problem space and the solution yourself, ask them "How would you scale this out to 10-100X" (by some metric).
Altogether, this is a dense 40-45 minutes extremely well spent. And it weeds out the phonies and charlatans.
Some yellow flags that individually aren't a problem but when you start seeing multiple of them turn into a red flag:
* Someone who didn't question the requirements and just accepted them from upstream.
* Someone that wrote a lot of code on the project, but didn't make any of the tough decisions.
* Someone that avoids talking about what they did, and focuses too much on "we"
* Someone who did all the initial decisions but did none of the actual implementation work.
* Someone who describes how X solved the problem, but you realize that's the only option they really considered
* Someone who left before the project finished, or immediately after.
* Someone who isn't sure if the project was a success or didn't see it their responsibility to find out.
This is very interesting. I naturally use “we” when discussing past products and achievements. I do this in recognition of the fact that things are very rarely designed and built in true isolation. Even principal engineers socialize their designs and thinking with colleagues, making small tweaks here and there or gaining additional confidence to move forward.
“We” is absolutely not a red flag for me.
Principal engineers know that there are appropriate times to say "we did..." and appropriate times to lean heavily into saying "I specifically did..." (while crediting others for their part, of course, but as briefly as possible) and they also know which one an interview is.
"We" may not be a red flag (I appreciate a measure of humility and recognition of teamwork as well) but it must always followed up by a question about the details of what the interviewee did.
The worst thing with guys like this isn't that they're going to deliver less than promised, but it's that the aggressive "willingness to lie for their own benefit" bleeds into a lot of other behavior at work.
Someone constantly using "I" like they worked in a vacuum, and didn't play nice with their team is a bigger red flag for me.
The important piece in the interview is can they answer in detail the rest of the questions.
The imposters/charlatans (and weeding them out was the context for this whole thread) find a way to avoid the question.
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
This verbatim can very well apply to many different industrial engineering efforts, regardless of whether there is software involved.
>This cannot be upvoted enough.
I agree, and I mean far beyond the message board.
Then you will not get recognition about what you did in the eyes of others. It is hard to trust someone who hides behind a group, because it looks like you have no confidence in yourself or what you did.
I have to say this is an awesome thing to be reading as within a couple of months I'll be taking on my first major project at my new employer. Valuable insight to consider as I proceed.
Nothing, that's expected for a junior developer. The items on the list only become a problem when a "senior" developer does them. One of the parts of transitioning from junior to senior and beyond is learning to understand the business (or other) context you perform your craft in and shaping what you do to help the business succeed.
[EDIT] When I say "help the business succeed", that may sound like management claptrap (even if it happens to be true) so I'll also point out that even if you don't give a flying hoot about the business or its goals, you still do care about understanding whether it's succeeding and profitable/effective at its goals, lest you get blindsided by a layoff or cancellation of your project.
Cheers.
It's only a yellow flag for a senior engineer - which in the framing of the original posting was being discussed. Someone with 7-10 years of experience, I'm imagining.
In my experience, people leave just after the big project ships. They've been focused on a task, working hard and are usually left with "now what?". It's interesting psychology.
I don't know the specifics of Rachel's parable, if any. But by and large, the people who are most well known in industry for 'expertise in X' are the devrel / tech evangelists whose job it is to go on stage and be an expert, for one hour at a time (and perhaps a few extra hours on the show floor surrounding the conference). Well, the on-stage demos they execute only have to live as long as the lecture, and you don't have to fix bugs so much as rework the preso to avoid them. It's a long march from a proof of concept to production readiness, and I've seen one or two stories on HN about people who got burned hiring high profile devrels to lead an infra buildout.
> sometimes either their belief in X is too strong ... or, ... the monetary and career-enhancing incentives are high enough to overcome any unease they may have
One scenario I've seen play out: you hire a core maintainer for a product you depend on, but should probably be transitioning away from. The maintainer you typically don't have comparable expertise in anything else, so they might as well apply for unemployment before telling your boss you recommend against it. Which I suppose is covered in 'monetary incentives' but with tinge of regret about the whole thing, especially if hired away from some a more stable role.
When I think of "experts in X" I usually think of the people who created or maintain the thing, or who're active in the Github issues. I guess some of those people might be considered tech evangelists, but I don't think I could name a single devrel person.
The corporate-climber-who-can't-build can often do this and nothing else, and they can sometimes even subconsciously exhibit some of the behaviors that end up with the same outcome, and it often can actually be unintentional.
She's left the positive case out for the charlatan comment, they wouldn't be charlatans (in this instance at least).
If you tell me to build you a system you don't need, and I do, and you insist on using it against everyone else's better judgment, how did I become a charlatan?
But that doesn't suddenly shift all the responsibility to the expert. The power relation and degree of freedom between those who hire and those who get hired is often asymmetric. The ones who hire usually are the ones who make the decisions, so they should be held accountable for those.
Now of course if the expert does have a sufficient degree of freedom then they become complicit.
because the more likely situation is that the newly hired expert on X is the only one realizing that X is wrong for this case.
You'll see this sort of things a lot from Rachel's writing, but I tend to write it off as a stylistic choice. She kind of channels the BOFH [0] sometimes, I think :)
[0] https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
Can I tell you a perfect personality test that will always work and never fail? Absolutely not. Even the anti asshole processes don’t always work. But it seems a good thing that this sort of behavior is at least being described and reported on.
I guess it’s better, but the proof is in what the management team looks like.
> Just imagine what companies would look like if their hiring processes filtered out this kind of charlatan instead of looking for whether they could do some dumb coding card trick in a 45 minute interview block. I think they'd look very different, and a whole bunch of people would have to find another industry to prey upon.
I would caution against hoping for a personality test that could weed out the phonies, though. "Behavioral interviews" are strange enough already, in my opinion, even if their goal might be admirable (e.g. identify the assholes).
Anywhere there is money and prestige to be had, you can either keep things small or inevitably suffer the phonies.