Live data from Hacker News

The software industry's greatest sin: hiring

neilwithdata.com

431–440 of 590 posts

Re: The software industry's greatest sin: hiring

#431

Earlier quoted context omitted.

I have my doubts about your conclusions given your statements. It seems you have 3 steps in your interview process: code assessment, architecture assessment, and CTO interview. And the candidate who does well on all three gets the job? So, does your funnel filter to exactly one candidate every time? And if it does not, then what criterion are used to funnel all candidates who finished this process successfully? Perha…

In my experience, if there are multiple qualified candidates it usually comes down to things like who lives closest (so we don't have to pay to move them here)? Who was the most friendly/likeable? Who might have a skill that we might need in the future? Etc.

> to things like who lives closest

Yikes! You may want to review laws about hiring... immediately.

Re: The software industry's greatest sin: hiring

#432
Oddly, the more real experience you have diminishes your chance of being hired. You might recall how to 'invert a binary tree' had you recently graduated from college. But since inverting binary trees is an extremely rare need in the real world, you are doomed if you have significant experience.

Re: The software industry's greatest sin: hiring

#433
post #389

Tossing my 2c in the ring, this is how I usually hire new dudes[1]: - Ask the existing team for a set of dude recommendations, and the reasons. - Track down a set of dudes myself. Usually from publications, open source, or previous products. - Discuss with the dudes regarding the greater project target, team, goals, initial tasks, scheduling. Ask the dudes for other dudes they can recommend, and why. - From here on I…

> 1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye colour, and so on. In that case, s/dude/person/g Language affects thought, right?

Very true, my deviance. But words change meaning and connotations over time. For me "dude" is a blank placeholder. I should of course take more care to see my text from the eyes and mind of the target reader.

IIRC the 2004 bsg called everyone "sir" regardless of gender. I remember that nudged me the first and second time I heard it, but then it was just second nature. It had lost it's (for me) implied gender.

Re: The software industry's greatest sin: hiring

#434
post #187
post #91

Earlier quoted context omitted.

No, but I get to write real code at my job.

They're not the same. I've never used Dijkstra pathfinding at my work, but I and yet, I seem to asked questions about it in interviews pretty consistently.

The goal isn’t to make sure you have memorized a graph algorithm. The goal is to identity people who can convert a scoped problem definition to code and to identify people who can convert a vague problem definition to a scoped one.

This can be beaten by brute force by memorizing a huge amount of material, but that isn’t the goal. It isn’t like the interviewers think you’ll need to implement their question in your day job.

Re: The software industry's greatest sin: hiring

#435

Earlier quoted context omitted.

It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing. The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast…

> most tech companies heavily favor "top school" candidates and actively recruit for them Good job prospects upon graduation is one of the things that makes a school a "top school" and attracts smart students. If you wanted to hire people with no work experience, and money was no object, a "top school" would be the logical place to go to first. And I say this as someone who didn't go to a top school. So tech companie…

> You'd have to provide evidence for the first half of that statement though.

I've worked for 10 years and recently applied for a position. The manager told me I was a good candidate, and that I checked the box for coming from a top school.

He didn't use the phrase "checked the box" but did explicitly say that my coming from a top school meant he could skip most of the technical portion of the interview and just focus on the people aspect.

But for the most part I agree with you. It usually is important for the first job.

Re: The software industry's greatest sin: hiring

#436

I hire people from direct conversation that jumps around many subjects. My goal is to see the wheels turning, find what excites them, get the lights in their eyes shining. If I can’t do that in even 15 minutes, then I lose interest fast. If I can, an hour goes by in a flash and I really get to determine if they align with the role they’ve applied to. I could care less about data structures and graphs. Do they care ab…

Many companies get by with mediocre developers, mine is one of them. You're not demonstrating that your interviewing style generates superior results.

As a consultant, I’m almost exclusively on high pressure projects that require a higher level of talent.

I have zero problems hiring adequate talent if there are suitable roles.

Re: The software industry's greatest sin: hiring

#437
We use a 3 step process:

1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with

2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much time in days as they need, and let us know when you're done. The candidate then comes back and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not do criticize their style and approach.

3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization.

This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.

Re: The software industry's greatest sin: hiring

#438

Earlier quoted context omitted.

It is true that you can succeed well at tech companies without a degree from a top school. Class, race, gender, sexual orientation are not barriers to success. That's the positive thing. The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast…

One of my previous bosses (at a large tech company) moved over to the US and was asked to hire 9-10 people in a quarter. Everyone said it was impossible. She went to LinkedIn, found people with the right skills (strong data and ability to communicate), and had a massive fight with HR because none of the candidates came from "top" schools. She won the argument, and all of the hired candidates did a great job. People (…

This is curious given there are well documented findings that which school you attended doesn't correlate to actual success. This is true in Engineering and Law. The problem, particularly in the US, is that the skills that are tested by the standardized tests (SAT, LSAT) are NOT the skills that make someone good at the job that comes out at the end.

Re: The software industry's greatest sin: hiring

#439
Given HN's demographics, I'm probably older than most here. I've worked with and personally invented quite a few great products, usually spanning Product, UX, and Engineering work. It's a joke to pretend ageism isn't a thing, and asking questions that only a recent CS grad is going to remember is not a tacit form of filtering for age. There's not many technical questions a fairly smart, non-lazy person with some experience can't either find with a Google search, a conversation with a peer, or a bit of hacking to figure it out. It's been a LONG time since I had to write the code to invert a binary tree, but I've done stuff orders of magnitude more tricky and valuable than that countless times, as have many others. What makes a great engineer? I've lost count of how many times I've had to rewrite the code of many engineers who aced the 'whiteboard shuffle', then wrote hopelessly over-complex and unmaintainable garbage. Most of software engineering is not that hard from a 'learn the things or look them up to get stuff done' perspective. What's hard is working well with others and consistently emitting tight, semantic, legible code that's fun to look at and extend.

Re: The software industry's greatest sin: hiring

#440
post #189

Earlier quoted context omitted.

> So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know? Programming education is broken. I did one year of computer science at one of the top universities in the world (switched into mathematics after that), and I'd…

> What does the interview process look like for a craftsperson? Welcome to my shop. Here's some wood. Make a chair! In most of the interviews I conduct, I get the candidate to write follow a spec we've written and some code. And I get the candidate to debug a program with some failing unit tests. About half of the candidates I interview fresh out of school have no idea how to get started debugging a program they didn…

Both of your "taboo thoughts" seem blatantly obvious to me, and not especially taboo. Intelligence obviously exists and some people have more of it than others, even if the metric "IQ" doesn't perfectly capture it. And yeah, some people are not cut out to be programmers. Why are we pretending otherwise?
Post reply on HN