Live data from Hacker News

Senior Developers Are Getting Rejected for Jobs

glenmccallum.com

181–190 of 384 posts

Re: Senior Developers Are Getting Rejected for Jobs

#181
post #3

This is seriously f'd up. When I was hired by IBM years ago, they also had a test called the IPAT (Initial Programming Aptitude Test) but, guess what?, there was no programming in it! Instead, the test was designed to see if one had the basic reasoning and logic skills which would be necessary to solve a wide variety of programming-related problems -- not one stupid, specific problem in a particular language. That's…

So basically, an IQ test. I believe these run into legal grey areas because they have to be obviously relevant to the job in question, which likely leads to the tests getting progressively more domain-specific as time goes on. Programming does seem to be a field in which general intelligence is a big predictor of success. Whereas a field like management probably personality and general intelligence are more equally w…

HR told me I couldn't ask such questions without proving they were useful first.

Basically a scientific experiment, have someone else ask and grade the questions, but those results were not considered for hire/nohire. Then 6 months after a bunch of people were hired we pull the results of the test and compare to their performance reviews. If the questions were a good predictor or future success we could use them on future interviews.

The overhead of this was more than we were willing to pay so we went back to HR's allowed questions.

Re: Senior Developers Are Getting Rejected for Jobs

#182
post #9

We need to admit that the interview process isn't about determining the relative qualifications of the applications in the pool, because we all know that 3 hours and whiteboard can't tell anything you need to know about whether or not that person will perform over the years. We need to acknowledge that we perform this pantomime in order to satisfy layers of management that are unable to accept that you can't hire for…

Absolutely untrue. Whiteboard problems absolutely do work. The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list. Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises. How, you ask? By using copy-paste and cleverly n…

> And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.

Seriously, Where are you finding these candidates? seriously.

I've worked at a number of mid-sized companies, and interviewed dozens of candidates, and I have never, ever, ever come across a candidate that couldn't write code on this level: "write a function that adds two numbers or counts the number of elements in a list".

Re: Senior Developers Are Getting Rejected for Jobs

#183
post #87

I interviewed ~500 people in a fairly large (~2000 devs) company. Interviews used to take about 6-8 hours of my week, and I was usually completely destroyed by the context switch. I remember many days when a deadline was very close, and I absolutely did not want to do the interview, but had to. In general some days I was in good mood, some in bad mood and even though I tried to make the interview as objective as poss…

I noticed that my job enjoyment took a hit during a period of heavy interviewing for new devs for all the reasons you mention.

A one hour interview required a minimum of 30 minutes prep to read the resume, etc and generate questions. Then at least 30 minutes to write up my findings in a way that would allow me to participate in the roundup, which could be up to a month away if I was the phone screen. The roundup itself accounted for at least another 30 minutes. So you were 2 hours and 30 minutes into it assuming everything goes perfectly. It's a huge time suck.

But beyond the time that I lost, it's a very difficult and crushing experience to have candidate fail and have to be the one that says "no" (and that is happening way way more than yes, especially if you are interviewing early in the pipeline). But it's equally disheartening to see a spark of something in an interview, tease it out, imagine that the person can be raised up to become a good developer only to have the candidate get shot down by all your colleagues because they didn't have a similar experience.

I disliked losing time during the day, but I really disliked the emotional burden of interviewing and saying "no." I empathize with the person on the other side as I've been there.

Re: Senior Developers Are Getting Rejected for Jobs

#184

I take a completely different approach to hiring, and I've gotten fantastic results. Instead of throwing tricky algorithm questions at a candidates, I scour their detailed employment records for the most relevant experience for the first project. In other words, I'm looking for relevant experience rather than top-of-the-head algorithmic brilliance. In the interview, I pose our project problem, and the candidate who g…

For our last hire, I was the only one on the hiring committee to ask about past projects. The others defaulted to "fundamentals" questions.

I think the reason people do this is a mix of 1) not knowing what traits to look for 2) not comfortable with unstructured conversation 3) frankly that it takes work to evaluate each resume and research projects enough to have a useful conversation.

For me though, how they achieve success at past work is the best indicator of future success.

Re: Senior Developers Are Getting Rejected for Jobs

#185

I take a completely different approach to hiring, and I've gotten fantastic results. Instead of throwing tricky algorithm questions at a candidates, I scour their detailed employment records for the most relevant experience for the first project. In other words, I'm looking for relevant experience rather than top-of-the-head algorithmic brilliance. In the interview, I pose our project problem, and the candidate who g…

Yeah this is the M.I.T. and Harvard "process". Hire success, instead of fostering success. Works well for small companies. If you need to hire 10.000 to 30.000 people a year, this approach is absolutely useless.

Also just because someone can't come up with the coolest solution for your project, doesn't mean they aren't good developers. This is even more biased than algorithmic interviews, because algorithmic interviews have structure. I actually CAN solve a puzzle in 20 mins. You definitely can not solve a project in 20 minutes or even an hour. It is impossible. And the best candidates will be those who sit back, analyze the problem for days or even weeks and come up with a good solution for your project. This approach is so infeasible for general interviewing that I don't even know where to begin. You are basically filtering out EVERYONE and take the one person who knew enough upfront to accidentially solve your problem best...

Re: Senior Developers Are Getting Rejected for Jobs

#186
Recently went through a process that had 5 hours of interviews, then a take-home (said 8 hours, took 16), then a full day on-site, then a reference check. Then not advanced with one sentence from a stranger ("We've decided not to move forward...") Asked for feedback nicely twice, no response, ghosted.

--

Been my experience with multiple SV startups now. In some cases went through back-channels to find out what happened (In one case - whole team loved you, CTO had your offer, CEO overrode at least minute and wanted a non-US contractor to avoid benefits pay)

--

Utterly absurd amounts of time and you still can't be sure!

--

My proposals -

#1) Companies that want take-home work or multiple day interview processes after initial screening /pay/ for them. You are already paying for your engineers to be inteviewing/etc. Pay the applicants. Keeps incentives aligned (you only advance ppl you really want to see how they work, you don't expect 40 hours + of work from me because I should feel blessed to get the opportunity to work for you...)

#2) More conversation. You can get way more ideas about someone's technical acumen by asking them how they know when to refactor, what they think about tradeoffs around technical debt, how they would think about data modelling something, etc than writing code. A brand new programmer maybe do some pairing, a person that has been writing production code for 3,5,10 years? Ask them the interesting questions and just talk!

#3) Hire quicker/Fire quicker - I think Riot for example will pay you money if you decide it isn't a good fit and you leave. Everyone is already employed at-will. I'd rather have a 3 month probationary period than try to find time for 40 hours of interviews while working my day job.

Re: Senior Developers Are Getting Rejected for Jobs

#187

I straight up refuse coding challenges. I code in the open on GitHub quite often and have built plenty of very high quality (and complex) web applications which I can go into intricate detail about. If your company can’t figure out I’m a good hire without having me jump through your hoops then your process is trash and I have no interest in working for you. In fact, I’ve been thinking how I would approach interviewin…

There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments and cannot talk about the projects they are working/worked on recently without violating contracts. Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily. They basically shut down. Doing the process you outline will optimize for talkers, and the indust…

> There are _tons_ of very good engineers who have spent the majority of their careers in extremely restrictive IP environments

Don't take those jobs if you want to be hireable I guess? You'd have to be joking to think a HackerRank quiz is going to help you glean any information about their expertise. Such expertise, by the way, is something I'd like to know about. Figure out a way to talk about it. Tell me the situation (you can't disclose real details) and then tell me about a hypothetical project with similar parameters in a way that doesn't break your contract. Or make up an imaginary project -- if you're actually a good programmer you can come up with something that sheds light on your technical ability and understanding.

> Further, there are _tons_ of very good engineers that cannot do 'a bit of show and tell' easily.

I'm sorry, soft skills are essential at my imaginary company. You need to be able to explain your thinking at an abstract level. I don't care if you can't do whiteboard problems, I get that - I can't either - but you do have to be able to walk through problems with other people. Especially problems that you know and understand well. If it's the interview environment that's the problem, well I'd like to informalize that process as well too so people don't feel so nervous about the whole thing. But if you can't explain a problem to somebody 1 on 1 then you'll probably be a very annoying person to work with.

> Doing the process you outline will optimize for talkers

It would optimize for "explainers", not "talkers". Talkers are usually people who can't explain something, and they're fairly easy to weed out from the people who actually know their stuff.

Re: Senior Developers Are Getting Rejected for Jobs

#188
post #76

Earlier quoted context omitted.

I've been on both sides of this. As an applicant, sometimes it's a crapshoot in terms of getting lucky that they asked me the right question. On the other hand, as a hiring manager or interviewer, I see lots and lots of candidates who can't write out a fizzbuzz solution, and it wastes a lot of my time (I'm a sucker and will take a lot of time guiding interviewees to the right solution, even on a simple problem when I…

> they shouldn't have to solve puzzle problems with "gotcha" solutions. I’ve never come across this myself, but I always figured that sort of interviewing would correct itself over time - if you ask questions that nobody is going to know the answer to, eventually when three years have gone by and you still haven’t hired anybody, you’re going to have to adjust your tactics.

There are different philosophies, but it comes down to how you want to balance type I and type II error, where:

Type I error == false positive == hiring someone who isn't qualified

Type II error == false negative == failing to hire someone who is qualified

I think a lot of companies are obsessed with minimizing Type I error. They really don't want to hire bad developers. As a hiring manager, your ass is on the line if you make too many of these mistakes (when your own manager asks, why are we paying 100k/year for someone who you are telling me isn't very good?). And perhaps you'll have to fire someone, which is painful for most people to do [0].

On the other hand, the costs of Type II error fly under the radar. Your manager comes to you and asks why haven't you hired anyone yet? "Well, I haven't found someone qualified yet" is the only answer you need to give. So it's easy to avoid culpability and it's harder to measure the costs associated with the work not getting done (generally, it's easy to measure a developer's cost, which is their salary + benefits + time they spend using others' time multiplied by those employees compensation. It's much harder to measure the value of their output in most cases, unless they are working alone on a revenue generating project.

I think there's a problem (at many companies) of people being held accountable for Type I but not Type II error. And so naturally, people worry more about Type I.

[0] On a tangential note, I had a boss once who made a good point to me. He encouraged me to take risks in hiring, but he said tgat the worst person to hire is someone who is mediocre. If someone is really bad, it's easier to fire them. If someone is really good, then everyone is happy. But if someone is bad, but not bad enough to fire, then they stick around and cause the most damage.

Re: Senior Developers Are Getting Rejected for Jobs

#189

Earlier quoted context omitted.

In your position, I’d take candidate 2. Displaying a reasonable level of competence and ability to work in a group is so much more crucial for a small company!

But now you did the mistake of assuming a lot of stuff, with very little data. Why can you say that person 2 is better at working in a group? Maybe person 1 was just very nervous, or is a type that takes a few days to warm up to new people. Maybe person 1 just crack jokes all day and is actually detrimental to the productivity. Impossible to tell from this one que alone.

You're always left with an imperfect amount of information after an interview. I don't think that means you should discount how well someone fits into a conversation given how important solid communication is.
Post reply on HN