> > No puzzles, no trivia-pursuit style questions.

I swear HN technical interview threads are the poster child of talking past one another. First, for-loop is nowhere near a trivia-pursuit question. Second, different companies of different sizes/industries/goals have different requirements. Let's all move forward with this discussion and acknowledge that we can't all use the same process because we're not all hiring for the same type of job. If the engineers you hire consider for-loops a "puzzle" that's totally fine and OP using it doesn't invalidate your process for your multi-national or startup companies.

> I can say that I've never regretted a hire I said yes to

The real question is, has anyone else regretted that hire, which unfortunately can't be answered as they may not tell you.

> To some of the younger generations, I've been told it sounds crazy.

Doesn't sounds crazy at all. A single process guaranteed to work for everyone? Now that sounds crazy.

1. It's often surprisingly difficult to fire an underperformer (anecdata: a friend of mine has lost multiple talented members of his team in the past few months - all the result of having to work with one completely unqualified person. For some reason, the other person has not been fired). As a result, a bad hire can have an outsized and lasting effect on a company.

2. Unless you're looking at very senior positions, there are almost always more people available to fill a role. You may miss 9 out of 10 people who would be effective in the role, but you only need to hire one person.

The math changes a bit when you look at the mythical 10x developer, so maybe it would be worth looking into false negatives specifically in that case. Still, getting that 10x dev would be much more important in a more senior position.

You don’t want ‘bozo cliques’ to form, so you make a semi-objective process like ‘solve this algorithmic question’ as part of the interview loop. I think execs and the founders doing a final review before hiring all engineers comes from that fear.

Then other companies cargo cult interview processes from larger companies and the trend propagates.

If you want to ‘hack hiring’ as a smaller company, you should use hard to scale processes like the one described in the parent post.

I love this idea but my old history professor (who I pretty much disagree with on everything except this) used to always say "follow the money". What are the incentives that all the parties have for and against growing companies bigger?

If you don't actually verify the technical problem-solving ability of the candidate in some way you're forgoing signal that can massively increase the confidence you can have in your decision.

After a few bad interviews I got the hang of it and aced a couple algos interviews. I’ve worked as a developer for 8 years, have tons of software in production, have some open source contributions and have worked productively on several teams.

Interviewing is a skill. I understand why a company wouldn’t hire someone who doesn’t pass a programming test but failing a programming test doesn’t mean you can’t do the job.

Then ask for a reschedule or try to get it as the first thing in a day.

> I found the interview process stressful, or felt nervous or uncomfortable in the moment

Need to grow confidence. Walk into interview - like you own it. You are the best. Think - you know everything {only during interview :-) } but also keep an open mind. Don't think - it's an interview - take it as you are going to teach them about what they will ask.

Irrespective of this - mistakes will happen. Fail -> learn -> try again.

Yes, I wrote that right. He struggled to understand conditionals in general when building his own logic. The guy even had a masters degree.

I then did a course on assembly programming and having to be extremely structured and using jump statements actually helped me a lot in easier to use programming languages.

Point of this comment is that people might be good at a lot of things, while just having some weird brainfuse related to a very specific thing. That said, not using if statements makes programming rather difficult.

What did he do or say that made you think he could do the job even though it looks like he wasn't able to work with other people code?

But they blank at code and struggle with the basics. They get lost for hours at the most trivial bugs. It's weird, but it's very real. Real coding takes a certain kind of abstract thinking that some people just don't have.

A company trying to hire engineers can easily give a take-home programming challenge to a dozen engineer applicants and take very little time analyzing the submissions. That’s pretty unfair. But it also feels a bit untenable for a senior engineer at a hiring company to have very deep investigations of each applicant’s work history.

Another problem is objectivity. If your company’s engineering hiring process relies heavily on a senior engineer’s subjective impression of an applicant, you’re going to have big problems with your own engineers’ biases, whether subconscious or not. Expect to hear a lot of evaluations like “well, the applicant did seem to have good knowledge and experience, but I just wasn’t impressed for some reason.”

Is it? The cost of hiring the wrong person can be huge. Not just agency fees if they came through a recruiter (those aren't cheap!), but also all the time people then spend on the bad employee and all the damage that person does before the mistake is rectified.

If this system of reading the resumes and then spending a few hours of senior employee time on an interview can reliably find good employees, that's an absolute bargain.

This just isn’t true. Every company has a “probation period” usually 3 months where either party can terminate the agreement. That’s more than sufficient to cover this risk.

You don’t pay the recruiter until probation is passed - everyone knows this.

This meme comes from Spolsky who somehow also convinced the world that the hottest programming talent was beating down his door to work on a bug tracking tool for project managers. Maybe his talent was in blogging, and not actually in hiring?

Sure it is. People on our team need to take time to onboard the new hire. That's good and expected. The new hire will work slower and that's ok; they will need extra help, time to learn the codebases, etc. After a couple of months, a particular new hire did not work out. Time had to be taken to document reasons, meet with HR, meeting to talk about expectations, etc. In the end, the new hire is gone and so is the time the team spent helping, and the slowdowns on real deliverables, and the hit to team morale. It sucks when someone is let go. It was a net negative for our team and thus the whole org. Depending on a combination of level (leadership position?) and toxicity, negative impact on the team or company culture can occur. Bad hires can have a real cost.

I believe that to be an incorrect statement, based on my own experience. I have seen companies hire the wrong people and pay the price.

Every company has a “probation period” usually 3 months where either party can terminate the agreement.

I believe that to be an incorrect statement; while I've always seen probationary periods, in this very set of threads "akelly" says that nobody has probation periods. This evidence suggests that "akelly" has never worked at a company with a probationary period (and has foolishly extended their own personal experience into the universal, but that's a separate mistake).

I would also suggest that there is an opportunity cost attached; if someone is fired at the end of their three or six month probation period, the good candidate that replaces them is six months behind.

Some companies end up with drifting dead wood employees; not fired, just moved around from team to team, department to department, because the company makes firing people harder (or more costly to the manager / team-lead) than moving them. This can go on for years. That seems quite a large cost. I've also seen managers simply sideline bad employees rather than dismissing them, for reasons of company politics and face. I've also seen bad hires get promoted, in cases where promoting someone is easier and less costly (to the relevant team lead or manager) than dismissing them; that can be really damaging.

Yeaaaah no. I've seen people nope out of a job within anywhere between 30 mins to a couple of months. I've also seen people that knew it wasn't right for them stay 1 to 2 years.

I have seen not that brilliant employees that still were earning company money. Just you know "we hire only best of the best" is a scam.

Hiring bad manager or a senior dev, can be bad I agree. So it is not so good to use the same hiring way for seniors and juniors, but unfortunately companies treat senior devs also like juniors.

I agree with your approach and use it myself but one thing is different now and that’s the proliferation of tiny skills. Back then you would have a few big skills, you would claim to know one or two main languages, one or two databases and so on. Now people list hundreds - literally hundreds - of skills sometimes. And there’s no way to tell on reading if they really know it, or just saw it once and maybe did a tutorial or “hello world”. People now will add a skill to their CV if they’ve done it for a hour total in their entire lives! Or read a blog post about it. It is a massive time sink to pick through that.

This tells me the person doesn't know the difference between skills and implementation details, so I don't need to proceed to an interview.

Effectively you penalise not catering the candidate resume to what you are looking for or deem important.

One will filter you out for having too many keywords. One will filter you out for not having enough keywords. One will filter you out for including a picture. One will filter you out for not including a picture. One will ... ad infinitum

Your resume is being evaluated by different filters constantly. Different filters filter different things. There is no "right" answer. There are only answers you will or won't be filtered out for depending on which filter is being applied.

Which filter is being applied?

It's random.

Hiring is essentially random.

"I need my resume to show up in your filter, relevance to the actual job functions be damned."

I know the theory of how to use it on large projects. I even know enough to know that I'm pretty much just scratching the surface, but so are probably most other people.

Same with most other skills. At how many lines of code can I call myself proficient in a language? And what if I copied large parts of code from stackoverflow?

All in all I think I spend like 8 hours on writing and formating that freaking thing, and it still just feels like some of my skills are a stretch.

> At how many lines of code can I call myself proficient in a language?

If you want a target to shoot for, I'll give you one, but don't really follow it... LoC is kind of meaningless on its own in part because it's contextual on many things (you highlighted one context, lines copied, I'll use a different context). 1k lines if paid for them, 6k-10k if not. This doesn't include lines added and then deleted (i.e. if your only project in FooLang weighs 300 lines, it's 300 lines, even if making the project involved adding 100 lines, deleting 50, adding 500 lines, deleting 100, editing 300, deleting ...) you need projects whose sum mass is 1k. Probably better to have at least one 1k+ project too, especially if it's unpaid. But again, don't follow this, it's just a somewhat random target to answer the question. Better to think about what this could be a proxy for, and target that instead.

I'm glad you brought up git. Source control is central to modern software development. If you don't have it on your resume, someone might think "hmm, have they really done much programming?" But if you do put it, it will obvious from your resume that you are just out of school, so no one is going to expect you to teach a git class.

As a more experienced person, I won't expect you know the internals of git.

Non-technical people screening your resume aren't going to know the difference between you and Linus, though, so you need to put it. Don't worry, it's not false advertising.

If the job description is back-end tooling at Github or Gitlab, I'll expect more. Similar to the difference between knowing how to use a spreadsheet, and having written a spreadsheet.

Now, if it's something crucial to the job,say your C skills writing software for micro-controllers at an embedded electronics company (like what Nest or Pebble used to be). You can't fudge here. Nothing will help but lots of practice.

Good luck!

P.S. For your first job, focus more on figuring out what you want from your working life. What kind of manager, what kind of work, etc. Yeah, you'll need to pick up some buzzwords to add to your resume, but it's not as important as becoming good at the fundamentals of what you are doing.

To be honest, the process of writing a CV is mostly painful for me because I have to evaluate myself and feel quite inadequate. At the same time, I have multiple companies wanting me despite not being very good, so my actual chances are really good. Software development in Germany is going crazy at the moment.

I would say don't use adjectives to describe skill level. I put most languages I have experience with on my resume, and order them descending by how well I know them. I know the stuff at the top pretty well, and it's downhill from there. In interviews I'm very upfront that I'm incredibly rusty with the stuff on the bottom of the list, and interviewers understand and accept that.

The exception is if you feel comfortable putting "advanced" or "expert" on one of those, but then you had better be able to back it up.

LOC is a bad measure of proficient. I would say you're proficient if you can write a simple program without looking up syntax and relying only on autocomplete for library references.

It takes a lot more effort on the part of the interviewer and is "harder to scale", in that you can't just train people to ask canned questions. But since it's open ended, it's a lot better at finding out what the candidate is really good at, and it's very useful to have one of these in every hiring loop, usually by a senior team member or exec.

This is key. There are a lot of hiring managers masquerading as experts and are frustrated when cargo culting hiring processes falter and lack the people skills to diagnose a situation. You'd also be amazed at the quality of resumes a high, advertised salary will bring.

This is so true. The best devs are making above market rate and are busy and content with their current role. By not including salary most of these people will simply ignore you, because of the time risk involved in finding the number. Non disclosure only works if your salary ranges are generally known (eg faang).

I don't disagree that there are a lot of fake it till you make it developers who did a vo-tech class and are applying for jobs out of their league, but I just don't know how people don't spot them. It takes me about 5 phone calls to find a competent individual, and then I bring them in for a in person. As a hiring manager, I don't find it cumbersome to weed thru 5-10 people to find a good hire.

You think this is a claim about how good your hiring practice is, but the only way I can think to read this is as a point about how little hiring you do or how little evaluation of hires you do. In the real world, perfection isn't possible, so claims of it are a sign of inexperience or naivete.

This may just mean that you say a lot Of wrong “No”s. To get very high precision or very high recall is really easy... what you must measure is your F-score

Remember Facebook rejected Brian Acton, and paid billions for that. An oversimplification, I agree, but the larger point is that people tend to dismiss too easily the impact of bad “no hire” decisions, compared to the bad “hire” decisions. Just because you can’t or don’t measure it, doesn’t mean that the impact may not be arbitrarily large.

To borrow from poker: it’s commonly understood that if you’re not “caught bluffing” at least a little, it means you’re not bluffing enough. If your hiring process results in zero bad hires, you are playing it way too safe and I guarantee you are missing out on phenomenal candidates.

Now, this assumes that you're not missing out on great hires; in other words, it assumes that the good hires you miss are at the bottom of your hiring range. Your point might be that this can't be guaranteed, and while that may be true, it's unlikely that any tweaks to a given hiring process are going to bring them in either.

I would be honest and say "I'm under NDA for a lot of that but I'll do my best". If neither of you are jerks, you should be able to manage it.

Have you let new hires go in the first 90 days? That's just one of the ways personal regret is probably not the best metric here.

This is one way the current status quo might be better than the past: you don't get pigeonholed so much by your past experience into being a "fit" only for similar roles. Sometimes the hiring manager is really looking for a specialist, but in general, we don't care what industry you were in or what tools you were using, as long as you can prove you're smart. Some of the most impressive people we have working on Go microservices were enterprise C# developers before.

While it maybe easy to hire dev who have been on the market for 10 years. You still have to keep in mind that new developers are still a very large proportion of the dev population.

If someone can keep up in a technical conversation about their background with me and answer every question I have about a technical project they did, then basically they pass. It works especially well even if I'm not familiar with their project, because I have an opportunity to learn, so I can ask any question that comes to mind until they teach me what they learned.

I did hire someone that I regretted, though, but to be fair, this was among my first interviews. The mistake I made was getting too easily caught talking about programming and technical things without specifically diving deep into his past project. He and I vibed quickly and I liked him, and that felt like enough, but after only a week it seemed obvious that he wasn't going to be producing much code, and we let him go. Otherwise, I've been happy and my ability to discern has only gotten better as I became more experienced.

I got a little offtopic, but my main answer to your question was "if the company leaves the decision up to a majority of engineers saying 'yes', then a lot of companies do this." Google does this, the startups I've worked at do this, and some of my friends companies do this.

Reader beware, of course, I know at least one company on there shouldn't be.