How do we define gatekeeping?
Posted by ninetofivedev@reddit | ExperiencedDevs | View on Reddit | 90 comments
So recently I made a post about a noticeable uptick in highly confident yet unskilled candidates, and a mob developed in the comment section to talk about gatekeeping and how I was a bad hiring manager for gatekeeping the position.
First, I need to clear things up that. I wasn't explicit enough and gave examples of candidates not knowing some information about tech stacks, and people thought that was short sighted or not an adequate measure of candidates strength.
The examples I gave were for Platform Engineer positions, not pure SWEs. It was also for staff level roles. Also I don't think I made our interview process explicit enough in the post.
I don't just start with asking trivia questions. I don't do leetcode. Instead, I do what I think most people prefer, and I give candidates an opportunity to talk about their experience.
I then relate their experience back to the role and them probing questions, most notably something like "Have you ever ran into this problem and if-so, how did you solve it?"
So if a candidate talks about their shift from EC2 to K8s and ephemeral environments, as someone who knows a lot about that process, I'm going to probe.
Now, I think the outcry from the comments about gatekeeping were mostly due to lost context. I know that a number of you are forced to work at the surface level with infrastructure and you don't have the depth of knowledge that a staff platform engineer should have. And many of you took that personally because you wouldn't have liked to been denied an opportunity for something that you feel shouldn't even be the main requirement for the job (and to be clear, it's not).
However, even when I clarified that, people still felt that I was interviewing poorly and that I was gatekeeping.
TLDR: Is expecting a candidate to have a deeper understanding of technical details during a technical deep dive interview gatekeeping? Am I really the crazy one?
lookmeat@reddit
I saw the original thread, and honestly saw where people were coming from, but also reading what you said a bit more carefully I wasn't convinced there was gatekeeping.
Let us understand what is gatekeeping in the hiring process. It is the presumption that your job is to filter out bad candidates during the key filters in an interview, that is that each filter (be it resume selection, interviews, etc.) the goal is to identify bad candidates and then filter them out.
But think about it: what happens if a candidate refuses to interview? Do they get the job? Well no, which means it's impossible to get the job without an interview. This means that the interview is supposed to be a positive filter, that is it's supposed to make it easy to identify and push the candidates that have the highest potential.
So, when putting an interview, the goal isn't to "lets prove if this guy is a good or bad candidate". Realize they are a "bad candidate by default" and what you want to do is "find out if this person is actually a good candidate". The goal is to get the most information and make the best (honest) case possible for them to be hired. If they are a weak candidate the case shown will not be great. At the same time you want all candidates to really want to get the job, because you want to make sure that the good candidates are excited about it. "But I'm supposed to say strong hire or no hire at the end", yeah you basically want to answer the question "after talking with this guy I really want to work with him" or "I would reconsider staying around if I had to work with this person", because that's an important metric (you don't want to bring an asshole), but for the interview you just get the information, make the best case for them, and go on.
And what is the problem with gatekeeping? Couldn't it work? Badly. You end up filtering candidates because they don't satisfy your biases, more often than not. Filtering candidates on "not being good enough" leads to this. You throw them out because they didn't match your culture, or weren't smart the way you are smart, or worse yet, are smart in a way that you just don't get and could make you feel dumb. To say "that never happens to me" doesn't signal you are a good interviewer who handles this, but rather one who refuses to acknowledge the issue, let alone handle it. We all have these things, and we must all deal with it.
So the question is: did you commit gatekeeping? I can't say, I don't see evidence that you did, but there are some red flags that hint it may be happening. And there seem to be some issues on attitude on how you describe things that show a bias towards that. But honestly it sounds like there may be a problem with your pipeline. Maybe the job is being misunderstood, maybe the recruiters don't understand the profile correctly. And yeah, maybe at one stage or another there's gatekeeping that is happening that is filtering out candidates with minor nits but good foundations for platform engineering, but is letting the bullshitters (that know how to hide this minor things) to pass through. If candidates were about showing the most strengths rather than the least weaknesses, this could fix the issue. Or maybe there's something else. The market is rough and maybe we're seeing more engineers be willing to interview for jobs far outside of their comfort zone. If they got recently laid off they have nothing to lose: they either find out that the job is actually a solid match, or they get good interview practice to prepare for when they are interviewing for a role that is a good match.
Proper_Product_3376@reddit
Sounds like my ideal interview tbh.
liminalbrit@reddit
Don't listen to the cry babies. Hire the person you need.
ninetofivedev@reddit (OP)
It was very pervasive. If it was just one or two commenters, I wouldn't have thought twice about it, but the entire comment section was mostly outcry.
gjionergqwebrlkbjg@reddit
This subreddit is heavily skewed towards people with barely any experience, the people who had to lead a larger project, or who had to build a team, are a tiny minority.
Sunstorm84@reddit
Subreddit name does not check out
MoreHuman_ThanHuman@reddit
What's in a name? That which we call a rose, by any other name would smell as sweet
VictoryMotel@reddit
Hidden post history bot
MoreHuman_ThanHuman@reddit
if I can't cyberstalk a stranger I disagree with they must be a bot
VictoryMotel@reddit
Am I cyber stalking you by reading your public post right now?
ninetofivedev@reddit (OP)
Man people really hate Shakespeare I guess
nextnode@reddit
Do not know the context of those comments but OP does come off as overindexing on specifics that they care about rather than complementing or answering what is required for the company and the function's success.
gjionergqwebrlkbjg@reddit
If you are looking for a person to lead in context of platform teams, they better fucking know how platforms work.
nextnode@reddit
Meaning what? People do not memorize everything. You look it up when it is needed. What is important is more conceptual.
gjionergqwebrlkbjg@reddit
If somebody doesn't know a concept of a firewall, they have zero fundamentals.
nextnode@reddit
Even my grandmother knows what a firewall is so I do not think you are expressing yourself well now.
gjionergqwebrlkbjg@reddit
One of the examples the OP gave in the original thread was somebody having no idea what security groups are (the fundamental kind of firewall).
nextnode@reddit
So that is precisely the problem with this - you try to invoke a basic concept and then you want to add on arbitrary expectations with trivia at a depth tuned to some level that you are familiar with.
It is a common thing that people move between different cloud platforms. Learning the specific concepts from one to the other is quick and not the limiting factor. There are much more valuable interesting decisions and understanding that is important to the success of the company.
Also for a lead, it is perfectly fine and you should delegate. It is fine to say that you do not know exactly how the horizontal scaling is set up but the team has it covered with a plan for upcoming requirements.
gjionergqwebrlkbjg@reddit
They were asking somebody with AWS experience what a fundamental AWS concept is, in context of explaining the project they worked on.
You also can't delegate if you yourself are completely incompetent, that's what TPMs do.
nextnode@reddit
Perhaps in the particular case you mention it starts becoming a reasonable expectation. Though if pushed, I suspect that you will do the same - go from knowing about security groups to now start piling on trivia expectations regarding them and conflating "not knowing about" with "not knowing" with some pattern matching against your own focus. Eg labeling it as "not knowing what a firewall is" is precisely that kind of red flag.
A CTO deleges pretty much everything and if you think they are incompetent, you should probably find a company you believe in.
That does not seem like a very mature statement at all. If you have worked in the industry, you know that most things have a similar shape. You can tell roughly how a new framework works even without even using it, or what shape a solution likely takes in each area even without having seem the specifics. You should have learned countless systems, frameworks, languages, challenges. I think experienced people have confidence in learning and figuring it out as needed, not that everything is fresh in your mind.
You can delegate when you know the shape of the requirements and you can get involved when it is needed to the depth that is required.
ninetofivedev@reddit (OP)
You’ve created an imaginary scenario and an imaginary person and now you’re arguing with them.
Because nothing you’ve said in this entire thread applies to the situation I described.
This was a person claiming they did something and then couldn’t explain how they did it.
It’s no deeper than that. They were lying about their experience.
Move along.
annoying_cyclist@reddit
It's kind of a trend with interview posts here. If you describe a process that is more than a low stakes high level conversation that ends with a smile, handshake, and job offer, you'll get a big peanut gallery telling you how stupid your process is, how you're wasting the candidate's time with trivia, how they'd be able to weed out people who can't hack it with a 15 minute non technical conversation, etc.
My experience is that people who can reliably evaluate technical competence from a breezy non technical conversation are far rarer than people who think they can, that the latter group will end up making a lot of personality hires if left unchecked, and that organizations with deep technical panels tend to have stronger engineering teams and less dead weigth than places that don't go deep and focus more on vibes or high level stuff. Personally, both as an IC and a TL, I prefer working on strong engineering teams where I can count on my coworkers to be great at what they do, so I tend to favor hiring processes with technical panels and am pretty unapologetic about including them as an interviewer.
scodagama1@reddit
So look around the average staff engineer bar - average mid level engineer probably filters out 80% of candidates. Staff engineer filters out 95%
That's 20 to 1 ratio. So of course you will see the rejected 19 complaining that the bar is too high and the club too exclusive and blah blah. People rejected from the club complaining the club is too hard to join, duh
These are not $60k jobs, these are often $300k+ jobs - it's perfectly fine to be extremely selective. Just think how much damage can a bad staff engineer generate - setting aside lost opportunity they can literally be a difference between making millions on a product and shutting it down early
MoreHuman_ThanHuman@reddit
this industry is full of babies.
coderstephen@reddit
Yep. As a hiring manager, gatekeeping is literally your job. No one is entitled the position.
Inner_Butterfly1991@reddit
And if they want to become gatekeepers, it's never been easier to found a startup.
lordbrocktree1@reddit
Yep, I have a team to think about. 12 people, ranging from new grads to 15 YoE. I as the tech lead have to make sure that a new hire is a positive contribution to our team. I have 12 people’s livelihoods in my hands. I have to justify headcount, I have to make sure we are producing enough that we keep the department afloat. Hiring someone who can’t hack it is going to put that at risk, the rest of the team will have to burn out to cover for their work, we will look more expensive on budget sheets and be more at risk etc.
Maybe it’s gate keeping, but it’s also ensuring my team has jobs and aren’t overworked. I’ll gatekeep all day if I have to.
engineered_academic@reddit
I always remind candidates during interviews that deep-diving technical trivia topics during an interview is stressful and it's ok if they don't remember - they can tell me how they would find the answer. I do not keep kubectl commands memorized. Instead I ask them about qualitative tradeoffs based on their resume and other things they mention during the interview. Why did you choose to create a whole separate cluster instead of using a namespace? etc etc.
ninetofivedev@reddit (OP)
Yeah, I think maybe that was lost in the context of the post too. It wasn't a deep dive into commands or terminology.
Ie, if I asked the candidate how the went about autoscaling and they couldn't recall the exact AWS terminology or platform that they used, that doesn't matter as long as they can describe the context.
However the other side of this: How do you deal with bullshit artists? Because there are people who sit in enough standups to pick up concepts through osmosis, but they would have no clue when it comes down to actually why decisions were made or how to execute, and it's important to filter those people out.
crabby135@reddit
Honestly kinda really strongly disagree with this, maybe because I see myself in it. This is obviously level dependent and would likely only apply to lower levels, but I’ve dealt with enough juniors and mid level devs that cannot absorb anything they don’t directly interact with that id see this as a positive. Sometimes people aren’t given the opportunity to take a step up in responsibility, but I feel like this would be a good indication that they may be worth a shot.
Probably doesnt really apply to senior people and definitely does to staff and beyond, which admittedly it seems like you are recruiting more of as opposed to the lower end of the level of experience spectrum.
jmking@reddit
This is a very valid point.
When someone parrots a problem scenario, how it was diagnosed, and how it was solved that they weren't actually involved in, the easy way to surface that is to simply ask "what lessons did you take away from that experience? How have you applied those lessons?"
That requires actual legitimate knowledge of HOW the problem happened, not just WHAT happened.
engineered_academic@reddit
I've found I just have pretty good intuition in dealing with bullshit artists. Everyone I have interviewed and hired has been solid. I generally don't focus on the what was implemented and more of the why. Like everyone does a kubernetes cluster, but why did you use a service mesh here? Why did you choose to use Bazel, did you encounter any issues with its complexity? (anyone who says no here is a dirty dirty liar).
tatsontatsontats@reddit
'Experienced' as defined by the sub rules is 3+ years as a dev....that's solely time in chair and not actual experience so YMMV on the responses you'll get. I wouldn't really consider 3+ years inherently experienced, I've known people still writing junior level code for longer than that.
coderstephen@reddit
Yeah, I would describe "experienced" as 10+ years. And even then, people can coast for 10 years and not learn anything, so that's no guarantee.
kani_kani_katoa@reddit
My coworkers have discussed this a lot. You could possibly have someone producing senior+ quality work after 5 years, just as much as you can have someone still at the intermediate level after 10 years. I'm of the opinion that true "senior after 5 years exp" people are as rare as hen's teeth, and that you really need more time working with the consequences of your decisions to actually be a senior engineer.
Then again, I seem to have a higher bar for engineers overall compared with the rest of the industry so maybe I'm wrong 🤷
LoaderD@reddit
Most people who lurk here also aren’t meeting that 3 years bar. So they read something true that hurts their feelings and instantly downvote bomb it.
ninetofivedev@reddit (OP)
Right. That rule only exists to combat a wave of posts about internships and first jobs.
When you understand the historical context of this sub, which is that cscareerquestions is overrun by 18-22 year olds, it makes more sense.
I don’t think anyone actually considers someone with 3 years of experience to be an experience engineer. But we don’t really need an explicit definition for this sub.
throwaway_0x90@reddit
Well clearly the mods of this sub think 3 years is enough to be an "experienced engineer".
lokaaarrr@reddit
One year of experience, three times
Heavy-Focus-1964@reddit
i hate that word so much. some gates need to be kept
Fluffatron_UK@reddit
This is just a selfish rant because some people disagreed with you on the internet. All of your paragraphs except 1 start with "I". It's all about YOU!
> So recently I ...
> First, I ...
> The examples I ...
> I don't ...
> I then ...
> Now, I...
This isn't a gate about gatekeeping. It it a self-indulgent rant because you thought people who were mean about your other post are wrong.
illustrious_feijoa@reddit
Agree, this is weird. I don't even have an issue with how OP interviews, but they need to just move on.
eubeez@reddit
This should be top comment. OP is fishing for validation after being criticized.
Zenictetus@reddit
Haha, you got dunked on in the other post so you made another one to soothe your ego.
shaileenshah@reddit
Gatekeeping = blocking candidates with arbitrary, inflated, or irrelevant requirements (trivia, pedigree, “must have done it our exact way”).
What you’re describing—probing real experience and depth for a staff platform role—isn’t gatekeeping if that depth is actually required and you’re testing understanding, not just specific tool exposure.
canihaveanapplepie@reddit
Someone who can't talk through security groups and service accounts in the context of work they had done in AWS/k8s, you would be negligent to hire them for the role described.
That isn't trivia, but fundamental knowledge required for the role.
Anyway, the job of a hiring interviewer is literally gatekeeping. Being accused of doing that means you're probably doing your job correctly to some extent.
LoaderD@reddit
I came into the thread expecting a bad take. You’re right though. I think a lot of it is social media and AI. I attend a lot of meetups, conferences and the sheer number of people with one ML class where they recreated 2-3 youtube tutorials, claiming to be “AI experts” has at least 10x’d since covid.
It’s hard to doubt yourself when you spend most of your time on tiktok where calling someone an idiot gets you an account band and chatting with chatgpt which is RLHF trained to be agreeable and hype the user up.
PopularBroccoli@reddit
Software engineering really needs some well recognised professional certifications. Other equivalent professions have them to avoid this nonsense
Material-Smile7398@reddit
I agree, but we can't even agree on what framework to use, and management seem to rarely care about code quality. The certs would help dev's not have to work with bad code, but alas we don't control the narrative here
PopularBroccoli@reddit
Thank you!
EmberQuill@reddit
The lack of context certainly hurt a bit, but I think some people just took issue with the tone of your post, rather than its content. You commanded your audience to "listen" twice, only to give vague and somewhat contentious advice (be confident but don't tell them what you think about AI).
Listen, that comes off as somewhat condescending and adversarial.
...See?
Anyway, you were complaining about the smug candidates who didn't have the knowledge to back up their confidence, but in doing so you sounded kind of smug yourself. Add that to the bias people have against hiring managers around here and you end up with some rather heated comments on your post.
flagbearer223@reddit
I might sound like a dick here, but I don't understand all of the complaining on here about struggles with interviews and getting jobs. I've seen it since I entered the industry over a decade ago - always complaints about it being too hard to interview, algorithms filtering out resumes, etc. Maybe I underestimate how good of a dev I am, but I've gotten offers from like 80% of the companies that have ended up interviewing me. My assumption is just that it's selection bias
Material-Smile7398@reddit
I've failed plenty of interviews but have never had a real problem getting a job after a few weeks of trying. I'd consider myself good engineer, but Interviews are hard, you have no control over the mindset of the interviewer, or his/her motivations (do they want someone to be better than them, or just do their tickets and not make a fuss etc etc)
Not to mention that when you have to look at a brand new codebase, with people watching you work, that's not easy.
BoringBuilding@reddit
If you don’t understand it I would encourage you to actually read into more of them and reflect on why there may be so many types of those posts. Maybe broaden your horizons to think of things like anxiety/ADHD/etc that are very common in the industry.
By the way, I am not saying anything needs to change wrt interviews. But it seems astoundingly ignorant to be surprised that a certain amount of people are going to struggle with the common tech interview formats.
Congrats on an 80% offer rate though, it is exceptionally high. You definitely shouldn’t overextend that claim to being a good engineer though. I have hired great interviewees who absolutely crushed algorithms that were complete dogshit at the actual work of SWE.
Tired__Dev@reddit
I’m a true believer of Conway’s law. A lot of what good software engineering is is a social construct that exists on a per organization basis. The questions you select are based on that. At one point or another there’s just no way to ask a proper question and vet who has ability or not without pedigree or bias coming into play. The biggest problem in tech hiring is that we don’t have networking, well at least where I am doesn’t, meetings anymore.
It’s pretty much why I’m personally fucked if I get fired. I’ll be forced to do a startup.
Material-Smile7398@reddit
What are you stuck working on?
Material-Smile7398@reddit
I browsed some of the thread, and I'm going to side with you on this one, explaining that they only saw the end product of someone else's AWS setup or whatever it may be is way more desirable that trying to hand wave the technical details away. That just starts off with distrust, what else are they going to pretend to be experts in?
It's true that most places will have a platform engineering team to look after the AWS environments so the chances to really learn are limited, but I'd be looking for problem solving and design thought processes, and most importantly, attitude.
AWS can be learned if someone has the aptitude and is curious enough.
mq2thez@reddit
I’ve been giving Technical Deep Dive as an interviewer almost once a week for more than a decade, at some very large companies whose names you know. That’s not intended to be bragging, just context.
All of the places I’ve given this question, follow up like what you’re talking about was specifically on the rubric, and the candidate’s ability to talk about this stuff (and deeper knowledge) were specifically part of what we were evaluating. This is extremely reasonable as a way to evaluate whether someone had a senior level understanding of the problems and solutions, or a staff+ level understanding.
From a “meta” POV, a lot of folks I interview pick shite projects for this. They focus on the biggest thing they’ve done or the most recent thing they’ve done, rather than the thing which best presents their skills and knowledge. I recently interviewed a candidate who talked energetically about how they’d been given room to research and prototype a number of options for how to achieve a technical migration for software on specific hardware as part of a larger and critical migration. They’d spent tons of time and effort on it, gotten the proposal through technical review, etc… and the whole thing they’d proposed had been deeply, deeply flawed. Like, to the point where I couldn’t control my facial expression when they said what they’d proposed. When I started asking probing questions, they continued talking about the project and… admittedly that their solution had been so problematic that the whole architecture had to be re-envisioned and (related to other problems as well) the huge planned migration had been delayed an entire quarter. The failures were many layers deep, too — all of the research had been done not on the embedded hardware but on a desktop computer.
Why, in a technical deep dive, would you pick a project where you’d completely fucked it? The candidate was able to iterate their way through things, but the eventual solution was a big set of changes. When I tried to figure out what they’d learned or what they’d do differently the next time, they couldn’t really point to much, either, despite me (almost desperately) hinting about several possible options.
The rubric for us is clear — in addition to everything else, I’m required to evaluate the quality of the technical solution. If it’s such a problem that I’m visibly wincing when the candidate describes it, yikes.
And again, from that “meta” POV? By choosing a project this poorly, the candidate unfortunately demonstrated that they weren’t a good fit for the role. Everyone fucks up and everyone learns, but if you can’t find a good project to demonstrate your staff level skills, you can’t get staff level roles.
caprisunkraftfoods@reddit
It's not even like you couldn't use this as a good story. I've got a couple stock examples like this from early in my career that I pull out for the inevitable "can you talk about a time you were wrong?" questions. The fact that I can go through it, explain my thinking at the time, and what lessons I subsequently learned from (and other examples where I applied them) usually goes down pretty well.
jmking@reddit
...but... all hiring is literally gatekeeping. That's literally the task.
As the hiring manager it's your prerogative to do so with whatever expectations or standards you want.
You'll end up hiring whoever you believe fits regardless, and the consequences (positive and/or negative) of that decision are yours to own.
ninetofivedev@reddit (OP)
I would say that it's likely. I'm not expecting everyone to run into the same problems. I'm expecting most of us run into similar problems.
jmking@reddit
Heh, I would start a conversation on that topic by arguing that implementing graphql was the mistake to begin with for reasons exactly like the N+1 problem among numerous others.
But if that would be a conversation that you would find would surface useful signal in hiring, then you're not doing anything wrong. It sounds like you're running into the problem in trying to explain your point by sharing how you start the conversation versus what the motivation is behind the question.
The specifics of the question aren't relevant so much as why you're starting to probe with that particular example question. Without context of how the conversation got you to the point of asking that question and without the context of what happened when you did, people aren't going to get it. Does that make sense?
Background-Deal-5391@reddit
Man just do whatever you want to.follow your instincts
liquidpele@reddit
Yea, frankly Reddit is full of low skill workers who will say anything to support easy hiring and more visas.
Idea-Aggressive@reddit
Totally fine! And much better than leetcode. And humble of you asking since you probably listened to people criticism
Spider_pig448@reddit
Low-effort post. OP is just fishing for compliments after having his feathers ruffled by a few people on another post. Not the type of content we should expect here.
Alone-Method-4537@reddit
nah this isn’t gatekeeping, it’s just matching expectations to the role, staff level platform roles should require depth, especially if you’re probing based on their own experience and not random trivia i think people reacted to the idea, not your actual process, there’s a difference between filtering unfairly and checking if someone can actually operate at that level if anything, your approach sounds more fair than most interviews
kingduqc@reddit
Interviews are literally a gate keeping exercise, I'm a bit worried that you get pushback. There's ways to do it well for sure, from what I've read you seem to be doing a good job.
In our domain it's impossible to know everything, you probe around areas where you have experience and where the candidates claim they do. I think that's a very reasonable approach.
MattDTO@reddit
Hiring is the opposite of gatekeeping. You're literally trying to bring someone onboard! It's fair to expect depth of knowledge in the tech stack at lead engineer roles or higher.
aidencoder@reddit
I'd argue hiring is an act of discrimination and gatekeeping. Rightly so. You want to select the best candidate by discriminating against those that aren't as good. That's how the world works.
BitNumerous5302@reddit
Arguing semantics never helped anybody. If you need to examine and redefine a word to defend yourself from it, there's probably something you're having a hard time accepting about the common sense usage of the word as it applies to you.
Looking at your original post, it sounds like you don't know what a platform engineer should really be responsible at the staff level and have decided to cover by asking overly-specific AWS trivia questions.
AWS is big, sprawling, and well-documented. The odd engineer who has it mostly memorized will be hard to find and will save little effort, because the references are right there.
Instead, you're discounting "high-level" or "abstract" thinking when the interviewer can't explain it to you in the specific handful of AWS terms you understand. This will be bad for your organization in ways you will likely also discount and refuse to understand: You'll be hiring staff platform engineers who are great at listing puzzle pieces but know nothing about putting it together.
Let's say that it was in your business's interest to migrate to GCP or Azure. Same high-level abstractions, different details. Would you know how to distinguish an engineer who could conduct this migration from one who couldn't?
gjionergqwebrlkbjg@reddit
We were talking about security groups. That's as if somebody was claiming to know english, but couldn't say "Hi, my name is BigNumerous5302".
ninetofivedev@reddit (OP)
I think you could have come up with a better analogy, but I agree with your premise.
gjionergqwebrlkbjg@reddit
Then let's say it's like frontend engineer not knowing what CSS is. Networking is the core domain on platform teams.
corny_horse@reddit
I didn't have time to comment on it but I also have now ran several platform teams and this isn't a new problem and no, you are 100% NOT gatekeeping. I would absolutely expect a staff level platform engineer to be able to explain, you know, the platform.
stikves@reddit
There are two different possible views to look at an "opening"
1 - From candidate's point of view it is a doorway to a paycheck
2 - From hiring manager's point of view, it is an opportunity to find someone to get things done
The ideal is somewhere in between. Focusing only on "can you start contributing on day one" harms the industry. But if the candidate clearly requires many months of catching up (or possibly never), then hiring them is just taking away an opportunity from someone who actually deserves.
My heuristic is:
"Are they 80% of the way there?"
aidencoder@reddit
If I'm hirinf a junior, I'm hiring them to teach and develop them. If I'm hiring a senior, they best be a day 1 value contributor.
ninetofivedev@reddit (OP)
My goal is to build strong teams. I tend to develop connections with my team members that live longer than the job. I know for a fact what bringing on dead weight does for the morale of the team.
It's basically the same group project behavior you have in college. You want 3-4 other members on the team who you can count on, who you think fill technical gaps.
Juniors are the exception. Everyone (should) understand the value of mentoring the next generation of engineers and nobody tends to get bummed out over someone making half their salary not being on the same level as them.
However when you bring in a staff level engineer and that person doesn't know the craft, it will tank your team and you will lose good engineers.
I personally don't even like to do this unless there is nobody on the team who doesn't deserve the promotion. But sometimes nepotism creeps in and your director forces you to interview someone with the expectation to hire them.
aidencoder@reddit
Hiring is an act of gatekeeping. Otherwise we would all just hire the first candidate to email a CV.
We should gatekeep. That's how the entire world filters skilled people from "fake it until you make it" con artists. People need thicker skin.
UniqueCod69@reddit
im not telling you
TheOwlHypothesis@reddit
Hey, I'm a platform engineer and I just got a new job (staff level!) so I'm in a great position to comment lmao.
You did nothing wrong at all. Platform Engineers should be some of the most capable engineers in the org. I might be biased but yeah this isn't a normal position
TonyNickels@reddit
Interviewing a candidate is not gatekeeping, it's simply finding a qualified candidate.
Which-World-6533@reddit
The thing to remember is that anyone can open a Reddit account and post an opinion. It's why Reddit is wrong on about 99% of everything.
I would be more worried by Redditors telling me I'm doing the right thing than the wrong thing.
If something works for you, keep doing it.
PrestigiousStrike779@reddit
Candidates should be honest in their experience. If they’ve only worked in one aspect of K8s and they weren’t involved in the setup or configuration of it, they should state that, not try and BS their way through and appear as if they know what they don’t know.
BOSS_OF_THE_INTERNET@reddit
In a world where the number of candidates vastly outnumber the roles available, I think calling being selective “gatekeeping” is a bit rich.
I think it’s actually OK to require X yoe, and none of this “I’m a software engineer, I can learn anything” nonsense. I don’t want someone who can pick up a skill. I want someone who is a subject matter expert. Someone who can teach me a thing or two about the work I’ve been doing for the last 20 years. Someone who’s already seen all the pitfalls, and knows not to repeat them.
Maybe I’m biased because I’m at the tail end of this career, but I’ve been burned too many times by this idea that being smart and eager is enough. Sometimes, the years of muscle memory outweigh your enthusiasm.
Ok_Slide4905@reddit
You’re a hiring manager so that immediately put you in an adversarial position with your audience regardless of the substance of your post.
People come to Reddit to gripe and complain about hiring and interviews. This sub is frequented by juniors and students who LARP as experienced devs. So your post was an opportunity to dogpile on a common foil.
I have used the internet mob mentality before when I want to verify an idea.
For example, I will take on the tone of a “junior engineer who knows better than a senior” — this is common trope and foil in engineering. I will challenge some idea of an unknown senior (the one I authentically hold). Then the mob will rush in to defend the unknown senior because they’re triggered by my character. This works almost every single time I’ve done it.
MoreHuman_ThanHuman@reddit
the underskilled and self-entitled have a lot of opinions about gatekeeping. they believe they can do anything if someone just pays them and dedicatesresources to show them how. ignore them.
gjionergqwebrlkbjg@reddit
In this subreddit no matter what your interview process is, people will bitch and moan about it.
mpanase@reddit
Some people define gatekeeping as not just letting everybody in.
I think they are wrong, and they just are being facetious by purposefully confusing "gatekeeping" with "selecting (people who have the required knowledge)".
Let them "not gatekeep" and hire all the guys with no knowledge and plenty confidence. You take the ones with actual knowledge.
hojimbo@reddit
You don’t have to apologize to strangers on the internet for doing conducting your interview process however you see fit. Even if you were asking Leetcode and “trivia” questions, that’s your prerogative. None of us like it, no one ever has, but it’s also been the game of tech hiring for a long time now, and it’s a predictable and winnable one.
Tech hiring has gotten harder. So has building software in general. I think that underlies some of the frustration of folks around here. We’re expected to be QA, platform, infra, sysadmin, ops, deal with distributed systems, concurrent software, 12 different database systems, 90 different cloud components, strong in at least one cloud platform, fronted, backend, god-forbid-you’re-not-using-AI, system architect, algorithm guru, etc.
20 years ago, these might all have been separate jobs. And I know some experienced folks who are finding that the job they’ve been doing for the past 8 years straight didn’t prepare them for the modern job hunt.
Our field has also become accustomed to some bigger Silicon Valley salaries. Why would people want to work writing actuarial software for some Midwest insurance firm for $115k annually when they can be earning 4x+ that at one of the big shops. Except the big shops have 1,000 - 10,000 applicants per job, so demand drives up the expectations of the interview into ridiculous areas. There are a lot of people here who feel like they should be entitled to one of those jobs and that “the people who can remember the trivia” are “unfairly” taking from them.
So no, you do you. It’s your job to hire for, hire the candidate you want and interview them for the knowledge you think they should have. No, it’s not unreasonable for them to have deep technical knowledge if you’re hiring for a role that requires deep technical knowledge.