We Can’t Hire You. Developers’ Challenge : programming

[-] MajorHavoc@lemmy.world 83 points 10 months ago

"When we decided to give the test to the development team (about 15 developers) — most of them got scores that were lower than our threshold (45%), despite them all being rock-solid developers. Also, there were some candidates who managed to get 95% and above — but would then just be absolutely awful during the interview — we would later discover that they were paying someone to complete the technical test on their behalf.

There is no substitute for taking the time to sit down and talk to someone."

That's pretty good advice. Interesting read.

[-] gravitas_deficiency@sh.itjust.works 36 points 10 months ago* (last edited 10 months ago)

Several years ago, there was a candidate who interviewed for a position on my team.

I and another colleague were the “discuss system design stuff for an hour” team. It became clearer as we spoke that the candidate knew barely a fraction of what they claimed, and pointedly flailed with absolute nonsense answers even when my colleague or I tried to throw them a line to get back on track - like, it was clear they had no idea what the concepts being discussed were. Moreover, after some pointed questioning, the candidate admitted that the systems she said she had built at a previous job were, in fact, largely set up by someone else, and that she had just made some changes after everything was initially set up. A few more pointed questions uncovered a handful of additional blatant misrepresentations, at which point we called that portion of the interview done.

As a result of these discoveries, I submitted written feedback for the candidate. We use a 1-5 rubric - “definitely not” through “holy fuck throw money at this person”, more or less. I gave the candidate a 0, and specified that we had caught them lying about significant aspects of their experience and knowledge, that the candidate essentially admitted as much when we presented them with the obvious incongruencies, and that that level of disingenuous behavior is at odds with not only our technical standards, but ethical ones as well.

Later, we all met to compare notes. Another dev pair evaluated the “take-home project” (which I took when I applied - it’s not that hard) and called it “perfect”. The thing is, we prescribe that you should be able to complete the exercise in a couple hours, and absolutely shouldn’t spend more than like 4-5 on it… but we don’t really track the time taken to do the thing. I am 100% confident that the candidate worked for DAYS on that fucker. Anyways: the chat with the manager, and the “culture fit” meeting apparently went well for them, and because the takehome exercise result was “excellent”, those engineers thought that the candidate would probably be great at cranking out tickets. I objected strongly and consistently in the clearest terms possible that we’d be setting ourselves up for failure by bringing this person in, and diminishing the overall effectiveness of the team.

My concerns were overruled. The candidate has been on my team since then, to my intense frustration. They have an apparent inability to understand normal git workflows, and insist on using a GUI that has created issues multiple times for the rest of the team. They are the specific reason why we tightened down all of our internal git project permissions from “you’re all devs, you know what you’re doing” to a minimal set of perms tightly scoped to our GitHub workflows. I have wasted weeks of development time un-fucking shit that this dev has broken. They are, by an order of magnitude, the most pain-in-the-ass member of the team, to the extent that even our manager has effectively siloed them off from the rest of us by mostly pointing this dev at peripheral busy tasks so that they don’t touch code that actually matters.

Before you ask: the person in question is a member of four protected categories, so they’re effectively un-fireable. I also found out about a year after the hire that they only even got the position they did because they needed visa sponsorship, and that title was the lowest level that corporate would do that for.

TL;DR: tests/project evals are absolute useful tools that can and often should contribute to a technical hiring decision. But they should NEVER be used as a basis for overriding conclusions reached from actual discussions, unless the technical challenge was executed in a fully-controlled environment (which I have done, and it was actually a much more pleasant process than I was worried it would be).

Edit: realizing that that was a bit of a rant, sorry. Guess I just needed to bitch for a moment about the deeply incompetent person at my work who consistently makes my job harder every time I have to interact with them.

[-] CodeBlooded@programming.dev 22 points 10 months ago* (last edited 10 months ago)

I feel your pain. I once worked at a place that hired an “expert” as a senior dev who asked me on the first day, “what is this import on the first line of this code??? I’ve never seen this before. 🤔” They were unfamiliar with the concept of packages and importing them… Senior dev, hired specifically because they were an expert in a specific language…

They’d call me upwards of 12 times a day for help with the most basic of tasks with anything technical, to include how to install the basic runtime to be able to run code in that language.

(I’m speaking quasi cryptically on purpose.)

[-] abhibeckert@lemmy.world 12 points 10 months ago* (last edited 10 months ago)

so they’re effectively un-fireable.

For me that's the biggest mistake your company is making.

I'm all for giving someone an opportunity if you think they might be good, and I'd be cautious accepting an individual's rejection, no matter how strong, since they could be wrong for any number of reasons... however you have to be able to fire someone especially early on in their employment.

If you've sponsored their visa, then (at least in my country) there are still ways to fire them. You just need to help them find a new more appropriate job - maybe even one inside the current company.

If someone is capable of "completing" a task by paying someone else to do it... then perhaps they have potential as a manager for example. Delegating tasks to other people is a real skill - and apparently an area your company is lacking (the most important ability is knowing who to give your task to... and they put this guy on your team! Wtf). Obviously don't start as a manager but maybe put them on that career track. Make him an assistant to a manager for example.

[-] gravitas_deficiency@sh.itjust.works 8 points 10 months ago* (last edited 10 months ago)

It wasn’t an individual’s rejection, though. My colleague who did the screen with me was 100% on the same page, and as far as I know provided a very similar response. We were just overruled because the assessment project we gave came back “good”.

Edit: to be more clear, it’s my pretty firm opinion at this point that the person in question is just straight up not a good engineer. They are:

they straight up do not listen. My colleagues and I have started 1) saying a thing 2) confirming comprehension by asking and then 3) confirming comprehension again by asking for a brief, very high level overview of what was just said. This person consistently just… doesn’t respond to step 3. I’m neurodivergent myself. This isn’t that. This is being a fucking idiot.
consistently and demonstrably unable to wrap their head around fairly basic git situations. I have tried at least a dozen times to express the importance of maintaining a clean and linear commit history on our working branches. I expect I will have to explain it again sometime soon. Along with how rebasing works. Or how the branch strategy of our projects are set up. Or to ask them, for the 87th time, to please fucking stop using whatever shitty git GUI client they’re using that often creates issues upstream for the rest of the team.
often brings up inapplicable or entirely irrelevant points in an attempt to look like they know something about anything
I know for a fact that at least one conversation I have had with them - in which I was genuinely trying to just point out some serious pitfalls they were about to run into - which was fundamentally misrepresented to the extent that I got pointed HR questions from my boss about the interaction. I am not the only person on the team they have tried this with.
as mentioned in my earlier comment, has repeatedly broken important shit in our stack and CI pipeline, and not only never fixes it, but doesn’t even say a fucking thing about it, even after it’s discovered, and it’s abundantly apparent that they broke the fucking thing. This generally causes a lot more work for myself or one of the other senior members of the team.

I have mentored people before, some very successfully. This person is un-mentorable. They are actively detrimental to our team overall. If I was in a position to do it, I’d immediately put them on a PIP for inability to perform their job as specified in their employment contract.

[-] JavaTheHutt@programming.dev 7 points 10 months ago

This person sounds like a future manager in the making. I've dealt with them in the past. If you're lucky, they'll somehow manage to find a better paying job elsewhere. More likely though is that if you want to get away from them you'll need to find a better paying job elsewhere, or change teams if possible.

To a certain extent, dealing with incompetent/adversarial colleagues can be a learning experience. You get better at designing/coding/communicating in a more idiot-proof fashion. But after a while it starts to hold you back as instead of being able grow, you instead have to stay behind and clean up after the others.

[-] SkyNTP@lemmy.ml 22 points 10 months ago

The job of HR is to manage employee needs, not to make business decisions, like what kind of employees are a good fit for a team. The moment HR gets involved with that decision making is the moment a poisonous cancer mestastatises and starts killing the company from within.

[-] intelisense@lemm.ee 38 points 10 months ago

HR is never about employee needs. Their role is to protect the interests of the business, especially with respect to employment law. I would argue that HR failed abysmally in this case, but not because it sucked for the hiring manager or the candidate, but because the business lost out on a talented individual and put the business at risk of a law suit.

[-] QuadriLiteral@programming.dev 5 points 10 months ago

It would be odd to not have HR involved in hiring imo. When I was hiring for my team I was happy HR was involved, I gauged technical ability + fit for the team, HR gauged general fit with the company. We'd then have a chat afterwards to compare and see whether we would move forward with the candidate, and honestly the opinions were always along the same lines. It took some of the responsibility off my back knowing that the candidate received the green light from an independent party as well.

[-] Blamemeta@lemm.ee 4 points 10 months ago

I would argue that HR has a very specific role in hiring, namely background checks and verifying that the resume matches reality.

[-] Nommer@lemmy.world 36 points 10 months ago

she later told me that I was anti-authoritarian and more likely to do what I thought was right rather than what I had been instructed to do. I am still baffled to this day about how that is an undesirable attribute

It isn't unless you're a corporation trying to keep employees down.

[-] ChairmanMeow@programming.dev 16 points 10 months ago

It is if you're the one trying to coordinate multiple product teams and one of them doesn't build to spec, introduces different behavior in edge cases or declares something to be "not their responsibility". Anti-authoritarianism is a bad trait to combine with "being wrong".

Someone who wasn't present during the design meetings, stakeholder calls, planning sessions etc... can absolutely still have very good input regarding decisions that were made. But they should raise those concerns with whoever made the final designs and discuss them, not decide on their own to deviate from the given instructions. They may not see the full picture and cause a ton of delays that way.

[-] bouh@lemmy.world 7 points 10 months ago

You are describing here someone who will get wrong and isn't able to work properly. If this is the kind of person you are looking to hire, then good for you, and your hiring process is perfect. But good employees will hate your company, because you consider them like bad ones. Many people will also end up acting like bad employees because that's how you consider them, so why should they bother?

This the problem with modern management and hr: it is hostile to employees.

[-] ChairmanMeow@programming.dev 2 points 10 months ago

Team coordination is now being hostile to employees?

Who do you prefer, someone who:

Thinks critically about his assignments
Communicates concerns with his coworkers
Can intelligently express his reasoning
Is open to being wrong
Helps improve a product

Or someone who:

Thinks critically about his assignments
Creates alternative designs that they feel are better
Builds those designs despite this not being instructed
Creates beautiful software, which ends up incompatible with the other software it needs to work with because they didn't consider various requirements from other stakeholders
Causes delays and frustration because their stuff, nice as it is, isn't to spec and needs to be rebuilt

You can be a brilliant developer and a terrible employee at the same time. If you want to design software as you like it, you should be in the design sessions. And not ignore the hard work those people already did and throw it out without discussion.

Anti-authoritarianism is a bad trait. Critical thinking and standing up for your ideas is not. I frequently question design decisions I have not made myself, because A) there could be something that was overlooked or B) I'm overlooking something and I don't have a full picture of the scope. Either should be resolved by a quick chat with the designers, not by me ignoring instructions and doing whatever I feel like is best.

Part of being a good developer is also accepting that you might be wrong and your ideas might be bad. That doesn't mix well with anti-authoritarianism.

[-] Senal@programming.dev 4 points 10 months ago

I'm talking anecdotally and from my experience here, not as an absolute.

I will upfront admit i am somewhat biased against authority in general, especially what i perceived to be unearned authority (if you wish to be a respected authority, earn it and continue to do so) In this case however I'm talking about "authority" in a professional sense somewhat measured against the success or failure of particular projects or initiatives.

For the most part i agree with you but it seems like you are using the term "anti-authoritarian" as an absolute, as in being against authority is bad in all cases.

At a lot of companies "Critical thinking and standing up for your ideas" is considered anti-authoritarian because the company culture doesn't allow for that kind of autonomy of thought (by design or long term evolution usually).

Your example works in the context of a company that works in a manner that promotes/encourage that kind of person, not all of them do. My personal experience and that of my circle of colleagues and acquaintances, I'd guess that percentage is around 30/70 with the 70% being companies that either actively or passively punish/discourage both of those types of employees.

Which i'd imagine is what @bouh meant when they said "But good employees will hate your company, because you consider them like bad ones"

Anti-authoritarianism is a bad trait. when the authority in question is doing the correct things (for whatever definition of correct you wish to use). "Anti-authoritarianism" and "Critical thinking and standing up for your ideas" are not mutually exclusive.

As with most things it's contextual.

[-] bouh@lemmy.world 1 points 10 months ago

You are completely missing the point. The problem is that you are considering employees to be the bad ones, and thus you are selecting them.

[-] Miaou@jlai.lu 4 points 10 months ago

If you're confusing "anti authoritarian" with "cannot work in a team", well that's extremely worrying. Don't engineers get introduced to ethics on the work place where you come from? "anti authoritarian" might as well mean "won't agree to do anything dangerous just because your boss told you to". Hence why the author refers to Millgram's.

[-] ChairmanMeow@programming.dev 1 points 10 months ago

Anti-authoritarian can lead to difficulties in coordination with other teams. I'm not saying it has to, but it can.

Not doing something unethical from a moral standpoint makes you a good person, but not necessarily a good employee. But in the vast majority of cases engineers aren't presented with morally dubious tasks.

Not doing what you're told because you think you know better is also anti-authoritarian, and definitely would be considered a bad trait to have for an employee.

[-] Miaou@jlai.lu 0 points 10 months ago

You have a legal obligation to refuse to do something unethical, so it depends whose definition of "good" you're looking at, the HR dep, or the engineering one.

Not doing what you're told because you think you know better still sounds better than blindly doing what you're told. Employees following instructions they don't understand, when talking about desk jobs, kills any motivation. Let them offer alternatives, and argue a bit. There's a difference between disagreeing and misunderstanding, and I bet the anti authoritarian crowd is more bothered by the latter than the former

[-] LwL@lemmy.world 1 points 10 months ago

Yea, that one point in the post doesn't necessarily make much sense (though this really depends on how the corresponding questions were phrased). Doing what you think is right over what you're told is good if it's a question of morals, it's not good if you're in a situation where you might not have the full picture. Though the correct thing to do when you're told to do something you don't agree with in this case would regardless be to bring it up and have a discussion about it.

[-] Potatos_are_not_friends@lemmy.world 33 points 10 months ago

One of the first things I did when I lead my department was tell HR that I want veto power to anybody they added to my team.

Rejected. They said they need to be in the loop.

I then said I want the power to help filter applications.

Rejected. They didn't want me to feel "burdened", and even when I said it's important, they rejected.

I went to the CTO to hire a handful engineers without HR approval. I needed them for a specific project, and going through HR would take weeks. He approved and we went above HR's stupid hiring process.

It's a endless battle against HR.

[-] signor@lemmy.world 11 points 10 months ago

They’re just trying to validate their position…by creating boatloads of bureaucracy.

[-] Slotos@feddit.nl 23 points 10 months ago

psychometric evaluation

Ah, the “I can’t justify my existence, so I’ll point at the machine” HR starting kit.

Remember, proprietary research is not science. And proprietary research is what these psychometric tests are based on, at best.

[-] stevecrox@kbin.social 20 points 10 months ago

I avoid any company that requires a software test before the interview.

I worked for a company that introduced them after I joined, I collected evidence all of the companies top performers wouldn't have joined since we all had multiple offers and having to do the test would put people off applying. The scores from it didn't correlate with interview results so it was being ignored by everyone. Still took 2 years to get rid of it.

The best place used STAR (Situation Task Action Result) based interviews. The goal was to ask questions until you got 2 stars.

I thought these were great because it was more varied and conversational but there was a comparable consistency accross interviewers.

You would inevitably get references to past work and you switch to asking a few questions about that. Since it was around a situation you would get more complete technical explanations (e.g. on that project I wrote an X and Y was really challenging because of Z).

I loved asking "Tell me about something your really proud off". Even a nervous junior would start opening up after that question.

After an hour interview you would end up with enough information you could compare them against the company gradings (junior, senior, etc..).

This was important because it changed the attitude of the interview. It wasn't a case of if the candidate would be a good senior dev for project X, but an assessment of the candidate. If they came out as a lead and we had a lead role, lets offer them that.

[-] watty@lemm.ee 18 points 10 months ago

Anyone who codenses candidates down to a "score" or a "number is doing it wrong.

[-] themusicman@lemmy.world 12 points 10 months ago

Hiring is literally condensing candidates down to a boolean

[-] alexdeathway@programming.dev 0 points 10 months ago

boolean at least give the option for false,here it is either you get hired(1) or no response(null),

You may consider null as false.

[-] sukhmel@programming.dev 7 points 10 months ago

"What's your mother tongue, is it JavaScript?"

[-] themusicman@lemmy.world 2 points 10 months ago

More like a promise that never rejects

[-] HairHeel@programming.dev 18 points 10 months ago

Also, there were some candidates who managed to get 95% and above — but would then just be absolutely awful during the interview — we would later discover that they were paying someone to complete the technical test on their behalf.

Yeah my company shot itself in the foot by replacing technical interviews with an online test and hiring a bunch of cheaters. After a while we started doing a zoom interview where we’d go over the code they supposedly wrote and ask them to explain it to us. Even that simple step made it obvious who had or hadn’t actually written the code they were talking about. I’m pretty sure a few candidates had somebody talking in one ear and/or typing to them on a separate screen.

[-] Rentlar@lemmy.ca 16 points 10 months ago

So the psychometric "analysis" test simply serves to put shade on any decision the interviewing team makes from upper management, and a cover for being borderline discriminatory?

[-] xmunk@sh.itjust.works 7 points 10 months ago

It's cute that you think the entire hiring process isn't entirely about avoiding discrimination lawsuits.

[-] lil_tank@lemmygrad.ml 11 points 10 months ago

Psychometric tests are the equivalent of healing crystals for corporate ghouls

[-] DroneRights@lemm.ee 7 points 10 months ago

Ah yes, the anti weird test. That's how you get all of the autistic people and POCs out of the recruitment pool.

[-] Miaou@jlai.lu -5 points 10 months ago

Ugh? Are you implying that every white person is a native English speaker, that non whites cannot be, or that they are unable to learn the language? Honestly your comment doesn't reflect good on you

Now don't misunderstand me, those personality tests are bullshit and HR is to employees what police are to citizens, but your take is bizarre to say the least

[-] DroneRights@lemm.ee 3 points 10 months ago

No, I'm not implying that, because that's ridiculous.

[-] BetterDev@programming.dev 1 points 10 months ago

I think it is simply saying that the named groups may get filtered out by this process, without making any claim regarding other groups.

[-] doeknius_gloek@feddit.de 1 points 10 months ago

A lot of other people who took the test got largely the same result as when they joined the company — my results had worsened (by the HR Manager’s standards) — she later told me that I was anti-authoritarian and more likely to do what I thought was right rather than what I had been instructed to do. [...]

She mentioned that my chances of securing the job upon re-interviewing at the company were slim due to my psychometric profile.

What a nice thing to say to one of your senior employees. HR people really are something else. They could've easily lost him that day because of some random bullshit.

Programming

Rules

Wormhole