A friend of mine asked me if I wanted a pointer to a job that wanted me to spend six hours of my free time greenfielding a toy. I laughed and said no thanks. Code challenges are sucking all the liquidity out of the job market and are probably responsible for a good bit of the salary hikes I've been seeing lately.

One challenge asked me to do everything in Vanilla Javascript.

The other asked me to make a commit to their production codebase. Even if you offer to pay me, your offer is never going to be truly enough, and I'm not looking for side work.

Code challenges feel incredibly lazy to me. Your organization sucks at hiring, so let's throw all the obstacles we can at applicants and see who makes it through. I wanted the job that asked me to do the production commit bad enough that I made my best effort. I ran into a snag and raised an issue like I was asked to. No reply, and the door slammed shut in my face a few days later when the time frame elapsed.

I now refuse to do a more-than-trivial code challenge while I still have a job. It's just not worth it.

There's little management innovation, they all mostly copy each other

Boy this is the freaking truth isn't it? Makes you wonder where the innovation is going to come from because it certainly isn't going to be universities -- all those management textbooks used in MBA programs across the country are just utter and complete rubbish.

The skills I would have to hone to do well in a Google style interview are very different from the skills I would have to improve to excel at my job. I wonder if Google prefers this system because the type of people that are willing to spent hundreds of hours honing their interview skills are also the type of people that are willing to invest a lot of their free time into their job beyond what is required.

That sounds like an exaggeration. I'd bet that very few people who work here had to spend that much time preparing...

I would have needed to study for a year or more of math since I never studied math in college, and I wasn't just out of college. Even someone with a computer science degree, once they've been a professional for a few years, would need to crack open college textbooks again to pass a Google interview.

Unless they did math as a hobby, which I will refrain from commenting on at this time.

A coworker of mine spent 5 years applying and reapplying and trying to improve their qualifications until they finally got hired.

I don't see any reason to question the statement that GP invested 200 hours.

When I started I didn't know what dynamic programming meant and I didn't know how to implement a breadth first search. (I thought it required a priority queue). So a lot of time was spent reviewing things like N Queens and dijkstra's algorithm because I hadn't touched it since university.

In the end I spent too much time on things I never got asked and I should have been practicing on paper instead of a computer.

In hiring you need some way to assess whether or not applicants can actually produce useful work. You can't get that from a resume, you can't get that from education background, and you can't get that from talking to people.

Now, you could just ask applicants for a sample of their work (preferably open source) and evaluate them on that.

Coding challenges probably get done instead of that because it is easier for companies to evaluate a single coding challenge than to evaluate a broad range of unique work from different individuals.

As an engineer the employment process gives you an opportunity to evaluate companies in the same way that they have an opportunity to evaluate you. If a company has a sub-par hiring process then you cross them off the list and move on.

A coding challenge addresses none of that, it just asks the candidate to solve a problem. Often coding challenges are sent to candidates and there's no verification that they're even the one completing the work. I've spoken with many candidates who submitted coding samples or code challenges and were completely unable to discuss the code. Often times I wondered if their recruiter supplied the code and not the candidate because of their confusion surrounding the code.

I've had more luck accessing candidates by asking simple requests like "tell me about your daily duties at your last/present job" or "oh you've language x, what's your least favorite part of developing with it?" If the candidate can't discuss simple things with mild depth or command then they're probably not a good fit.

This is what I do. If an interviewer can be bullshitted doing it this way, they don't need to be interviewing. Non-technical managers really need to defer this sort of thing to technical people.

There is no magical BS detector. You can't judge a person's skill without seeing them work.

Everyone I have met who thinks they are smart enough to not get duped by smooth talkers gets duped all the time.

You are conflating the issues. A tech top can detect BS, but no one can judge a person's skill without seeing them work for several months.

Think of it this way. How long do you think it would take an MD to detect a fraud MD talking shop? Not long. How long does it take a military veteran to spot a fraud? Seconds. You have to be technical to spot the issues though. If something pops up that makes you think they are bullshitting, you have to drill in on it.

You can have someone who has an extensive education in Computer Science and can talk about it all day long very articulately but has no implementation skills.

You might be able to catch someone with no comp-sci background by talking to them but not someone who has an advanced comp sci education.

The doctor example is relevant though.

Doctors don't get hired based on talking. They have to do residencies, get certified, and demonstrate ability before even applying for a job. Same reason. Someone could learn how to repeat everything in the text books without being able to do the procedures, which require practice to master.

For technical interviews, you don't ask them about Computer Science things (or only briefly), you ask them about real-world software development; that's what you are paying them to do. The stuff they really don't go over in CompSci classes.

What was the project you were most proud of and why?

What was the hardest project for you and why?

What are some of the ways you've connected to a database / datastore (if applicable)?

What were some database design decisions you've grappled over? What designs were you considering?

What's the most impressive code you've seen written by someone else and why?

Tell me about how you organized classes in a particular project and why you did it that way.

Describe a way you've organized your classes and wish you had done it another way, and why.

How do you make sure if your software has a problem, you know about it and can figure it out quickly?

What's the hardest software you've written and why?

How do you handle disagreements with a colleague? Can you site an example of a disagreement and each person's reasoning?

Notice almost all of those examples asked "why." That's the most important part. If someone isn't up to par, they will do one of two things:

1. Answer Briefly. 2. Babble on to the point it's obvious they don't know what they are talking about.

#1 of course can be because the person is shy or intimidated or an extreme introvert, but not likely. Because you're talking about a subject they should feel extremely comfortable about, even introverts will come out of their shell.

Being able to answer those still doesn't mean they can actually code proficiently, which would also make them not a good fit.

You seem to be swinging the other way too much. Not testing their programming ability just because other things are important doesn't sound like a great way to interview people, either.

They are still pretty rare as far as I have seen, at least any that are especially long.

> Code challenges are sucking all the liquidity out of the job market...

How exactly do they do that?

> One challenge asked me to do everything in Vanilla Javascript.

As if wanting a candidate with a reasonable level of knowledge on that is outlandish?

> Code challenges feel incredibly lazy to me.

I'd love to know a better way to weed out the people who can talk the talk but can't walk the walk. And every time I ask, the best response is something absurdly vague like, "I'd just talk to them and know, because I'd know what to ask them."

> Your organization sucks at hiring, so let's throw all the obstacles we can at applicants and see who makes it through.

As if testing for basic programming proficiency is 'all the obstacles'?

One code challenge is fine. But if they're all asking for them then applying for a job while I still have a job then I'm spending 8+ hours of my free time a week just doing code challenges. I'd have to really hate my life before that becomes something I want to do.

I don't know what segment of the job market you're in, but in mine it's getting a lot more common. They're treating mid-level and senior candidates like recent grads.

From these questions I can come to an understanding of what sort of talent is needed. Can we get away with junior talent or is a senior perspective required? What sorts of management resources are available, will we need the candidates to take on those roles too?

You're going to discover that companies don't want to be honest during the interview process. They'll lie to your face and tell you Everything is Awesome™. You're going to discover that applicants are dishonest as well. Everyone's lying to signal to the other that it should be a match.

I've spent the past ten years in the hiring space so I promise you, I've already discovered all of those things en masse.

This isn't a silver bullet to transform hiring. It's a foundation that improves on existing job boards by making simple elements like salaries and info on interview processes mandatory. Our intention is to then build on this foundation and create a platform that affects many more areas of the hiring process in a positive way.

People with insider info and trust cannot share that info. It would involve cutting their own throat and burning bridges. Any nice things said about the company would get pissed on as "Well, of course, you would say that because this is HN/you must be a shill/whatever." Inevitably, someone would feel the need to say something terrible so as to be edgy/honest/whatever.

There is just absolutely no good that can come of that.

They are also not subject to voting, they have a fixed path through the front page.

You mean you've never had a long winded candidate who wouldn't get to the point, where despite repeated attempts to get things back on track, you could only get through half the material you wanted to cover, and where everyone else who interviewed the same candidate was frustrated by the same thing? I almost envy you.

And some of the screenshots reveal an approach to hiring which is sorely lacking. At this stage, every single LinkedIn email and cold outreach email from a recruiter gets marked as spam.

Not a single one seems to understand that hiring should be treating people as… well, people with lives and desires. Not just a resource to plug into a hole; not a fool to be tricked into changing jobs so the recruiter can hit their targets.

Any innovation in this space is welcome and I hope there are enough "decent" companies to make it a successful business.

fwiw, part of the advantage of going freelance was side-stepping all the bullshit hiring assumptions.

The sooner everyone starts refusing to deal with recruiters, the better off we'll all be.

For employers, recruiters will do the dirty business the employers don't want to know about. For example, ignoring PII legislation to get a larger pool of contacts. Advertising highly paid nonexistent jobs to harvest CVs. Lying to candidates and pressuring them if they're wavering.

These convert into more hires.

For employees, recruiters will bypass bullshit job applicant websites that make you re-type your CV into their agonisingly long forms. They'll free you from emotionally draining work like customising your CV and writing a thoughtful cover letter - or even to really know what an employer does before applying to them. Often they'll also tell you interview questions in advance, and some will help you cheat on take-home tests.

This converts into less effort needed per job offer.

I'm not saying I like them - clearly, I see big disadvantages - but there are reasons they've lasted as long as they have, as an industry.

And more fires. This is why you see more and more Contract-To-Hire and Temp-To-Hire positions being posted.

Recruiters provide bad or inappropriate candidates to the employer. When we go through recruiters we spend a lot of wasted time interviewing candidates that should have never been sent to us.

I'd like to add one. Salary range is low (pre-revenue startup) so the company needs to make up for it in non-salary ways. And the company wants a chance to talk to the candidate and sell the position without having the candidate not even bother to apply.

With that said, I don't agree with that. I used to, when I was younger, but now I understand the importance of padding your retirement account and saving while you are young.

I eventually made my opportunity costs back and then some but it was the long difficult road and most people aren't so lucky.

That's where I'm at these days. I have over a decade of experience and it's a waste of everyone's time to talk if you aren't offering me six figures.

When I was younger, the talking to me sometimes worked to get me into the job, but it's worth noting that I didn't stay long at those jobs once I realized that the tradeoffs of lower pay weren't worth it. Turnover at a company has substantial cost, so this isn't necessarily good for the employer.

- Significant equity

- Flexible hours

- Usually less bureaucracy and politics

- More opportunity to make a critical impact as an individual contributor

- Usually a higher job title (senior becomes principal, principal becomes director or VP)

Those last two have been a huge help in my career. Early in my career I got a huge amount of experience that would take much much longer at a larger company. And the job title thing adds a bit of a "fake it until you make it" thing. But it came at the price of a lot more stress and less work-life balance.

Whether it is worth it is up to you. I used to think it was but I'm not so sure anymore.

Edit: Added a note on job title.

Only to the extent that you get do decide exactly which 14 hours you want to work each day (except when there is a 2am emergency of course)

I learned something at my first few startups... if you are working 14 hours consistently:

1. You will get burnt out quickly

2. Probably only 6 of those hours are productive.

If you tell employees to work 14 hours they will record 14 hours in their time sheet but they are probably not actually "working" effectively.

Now as the CTO of a startup I consider it my personal mission to grow and improve the product by making sure the team workers more efficient not longer hours. I get the same 6 productive hours out of the team and much happier employees. In fact, it could be a coincidence, but this go around we ship features faster and have less bugs then when I was at a company that demanded 12+ hours.

With that said, I also grew a lot as a person and manager during that time. And learned what is effective and what is ineffective uses of time. If you aren't able to answer the question of what will have the largest impact and what is the best use of time than it is easy to end up with people working 80 hour weeks.

Untrue. Less politics comes from good experienced management and leadership. The more chaos (startups), the more politics. Imo, tech only people who dont navigate politics well are best off in middle sized companies.

I also disagree on flexible hours. Startups are flexible in that you can come late in the morning. You rarely can leave sooner (even if you come in very soon) without major hit and you are expected to participate in more non-work social activities (adding to total inflexible hours).

But yeah, higher job title might be a benefit.

Free extra learning when you're fielding calls at 2 am because the shoelace-and-ducktape release process went belly up and you're expected to be available at all times.

Equity (many say you should value this at 0. I tend to agree)

Title (You get to be senior whatever because all the other seniors in the job market want stability. And money.)

Flexibility in tasks. On the whole, a smaller company will have more people doing a bit of everything. That might be annoying if you just want to focus on one thing, but if you've an interest in React, Keras, talking to clients, Rancher, and devops, it might suit you. You definitely get a lot of exposure to new technologies. When I worked for a "big" company I left when it was obvious I'd never get to work with tech I found interesting.

And the usual things a company might offer. Remote work is one I would find pretty tantalizing. Other places uses free food and beer, though I have a bit of a problem with compulsive eating so dislike the former (and there's plenty of people struggling with addiction who dislike the latter, no doubt).

All those dumb Valley buzzwords were secretly the fault of bros all along?

Fantastic! I'd hate to have to do any actual introspection.