Hacker News new | ask | show | jobs
by dinp 971 days ago
In case the founders read this post: what would you do differently if you could start over and would this idea work today?

Slightly OT: everyone feels hiring is broken, can you list some things that are annoying from the employee and employer perspective? Here are some points:

- the process often stretches out over weeks and often months

- job posts often get 100s of applications, a lot are low effort applications, it just muddies the water for both sides

- ATS systems/job boards are annoying with the need to create an account on many sites, some forms have more than 20 questions, often asking what's already there in the resume.

A question to everyone: What would a good application process look like? For me, it should just solve the above mentioned problems. I send an email with my resume, a few sentences about why I might be a good fit for the role/what interests me about the company. The jobs@<company>.com email address could be linked to some Saas product which makes it easy for the employer to go through the applications and further communication about video calls or take home assignments or whatever are all in this email thread. The employer can set the stage of the application such as 2/5 or whatever, they can mark it as rejected or accepted after all rounds to trigger automated emails etc. Is there any Saas like this? (I can build this in a week if it doesn't exist, but no clue how to market it/get users, any pointers in case me or someone else builds this?)

5 comments

You're describing basically every ATS (applicant tracking system). The problem is that those are all internal-facing, so there's no incentive to make your life easier as a candidate. I'm trying to tackle this with https://rolepad.com, a job application tracking system that can be connected to an employer portal and provide greater transparency and just make the whole candidate experience much better (the employer part is still under development though).
I found LinkedIn’s Easy Apply to be remarkably easy to spam a hundred or so applications in a week and it lets you see if your application has been viewed or resume downloaded.

Unfortunately hundreds of other people found it just as easy.

This is why I never blindly submit my resume to an ATS. I only did it this time because I was unemployed (for two weeks) and had nothing better to do.

The five opportunities that led to interviews were still based on good old fashion networking

1. A full time offer (didn’t accept) and a side contract (did accept) based on referrals from former managers

2. Two interviews based on reaching out to the internal recruiter for positions I was objectively the best person on the market for - I was a major contributor to an open source official “AWS Solution” they were implementing and modifying. I accepted an offer.

3. Responding to a recruiter he reached out to me. There was some miscommunication about the role. The team thought the client wanted someone “local” to the US since their whole team was in India. They wanted someone local to the city - I declined.

Out of the 100 applications I randomly spammed, most didn’t get around to even looking at my application and only four actually downloaded my resume.

> so there's no incentive to make your life easier as a candidate

Especially because lowering the barrier usually means getting more low effort application.

People either put a lot of effort on few applications and invest significant amount of time in each one hoping to increase the chance they get picked up; or they put a lot of effort on reaching out as much as possible, knowing they have a very small chance on each application but playing on volume.

Most recruiters are only interested in the first category of candidates. Having a long initial process is a feature. The goal is that the second category considers that given their chance of getting picked up, it's not worth filling the form.

> Having a long initial process is a feature.

Reality is:

1. Screening tools (background check, skills analysis and testing) are really good. There's really no reason to put someone through a six-week gauntlet just to find out if they can do the job.

2. Interviews are really a tool for seeing if coworkers and managers get along with the candidate, and the candidate gets along with their future coworkers and managers. In many companies interview == where manager has discretion to hire the people they want. Lots of interviews usually means lots of managers who all want to put their stamp on the hire.

3. Being good at getting hired is a function of experience getting hired. The skills needed to be a good candidate do not align with the skills needed to be a good worker in most roles.

In my experience:

  (1) just isn't true.  It's at best a mixed bag.

  (2) is somewhat true. Team fit is pretty hard to figure out without interactions, and agree sometimes managers just want to get their oar in.

  (3) is oversimplification.  There are definitely people who are better a getting hired than doing the job, and they are hard to weed out early in their career.  If you aren't able to identify good candidates in front of you though (e.g. the FN, not FP) there are problems in your process, not the candidates.
1. I'm pretty sure that background checks work beyond doubt. I'm pretty sure that skills tests work beyond doubt. I'm less confident in AI resume/profile analysis and skills matching tools - both are getting better.

3. Agree, it's simplified, but for most companies, field and "hiring" managers are barely able to do an effective interview, let alone smoke out someone lacking interview skills from one lacking communication skills.

Agree both background checks and skill tests can work very well in an ideal form, but it's expensive (in time, mostly). As practised, they are very much a mixed bag. The latter is a problem past early career stuff anyway, as you aren't going to learn much in a couple hours.
Netflix was pretty great, I recommend everyone apply there. I don't even work there.

Their live coding questions were

1. Either practical , or core CS stuff. No fancy algorithms, just basic stuff you'd get in a CS 101 DS&A class.

2. Collaborative. No one cared about perfect code or syntax, it was very relaxed and dare I say fun (if it wasn't for the nerves).

3. System design was practical and a good back and forth.

The interviews were challenging overall, but nothing they asked seemed unfair or about memorization either.

Certainly coding under pressure sucks, but I don't think there's a better way.

> A question to everyone: What would a good application process look like?

A complete overhaul of credentialing, so that when I have a degree in computer science from a top university and decades of industry experience, employers don't need to independently confirm that I know how to reverse a string or traverse a tree or define what XSS is.

Also, make a time machine so we can make this change 30 years in the past, if you wouldn't mind.

The problem with credentialism is that lots of people with degrees from reputable universities can’t code.

Similarly lots of people with significant industry experience… also can’t code.

What does "reputable" mean in this case when these universities are handing diplomas to graduates who can't code? Somehow we've gotten ourselves into the situation where we force someone with a CS degree from Stanford write some leetcode, even when the people on the hiring panel themselves have degrees from Stanford. Do they still not trust their own university?

And yet, when scanning resumes, people often look for prestigious/"reputable" universities as a filter. Is the assumption that if they have a degree from Stanford and can reverse a string then that is a positive signal, but if they can't reverse a string that is somehow a personal failing and not a failure of the university to educate (and then evaluate) the candidate?

> What does "reputable" mean in this case when these universities are handing diplomas to graduates who can't code? Somehow we've gotten ourselves into the situation where we force someone with a CS degree from Stanford write some leetcode, even when the people on the hiring panel themselves have degrees from Stanford. Do they still not trust their own university?

What's the alternative? Just give leetcode tests to people who didn't go to the same university as the hiring panel?

The fact that we have the same tests for everyone no matter where they studied at is a good thing and prevents nepotism in hiring decisions.

A professional organisation like the ACM which 'accredits' college courses, making sure that 3.5 GPA from MIT is equivalent to a 3.5 GPA from Podunk University.
As someone who attended two different universities for my undergrad, the first was way harder than the second. Basically, I failed out of my first, and cruised through my second. I intentionally selected a much lower ranked university for my second attempt. I felt like I was buying a university degree at my second place. And, yes, both were ACM accredited. It means little.

What I am noticing on all threads about HN hiring: Hiring knowledge workers is fundamentally a difficult, fuzzy process. Few want to admit it. And, there are some people are naturally much better at it because they can control themselves very well during an interview. People who are very strong at solving puzzles will nearly always outperform during interviews for hands-on roles. More than anything, interviewing feels like dating. Everyone hates it until you find what you are looking for... then it becomes: "Oh, it worked fine for me."

The reform I'm proposing is that reputable universities should only issue CS degrees to people who can, in fact, code.

That's why the time machine is so important - to get back any CS degrees issued to people who can't code.

So I think you are actually agreeing with me?

This sounds more like a PE Exam equivalent for software engineering which I honestly think should be put into place since most traditional engineering industries have this already.
Yea, I think that is the alternative. A professional body which accredits its members. It is a system which is known to work for other disciplines.
this has been solved -- with take home coding or whiteboarding.

in the networking side of these we used to have a couple of Cisco 2960s with slightly borked configs and our interviewees had to log in and tell us what's wrong. 5 minute activity, but often took some folks 30 minutes.

Yeah I think that’s what Starfighter did. And we are discussing how it failed, so…
I used to share your opinions, until I sat at the other end of the table and interviewed candidates. The problem is that people lie constantly about their credentials, experience and knowledge. They lie on their resumes, they make up fake references (sometimes going so far as to pay their friends to lie for them), they might even have someone create fake portfolio websites for them and showcase those as their own. There will never be a way to detect such deception without asking candidates basic questions as a way to at least "smoke test".
A resume is not just a piece of paper. It’s a piece of paper with lies on it. And it can be the difference between not getting a job and not even coming close.

-Dave Barry

I’ve been interviewing people as either just another person in the loop or the person who could give the thumbs up about whether I wanted someone on my team and the manager just rubber stamped it for over 20 years - no coding just conversations.

I’ve never regretted a single person I hired and they have always been able to do the simple CRUD work that most of the 2.7 million developers are doing.

And before the gate keeping starts. I’ve been through the “Making Great Hiring Decisions” training and have conducted behavioral and system design interviews at AWS.

> I’ve been interviewing people as either just another person in the loop or the person who could give the thumbs up about whether I wanted someone on my team and the manager just rubber stamped it for over 20 years - no coding just conversations.

Sounds like a good way to filter for the right class background. (Which, given how well that's correlated with intelligence, is probably as good a hiring method as any)

What do you mean by the right class background? If you think I’m a white guy who graduated from a prestigious school, I can guarantee you that’s a far from accurate assumption.

Let’s just say when I walk through my neighborhood I’ve read comments about me in my own NextDoor group about someone “suspicious” and realized they were talking about me or my son…

> What do you mean by the right class background? If you think I’m a white guy

This is why I find it so frustrating to talk to Americans.

> Let’s just say when I walk through my neighborhood I’ve read comments about me in my own NextDoor group about someone “suspicious” and realized they were talking about me or my son…

So you're a member of the class that lives in "good" neighbourhoods where it's suspicious for certain types of people to be? I think you've proved my point.

I ask myself whether this problem is also part of the US mentality: in Germany, one would rather be tempted to treat even white lies as fraud, and thus compare (culturally, though not legally) such liars with criminals.

On the other hand, in my experience such fraudsters are in most cases easy to detect: just ask them some hard questions (where the candidate will either know the answer or not, thus rhetorics or charisma won't help) about the topics that the candidate claims to have expertise in (choose the question in a way that even very capable candidates will only be able to answer a fraction of them - this is fine and intended).

Typically, after 30-45 minutes you are either sure that the candidate tells the truth about his capabilities or is a liar (hardly ever anything inbetween happens).

> a degree in computer science from a top university and decades of industry experience

> know how to reverse a string or traverse a tree or define what XSS is.

In my experience, it is absolutely not safe to assume a correlation between these two sets of traits.

>A complete overhaul of credentialing, so that when I have a degree in computer science from a top university and decades of industry experience, employers don't need to independently confirm that I know how to reverse a string or traverse a tree or define what XSS is.

But 'top universities' don't know how to teach CS. That's the point. Don't waste your time there.

Maybe we should have a 'bar exam' type system, but the university system is a joke at this point, and there's no point trying to put lipstick on a pig.

>A complete overhaul of credentialing, so that when I have a degree in computer science from a top university and decades of industry experience, employers don't need to independently confirm that I know how to reverse a string or traverse a tree or define what XSS is.

But 'top universities' don't know how to teach CS. That's the point. Don't waste your time there.

Maybe we should have a 'bar exam' type system, but the university system is a joke at this point, and there's no point trying to put lipstick on a pig.

It still doesn’t tell me whether you kept up with what the market wants, you have the specific skills I care about or whether you have the behavioral traits I am hiring for.
> A question to everyone: What would a good application process look like?

I work in a top company with infamously difficult interview. I made major contributions to several opensource projects that modern tech runs on. I can easily show a clean standalone pull request attributed to me that introduces complex multithreaded code. That code runs daily on millions instances.

Why the hell do I need to spend hours answering “what a mutex is”? Also, understand that a lot of stuff is much less obvious and clear cut (e.g. how HTTP protocol works) for me than for your engineer. They only saw the basic case. For me the answer will be “it depends”.

Please, respect the candidate time and experience.

> I work in a top company with infamously difficult interview. I made major contributions to several opensource projects that modern tech runs on. I can easily show a clean standalone pull request attributed to me that introduces complex multithreaded code. That code runs daily on millions instances.

A lot of applicants will lie or bullshit something similar. How would you suggest an employer distinguish someone like you from someone pretending to be someone like you?

This. Once you've spent enough time on the other side of the hiring process and/or in a leadership role, the reasons behind aspects that seem annoying and trivial as a job candidate become clear.

Any interesting technical position posted by a company with a good reputation gets so many unqualified applicants that I wouldn't believe it if I hadn't seen it over and over myself at different organizations. Every HR department I've worked with has done a good job of filtering out the ones that didn't even look good on paper. Out of the ones that get past that stage, I'd estimate maybe 1-5% actually have the technical qualifications for the job. Of course, even if they have the technical qualifications, they may be lacking in other areas, like professionalism.

The last three companies I've worked for have all used a custom CTF as one of the interview phases, and it's been invaluable at screening out people who were good at talking about the work, but not good at actually doing the work. So, superficially, I'd love to be able to use something like Starfighter instead of having to maintain one in-house. But how likely is it that a company like that would build truly unique challenges for every customer? IMO it would cause cheating to be easier, because people doing the CTF in bad faith could just work from lists of known elements used in previous CTFs from the same company.

References. My GitHub profile. LinkedIn.
All extremely easy to fake.
> What would a good application process look like?

As a data engineer I'd like to have a chat about the pain points of the current team and contribute. I think a coding test is OK too as long as it is just one round and actually test something meaningful.