Apparently the approved HN method is to arrange the resumes on a dartboard, throw darts at it, and commit up front to hiring whoever you hit unconditionally for at least two years without no possibility of having to fire them. Or something like that.

Setting limits on what you will do is good, and ghosting is bad, certainly.

But in the end, you're going to have to do something unfun to get hired. There's no way around it. I know we'd all love to live in a world where Google one day just logs on to LinkedIn and is so impressed by the sheer brilliance of our awesomeness which just somehow oozes through our listing despite the fact we didn't have to do anything to demonstrate it, as it's also unrealistic to expect programmers to have a lot of publicly-available demonstrations of their skill such as open source projects (forgot to mention that one!), that instead of hitting you with a job interview they just lead with a job offer for their best position, but that's just not going to happen.

>do something unfun to get hired

I don’t know of any other industry who hires senior people the way we do outside of performing arts.

I personally don’t mind putting together a portfolio the way most other creative industries do it. At least then I could use it multiple times.

What I don’t like is being treated like a new grad when I have close to 20 years of experience.

And called it the HN gestalt. Pretty sure I labelled it with what it is right up front.

Nevertheless, I do think there are quite a few individuals who have an unexamined (in the philosophical sense) assumption that they just shouldn't have to do anything to get hired. I bet most of them, if they examined it, would realize that it's not a sensible assumption. I think it sneaks in through these conversations. But I think it's a modestly popular view.

THAT is your strawman. I would question that this is a "common" assumption - most everyone, when pressed, understands there is some need for an interview and some form of evaluation of skills. They may push back on specific mentions as one person already mentioned, but almost everyone falls in a middle ground where it's something like "yes, interviewers have to vet people, and that is hard, but it can be done in a manner that is respectful of the interviewee's time and properly reflects the kinds of things a person may be asked to do for the job in question."

I would premise that the problem isn't with (most) interviewees not wanting to do anything to get hired, but that (many) interviewers do not have a lot of experience interviewing and have just googled what other companies do and copied that, many times for the detriment to the entire process. If the interview process were actually thoughtfully designed to both probe the interviewee's ability to work with the team in question and ability to do the specific work the position entails, I don't think you'd see nearly the same level of disdain for the process.

You can’t take the union of everyone’s food dislikes and say “according to the Earth gestalt, no food is edible.”

I get what they are saying. If you read the comment threads here on interview experiences, you're going to encounter groups that dislike or want to forbid every kind of technical screening technique. It's easy to read comments here and come away thinking nothing is OK and everything is unfair.

It's weird if a company feels it needs to do more than that.

Companies either have trial periods or can let go of non-performing personnel. Hiring is critical but I've not seen any study that would correlate "high scores" in any type of hiring test to actual work performance.

This implies no matter how elaborate interview performances are orchestrated, their capability to do anything else except create false negatives increases as their complexity increases.

Hiring, in essence, is always a gating process with very little predictive capability beyond. The only thing you can know is the percentage of new hires who fail at their duties, and if that percentage is oddly high, you realize there is a problem in your hiring process.

I suppose you can gauge candidate agreeableness and conformity by subjecting them to all sorts of hazing procedures but in our field I don't see how that translates to good outcomes either - technically speaking. Might be good for creating cult enclaves, though, for lonely gurus.

I was a bit tongue in cheek here but my opinion "less is better" holds as it comes to hiring practices - this does not imply lack of diligence from the part of the hiring manager.

There definitely are such studies. I don't have citations here, but it's well known that IQ tests or work-sample tasks are both the most effective at predicting on job performance.

I.e. if you prefer IQ in your job application process, you will get a more performative workforce.

However, with point samples it's not a very good benchmark. I.e. if you are comparing fairly strong candidates A and B, just preferring the one with the higher IQ is not necessarily the best option. So, getting the best hire for a specific position, and getting the most statistically best workforce are not necessarily the same thing.

Or in your onboarding process.

The difficulty with such is that these tend to be very time intensive on the employer side often requiring more time per candidate than the candidate spends with the prospective employer.

This can work for one candidate, but fails if one tries to scale it up to even 10 (much less 100) candidates. For that, a filter needs to be applied... and we're back at square 1 of a subset of people not wanting to do take homes (and so on).

Corps basically just offload this work on the candidate as this is obviously cheaper and more convenient, instead of spending time and looking into his profile.

I question how true that is.

In any case, GitHub as resume basically tells applicants that if you don't work in open source for your day job and don't have the time/inclination to do coding as a hobby, don't bother applying. Which is going to be pretty discriminatory against a number of demographics.

It's fine if someone wants to show off some project, but it shouldn't be a mandatory filter.

Personally I feel fine about take home coding challenges, because I would be programming something either way, but I can understand people that consider that they have better things to do with their free time.

I think it has to do with people the weird phenomenon of people that are working as "programmers" that don't know how to program. I've seen a few. I've seen people write C on their resume and I gave them an hour for an easy assignment with the language of their choice, and they couldn't even get anything to compile. The guy probably read a book on C a decade ago or took a C class in college. Me on the other hand, I had python on my resume although I never worked in python or any programming language, but I studied the hell out of it in my free time. It was difficult for me to get my first programming job, so I like this model more. Trust but verify

Another reason is that there is a lot of variability in programming jobs. A programmer or developer in one company may consist of changing a few lines of code in a project they don't understand all the way to architecting the infrastructure the whole organization relies on. It's difficult to parse out the two from just an interview.

If you're hiring an actuary, and they had worked as an actuary before, you're probably pretty certain the work is similar enough, and if they hadn't been fired then they're at least somewhat competent.

I like simple programming problems, something slightly harder than foobar, ideally industry specific. Show them you know how to get a programming environment setup, know how to create functions, for loops, classes if appropriate and basic control flow. With the technical stuff out of the way you can review the candidates work experience

This absolutely isn't unique to software. There's plenty of incompetent workers in other fields, like construction workers, bureaucrats, pretty much anything.

What I think is different is that it's not so much deep, like programming can be, as wide -- meaning a skilled interviewer can correlate experience and technicity in a way that gives reasonable assurance.

This is not the case with more junior positions where you need to make sure technicity has actually been acquired by the candidate, lest it be just as you say a "net negative" for the team: for finance positions with less than 10 years of experience, we have a case interview. That case interview is not meant to be selective but just a check of capability. Only candidates that have passed phone screening and hiring manager interview get the case interview, which is also delivered by the hiring manager so gives a chance to see the candidate in another kind of situation.

Junior bankers fresh out of school do the heavy lifting in huge important deals. They get supervision of course and there's a steep learning curve, but the fact is they are in the trenches pretty early on. Senior bankers deal more in relationships and sales. Could you imagine Google hiring junior engineers right out of college to tweak their ad-engine?

Programming on the other hand has taken a lot more time for myself, and pretty much most competent programmers I know. To think about it another way, I don't know anyone in finance that spends hours at home working on side projects learning finance for years. However every competent programmer I know has spent a considerable amount of time outside of the classroom and work honing the craft to reach a basic level of proficiency.

There's a place for junior programmers, but its one of those professions that if you don't truly enjoy it, the payoff in terms of the time you have to spend on it just isn't worth it. And the competition is a lot stiffer. The percentage of finance guys that spend their weekends contributing to open source finance projects, creating educational resources, or answering questions on a stack overflow type platform is much lower when compared to programmers that do this stuff for fun.

- how much would you rate your knowledge of C++ on a scale to 10?

- 9/10

- Can you explain "pointers"?

- blank stare

Serious question, if the person actually had a 9 out of 10 knowledge of C++, how would he answer? Or is this just a teaser question?

I don't know C++ but I would answer pointers are addresses in physical (?) memory. They let you pass around variables by reference where the receiving function has full access and permission to edit its content. Pointers have to be dereferenced with the appropriate type before being able to read it

Any answer is basically fine, as long as it's clear you know what pointers are.

It's basically also a starter question to go further into memory allocation and freeing, smart pointers, etc.

The thing is, it's fine if you answer 3/10 "because it's been a while since I saw it". It's just to probe self knowledge.

Shirley, you jest.

Doctors are asked to perform "demo surgeries," all the time.

Lawyers are asked to argue "demo cases" in court all the time.

Social workers are expected to help patients through trauma, in "demo therapy sessions," all the time.

CEOs are asked to do "demo IPOs," all the time.

CPAs are asked to do "demo audits," all the time.

In case no one realizes, that was all a joke. Of course, none of these happen, IRL.

I can see people with no track record (like just coming out of school), needing to do this kind of thing, but, once we have some accomplishments under our belts, we can have some track record.

Some of us may even have significant portfolios. Mine is so complete, that you can easily tell what I can (and can't) do, without ever even contacting me.

Designers live and die by their portfolios. Any first-time designer is expected to have a portfolio to show the prospective employer. Once the designer has been working for a while, they can point to their track record.

My fiancee is a high school guidance counselor, and she essentially did a demo session with some current students during her interview.

I don't like the situation we are in, but I think your examples actually help illustrate why things are the way they are: we don't have a gating mechanism into our field. Most of your other examples do.

Teachers also have fairly strict licensing and educational requirements (and get paid squat).

I know a lot of finance people. These are not the most stable or reliable people on Earth, but they have to pass their Series 7s, in order to work. They tend to be kind of a scruffy lot, otherwise, but they make a lot of money.

To the degree that it's a reasonable thing to ask in terms of time, it's hard to argue against asking someone to demonstrate something that they'll actually be doing on the job. Certainly I don't think, in all but the most extreme cases, that anyone would argue that there don't need to be auditions for actors or musicians.

When I was an IT industry analyst, we did ask for writing samples. At least one of the big firms did require at least some candidates to prepare a presentation on a topic and deliver it. (This is an example of a sub-industry that has very few formal requirements and people come from all manner of different backgrounds.)

This is anecdata, but based on talking to my wife and friends who work in other industries most recruitment is pot luck. They interview the candidate for 1 hour, maybe 2, don't have any consistency in what they're asking and no standard criteria for 'good enough'. It's all subjective and down to the interviewer (maybe two of them if you're lucky). You then get stuck with a proportion of your staff who are dead weight.

I'm not sure of the reasons why the technology sector cares more. Possibly because the difference between "good" and "bad" is much bigger - maybe not the mythical 10x, but more than the difference between one accountant and another. Or maybe it's just that these are all newer companies who don't have the older ideas holding them back and have discovered a better way to be profitable.

The mere thought of doing that, in the tech world, though, brings about collective apoplexy. I'm not especially a fan of how licenses can be used to protect incumbents, and bar entry to otherwise highly capable people. They do, however, go a long ways towards ensuring that a building doesn't fall down, the first time a hot rod drives by.

But hiring always has been "pot luck." Been that way, for -literally- thousands of years. That's why hiring good managers has always been important, and there's really no way to test for that. For whatever reason, we seem to think we get to play by different rules.

I presume one reason may be because tech industry may be a bit insular, and full of people who enjoy creating complex models of the world - trying to find a perfect technological solution to everything (when they should just try to find a good hiring manager in stead).

Medicine does move on, but a lot of what a doctor needs to do doesn't. And the bits that do are actually a problem with there not being a good way of ensuring that doctors use up to date techniques.

The difference is that structural engineers and doctors are safeguarding safety, and (most) software engineers aren't. If someone suggested people should need chartered status to work on medical device software I don't think that would be as controversial, and will get progressively less so as the discipline is less brand new and progress slows down a bit.

Many apps that I encounter, are pretty much bald-faced, unapologetic, data harvesters. That’s clearly their main purpose, and their stated purpose is really just the lure on an anglerfish.

“Move fast and break things” sounds good, until you realize that said “things” may be people’s lives.

https://en.wikipedia.org/wiki/Engineering_ethics

I presume technology sector pays more attention because the task of programmer is ill defined, and that it's quite hard to define exactly what you are looking for based on external standards.

Last fall I hired a supposed senior dev with 10+ years of experience and watched them struggle for the next 4 months with the most basic things. At first I though it was our codebase (large, mature and complex), but it became pretty clear they had mis-represented them selves. The fault is ours of course, they should never have been hired in the first place.

As for a portfolio, I would normally agree, but it's too easy to fabricate one. The above developer was put on a PIP and given some basic tasks to prove to me that they could actually do the job they were hired for (or at least the apptitude to learn/figure things out). For 3 of the assignments they submitted repos that indeed implemented what I asked,but they were not their work, they were cloned from Github. I had to let them go.

However it has become a common practice to require from applicants unreasonable amount of time to complete said assignments without any commitmet from the company. That's just toxic.

This would not have been such a big problem if companies provided decent feedback on what went wrong with your assignment.

One problem is that take home assignments are, barring some sort of time-gated online tool, open-ended in terms of time spent. Sure, maybe you can "meet the requirements" in a couple hours. But someone else will handle all the edge cases and optimize the code by spending a weekend on it.

I do a lot of writing and if you ask me to write 1,000 words on $TOPIC, I can probably do so in a couple hours. It will almost certainly be better if I work on it over a couple of days.

ADDED: Having said that, while I tend not to be a fan of take home assignments, if I'm hiring someone whose job is going to be, to any significant degree, writing for external consumption, I'm going to need a writing sample. And, if they don't have anything suitable, they're going to have to create one on the topic of their choosing.

Because nearly every other industry is credentialed, so proving your 3-8 years of university grind is enough to get hired.

Outside of tech, any other white collar interview is basically a 15-60 minute coffee or lunch with the boss (the culture fit interview basically) and then, unless you showed some red flags, you get hired.

Easy. They have a 15-30 minute chat over coffee or lunch, then they get hired.

Nearly every other industry is credentialed and a degree is enough to get hired? I don't think that matches reality at all.

In general, the undergrad degree is a filter. Unless someone for, say, a marketing role has a lot of experience, a BS/BA is probably a requirement and a better known school probably gives you a bit of a leg up as may a graduate degree.

You're still going to have some interviews. In my experience, HR passes promising resumes through, there are 5 or so half hour interviews, and then there's a thumbs up/down by the people who did the interviews.

But for most roles there's no specific non-negotiable credential like there is for an accountant or lawyer.

But outside of medical, legal, and certain financial roles, you're more likely to see formal non-academic licensing for truck drivers and hairdressers than for white collar professionals.

You maintain a current law license, which requires having passed the bar once, continuing education requirements, and the absence of professional mal-, mis-, or non-feasance sufficient to lose that license. Taken together, the requirements are ongoing, though some individual elements are one-time.

Not getting disbarred hardly counts as an ongoing requirement in all but the most meaningless sense of the word.

https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especi...

Problem is people calling themselves engineers without being one.

It would be wonderful to have an equivalente for computer science. You do it right after graduating, study for it once and you're done. Not leetcoding for 6 months every other year for life which is ridiculous waste of time.

Think of all the marketing, sales, Human Resources jobs etc…

Would you expect MD or CPA to be spelled out every time?

"Most working engineers don’t even bother with a PE."

Engineer is right there, no need for you know the E of PE is for engineer.

https://duckduckgo.com/?t=ffab&q=working+engineers+PE

https://search.brave.com/search?q=working+engineer+PE

https://www.google.com/search?q=working+engineer+PE

You are giving off troll vibes. Maybe you are in the wrong forum? HN has been called all sorts of things but never a "general public" forum. Next time, just ask if you don't know - no shame in that.

Software engineers don't like the concept of formal credentials. Fine. But you'll have to demonstrate your skills at one of the interview stages.

Or we could create something like the American Academy of Software Engineers, or the Society of Software Engineers, or the Software Engineering Institute, which would be tasked with accrediting schools and programs, and in order to practice as a software engineer in the industry, on top of a university degree, you'll have to pass another examination from the credentialing authority to obtain a professional title like Professional Software Engineer or Chartered Software Engineer.

Other professions gatekeep before you can take the interview.

Formal credentialing generally means you demonstrate "I can do this", in a very drawn-out, thorough manner. It's gatekeeping more, but there's a much larger guarantee for your creds to be transferrable from place to place.

In software engineering, you demonstrate "I can do this", in a several-round bout of interviews. And then have to demonstrate it all over again and again, for every single company. Your interview performance is non-transferrable.

My opinion is, the latter is more wasteful as it involves repeating yourself a whole lot.

The former has a higher upfront cost but you are betting in the long run that it will amortize over time as you continue to go on interviews.

The latter has less upfront cost but a greater chance of creating more cost in the long run, depending on how much you interview and where.

OP spent 6 hours- personally I wouldn't spend that much on any assignment, but the bigger issue here is that 6 hours is only valid for one company. Interview "work" is so proprietary and non-transferrable- like currency that is useless outside that one company. You cannot take what you did there and show it elsewhere to expedite an interview. You will have to run through another several-hour process again (whether interviewing or another assignment), for some other variation of a CRUD based problem that they expect developers to do.

I suppose the closest thing we have to avoiding repetition is- the answer many won't like- Leetcode. You still have to navigate through opinionated views of your answers, but at least there are more patterns that carry over that its benefits compound more easily from interview to interview.

> . . . wasteful as it involves repeating yourself a whole lot.

It's also incredibly wasteful for the companies doing the hiring. Which is why they often try to offload that waste to the candidate.

But those companies would probably have to pay more for programmers who were already vetted as part of their membership in a professional organization; people who were actual engineers. So it's not in the companies' best interests to change anything.

Furthermore I do see a difference between being a person who knows how to write code and being a software engineer. The former can easily be achieved without any formal education, but the latter is more difficult to achieve without formal education. There is lots of stuff not learned in a coding bootcamp and it will take time to close the gap.

I do not think one can generalize like that and claim, that we all do not like formal credentials. I wish formal credentials worked differently though. Not through some university institution, which might or might not teach us important things, but maybe more practical and hands on, more projects, where actual work is done and we all get more opportunity to learn from thise experiences.

Local governments impose licensing requirements on some professions. This is not something the professions just voluntarily impose on themselves. (If they did impose it on themselves, there might even be antitrust problems as a result.) This is mainly (or at least purportedly) for the protection of public health and safety, not to make it easier on potential employers interviewing job candidates.

It actually has nothing to do with job interviews, because every such professional needs a license in order to practice their profession, even if the professional is a self-employed entrepreneur.

So to be clear, when someone asks for software engineer licensing, in effect what they're asking is for local governments to regulate the ability to practice software development, even for self-employed programmers.

And then you can expect a visit from the government software inspector.

Anyway, government isn't a fig leaf, it's a cudgel. It has to be, otherwise the system would be undermined by mass defection.

It appears to have been for Engineers who want to be credentialed in software rather than a credential for a software developer to be able to attest to PE level standards of competency.

As a mechanical engineer with sufficient years of experience that would be considered senior in the software world but intermediate in the mechanical world, I have had interviews where we only talked, interviews where I was given a task and put in front of a computer with one hour to complete it, and interviews where I was sent a problem to work on at home. These interview techniques, while perhaps more prevalent, are by no means limited to the software world.

We do have apprenticeships in programming, we just don't call it that name. You start out at the bottom of the ladder and more senior people help you learn. Most medium and sized and bigger companies have some variation of that. Sure you can start as the only programmer in a small company and thus not get mentored, but you still learn on the job like an apprentice.

They are useful in that they at least convey a tiny bare minimum level of skill--something many, many software engineering candidates lack. Passing the bar exam for lawyers and the medical board exam for doctors signals at least some minimal knowledge and qualification. They don't tell you the professional's whole story, but enough to allow you to skip the "Where is the patient's knee?" interview questions.

Software desperately need at least some "barest minimum" gate that lets interviewers at least skip the Fizzbuzz questions.

Still, if I need someone who knows Linux, something like a current RHCE tells me they have at least some minimal level of competency. (Certs seem to be more of a thing for sysadmin knowledge than general programming however.)

To the larger point: I'm very much in favor of hiring junior developers, but there's a limit - I find you need at least 2-3 mid+ developers for each junior, ideally at least one senior/staff per if you want to do a good job of mentoring and development at the same time. Since the industry has grown exponentially, it's impossible to hire proportionally to applicants and maintain this ratio.

I am counting down the days until our recent senior hire is fully onboarded and comfortable and we can open a junior position again.

> Chemical engineers must, on average, complete 15 hours of technically focused continuing education courses each year. State requirements vary, and some also require courses on ethics, state engineering laws, or professional behavior. Acceptable formats include online courses, live webinars, seminars, and college courses.

So while the PE doesn't have a personal portfolio, they do have a professional one, the tests that they've passed to reach that and the continuing education completion certificates.

The "do things at home" is a way to get a similar type of value as the PE has for continuing education... but not as any formal way of stating it because software development hasn't come up with a good way to do licensure.

So, for all those other technical, scientific, medical, and yes, business fields (the 'C' part of a CPA) which do have licensure, this is a solved problem.

Continuing education is a bit of a joke. So you attend a conference once a year, maybe watch some webinars. In general, PEs mean you've gotten an undergrad degree, passed a couple of GRE-type tests and have worked in the industry for a few years.

Within a few minutes I can figure out if a candidate knows SQL better than I do (not that hard to do, basic joins maybe a HAVING clause) or if they took a class and forgot most of it and don’t know what it means to de-normalize data. I can do the same with Excel.

But I still don’t know how to effectively judge whether a candidate is effective at closing deals, what their work ethic is, how they actually support team members, are self-starters, etc. It’s much harder to do.

Technical fields have a huge advantage in being able to assess skills with objective criteria. It’s not perfect and interview anxiety is real, but it seems a lesser challenge than how business fields hire.

Is there a name for that fallacy?

I.e., when two different subgroups have incompatible positions, treating each individual in those groups as holding both positions?

I don't know if you're suggesting that interviews should assign actual tickets in an interview, but that seems nearly impossible to do in practice. I've never got back work from an interview or assessment that was anything near production code - nor would I expect to. It's to get a sense of the level of their real world coding skills are since there is such a variance between developers.

Your resume is basically the Instagram version of your work life (and let's not pretend otherwise). I've worked on a couple of teams that hired solely on the "strength of the résumé," and it was, honestly, a disaster. The two people I know we hired on that basis quickly cycled out (one fired, one quit) because they were pretty terrible. We realized they were just good interviewers who couldn't actually ship very good code. Maybe the issue was on us with a bad set of interview questions, but had we asked them to do even a simple take home, we'd have sussed out the issues really quickly.

I have a friend who set the expectations upfront (working from home) and was told it might not be a problem, finished the whole ordeal of take home assignments and technical rounds. The company liked him but he was told WFH is not acceptable (hello Tencent).

In my experience interviewing, a properly designed technical interview exercise can fairly accurately peg an interviewee's skill levels in about an hour, as well as their ability to communicate with the team (taking into account nerves will likely reduce their performance in an interview setting). I think having a take-home exercise could be an option that could be offered, particularly if someone is struggling in an in-person(or video) interview session, or even something that is flexible ahead of time to allow the interviewee to put their best foot forward by choosing the evaluation that best suits their strengths.

I do agree with your point that interviewers need to have an ability to spot "good interviewees" - some people are just really good at interviewing. I don't think that automatically means take-home assignment though, I think having gradually more specific questions to suss skill level out (which you mention, i.e. "better questions") is really important.

Having an interview process exactly like Google won't give your company Google-like engineers.

> We realized they were just good interviewers

It sounds like they didn't hire solely on the strength of the résumé, because then wouldn't interview performance be irrelevant? In contrast, there are people with strong résumés who don't interview well, regardless of the interviewing method.

> The two people I know we hired on that basis quickly cycled out (one fired, one quit) because they were pretty terrible.

This is how it should work, I think. Hiring is extremely difficult. Mistakes will be made. The key is to quickly correct those mistakes and move on.

I'm not sure what you mean by putting families at risk?

Incompetent people put their own families at risk by trying to work in an industry where they're incompetent. It's not the responsibility of employers in that industry to provide for the families of people who can't do the job. It's really a bizarre concern to be worried about the families of fakers. Moreover, how would it be better for the family of a fake for companies to not hire them at all, as opposed to hiring and inevitably firing them? In either case they'll be unemployed ultimately, but at least if they get hired and fired they can pick up some paychecks, so that's actually better for their families, if that's what we care about here.

(1) Competent programmer who isn't a good fit for a particular job.

(2) Incompetent programmer, the "can't code, can't even write a for loop" bogeyman that seems to scare everyone.

Coding interviews — whiteboarding, take-home projects, and the like — are intended to filter out (2). But they aren't good at filtering out (1).

(1) can always occur. There's not a great way of avoiding that until they actually get on the job. Of course it's unpleasant to fire somehow who doesn't work out, but I don't see how take-home assignments are supposed to help here with (1). Whereas the (2) people shouldn't be in the industry at all, and they're lucky to somehow scam someone into giving them a job, but the industry should not be financially supporting scammers or their families.

I'm personally not convinced that (2) is as big a group as many people believe it is.

I've done exactly this, and everyone seemed happy.

It took up a lot of my week, though, and I know it would be tricky to be interviewing at multiple places at the same time like that. Others have mentioned portfolios, which is an idea I think makes a whole lot of sense.

I've seen multiple comments in past HN threads of programmers complaining about any after-hours coding homework (even if paid) because "they have kids and don't have time or energy for that".

Probably the only suggested interview method that gets the fewest complaints from candidates is the "let's have a casual chat and just shoot the breeze about past programming projects". The problem is that you get complaints from the hiring managers that it's too easy to bullshit and is the weakest signal to determine competency.

I agree with gp (jerf). Ultimately, candidates just want to be hired without demonstrating skill. E.g. the college diploma should be enough. Or the resume should be enough. Or just low-stakes conversation should be enough. But the hiring managers don't want to do that.

Hiring managers need to actually spend time constructing a process that has questions (and if needed, exercises) that specifically determine whether a candidate has the specific skills needed for the job at hand. But that is actually fairly hard to do right, and it's easy to just grab some semi-random "take home exercise" and hand it off and call it a proper assessment. A proper technical interview will have increasingly specific questions that will both assess skill level and a person's ability to communicate with the team. If there is an exercise, it should reflect the specific skills the person will be expected to use in the job at hand. And bonus points for flexibly adjusting between in-person or take-home depending on the interviewee's strengths and wishes in that regard.

The problem is you're using your own perspective of "reasonable middle ground" and thinking that other candidates would agree with you. Many would not.

Here's an example of "you shouldn't have to go through that crap when your resume clearly states you are capable." : https://news.ycombinator.com/item?id=11596553

So regardless of any "job-specific" skills assessment you come up with, you will still get complaints from many because they feel their resume of experience, (or github portfolio, or college degree, etc) -- should already prove that they know how to code. This is not an uncommon sentiment! E.g. "Making me demonstrate my coding skill is an insult when you could just look at my resume credentials. Does a pharmacist show how they dispense pills to get hired?!?"

Or variations on your "reasonable skills assessment" with creative exercises such as "here's an existing bug ticket for a code defect; show us how you debug it" ... still has some complaints of "demonstrating my coding skill is unfair because I get nervous in interview situations because there's an imbalanced power dynamic between interviewer and interviewee."

Ok, instead of interview because you get nervous under pressure, here's some coding homework. Of which this "reasonable" alternative has pushback from some comments in this subthread.

Various threads about "hiring is broken" is evidence of the ever elusive "reasonable middle ground" that we're chasing after.

I don't have a lot of sympathy for this argument. If they have time to take half a day to go to an interview, then it doesn't seem like it should be much different to take half a day to work on an interviewing problem.

But a lot of companies use the multi-hour coding homework as a preliminary filter before asking the candidate to take the "next step" to the half-day onsite interview.

The coding homework is asymmetric work because the company doesn't have to expend their existing employees time on prospective candidates. In fact, a lot of companies let recruiters coordinate the coding homework so their existing employees spend the least amount of time on it.

The onsite interview is more symmetric effort because both the interviewer and the candidate have to expend time together. There's a bit more commitment on the part of the company doing the hiring.

I'm not complaining. Just stating how the different perspectives play out.

if i interview at 10 companies suddenly a lot of vacation time is gone.

so i am not going to take time off until i am reasonably certain that i want this job and can get it if i pass.

likewise i'll be willing to take time off for a take home assignment only when that is the last test i need to pass.

if companies want the assignment before they'll even look at my CV, then that's to much.

steps should be:

look at the CV to see if the candidate is basically quslified.

talk to the candidate to get to know them, answer any questions, agree on salary and benefits.

once that is all sorted, bring on the coding test.

Most contracts I’ve had will actually state “without manager approval” but that’s just as bad in many instances.

[later] Actually this became illegal in Illinois at the beginning of this year, though the protections don’t extend to clients or competitors.

It's unenforceable, according to everyone I've interacted with in the state :)

"The solution is this, but I'm SURE people wouldn't like it, so you all are complaining too much"

What was the rate you chose?

…

Now, I want to eat pumpernickel and am shaken by wanderlust in the hinterland.

The real issue is that the company ghosted OP rather than provide feedback and closure.

Personally, the more experience I gain, the better the hiring process becomes.

AFAICT the null hypothesis has yet to be disproven in tech hiring.

Actual hiring results look a lot in abstract like dartboarding after trying to filter out the obviously unfit applicants, and while people can reasonably disagree on how hard to filter, not at all seems like a good way to put yourself out of business.

In any case, the dart throwing method can't be criticized simply because it produces lemons, because no hiring process is perfect. Every company from top to bottom makes bad hires. So you've got to compare the overall results, which will contain both good and bad.

One big advantage of the dart throwing method is that it will randomly select good people who tend to be overlooked by hiring managers because they don't interview well.

Yes, now your process is indistinguishable from existing hiring pipelines. The darts happen to be weighted in all sorts of ways you don't have full insight into, but hey, so are literal dart throws.

> In any case, the dart throwing method can't be criticized simply because it produces lemons, because no hiring process is perfect. Every company from top to bottom makes bad hires. So you've got to compare the overall results, which will contain both good and bad.

The problem is not that it makes some bad hires. The problem is that you will make >90% bad hires if you don't do filtering, and once you bring a few of them on and word gets out you will be making net >100% bad hires by this process.

How so, when there are no interviews? Everyone seems to take interviews to be the most important part of existing hiring pipelines. Interviews are certainly the most time-consuming and expensive part of existing hiring pipelines.

> once you bring a few of them on and word gets out you will be making net >100% bad hires by this process

To be clear, I was only entertaining the dartboard selection part of the proposal and not "for at least two years without no possibility of having to fire them". You should definitely fire people who can't do the job.

I think you're also assuming that if "word gets out" then you will only attract more bad candidates, but it will also attract more good candidates who hate the existing hiring pipelines, some to the extent that they even refuse to apply for many jobs.

Like, "Zeitgeist" seems to be used like I would in German (although far more frequently).

What am I missing? Is there some subtle difference in meaning via Yiddish or similar?

A collection of physical, biological, psychological or symbolic elements that creates a whole, unified concept or pattern which is other than the sum of its parts, due to the relationships between the parts (of a character, personality, entity, or being) quotations

It's also used that way in German, aside from its regular meaning: https://de.m.wikipedia.org/wiki/Gestalt

The important part of contract-to-hire is it shows how the person will communicate while working, which is not really verified in any way with a take-home or whiteboard setup.

Going straight to full employment is like going from strangers to marriage, contracting is a dating phase.

As someone who has been freelancing/contracting for a long while, it is much preferred to full-time employment and essential ownership anyways.

I personally don't mind take home tests, everything you do you can learn from and this gives you somewhat an idea of the type of company you are working with (not necessarily the work). Though they should be paid, as people that are in demand would be more willing to do them as well as the company more invested in reviewing them. However, in no way is the take home test a good indicator of how this person will ship product.

The difference is in the presumed defaults.

If you hire me, my assumption is that outside of company/organizational problems/changed of some sort, you'll keep me around so long as I'm reasonably competent.

Contract to hire on the other hand , sends off a vibe of we'll probably hire you if you wow us. Which, if someone already has a job or has other good offers in hand, is not going to sound like a great deal unless it's a company/position they really want and are very confident they can do.

Same with interviewing/take-home/whiteboard. It is just a better realistic view of the company. It not only makes it a "wow us" for the worker to the workplace, it is also the workplace to the worker. It is a two way street with a more realistic sample. It also reduces the friction of locked in employment.

Creative/programming/product/design are all creative fields, most projects/products like that have more flex/contractor style arrangements based on projects/products not necessarily the company such as movies, music, books, etc. Most of my career has been in games/interactive/agency style projects/products so it may make more sense there.

You can't judge creativity and product shipping capabilities with a take-home/whiteboard/interview very well. The sample is much smaller. The better way is the body of work and a real test that is longer or closer to the actual work and timeframes.

And yes there are agencies and consultants for all sorts of specialized work on a project basis. But that's not the majority of software and I'd guess the majority of programmers/software engineers don't want to be constantly looking for work especially if demand lets up.

Obviously, some things like games lend themselves to more of a project-based approach to staffing than other things do. (And certain other engineering projects do as well.)

Not when employment is at-will.

It's more like going from one date or few dates (depending on the length of the "interview process") to an exclusive relationship, which happens all the time. And non-marriage relationships are also at-will, so they can end quickly if necessary.

It does suck that when you are on your own you have to either join a group or be rated at the individual/family level. If we fixed grouping in health insurance this would be much better. Grouping like how Medicare does it across all private insurance would be much better.

The great thing about not taking work insurance is no extra cost, can easily go from contract to contract or full time for a while, and with your own company it can be expensed. The only downside is the part work would pay for, however you don't get any say in the type of insurance or what companies. You can ask for a small bump in pay to help cover it.

Companies would prefer not to have to deal with health insurance as it is a competitive weight in the US. Private insurance and public options, both separated from the employer is the way to go.

We don't get our home/auto/life insurance from work, why do we get the most personal type of insurance, health, from employers. Not only that healthcare bound to the job leads to all sorts of problems, ageism, harder to change jobs, harder to compete with other countries and more.

If developers starting doing this more, we alone could change the legacy employer/healthcare coupled system.

For example, my wife is an organization development consultant, she's changed jobs a few times over the last 12 years, and never has she had a take-home test. Instead, she has a few rounds of interviews, typically starting with a hiring VP, followed by an SVP or executive, and possibly a panel interview with possible peers. They talk about her previous work in detail, digging into frameworks she's used, papers she's read, etc. And then relate that work to the open position.

Personally, I've had reasonable success talking through a basic system design problem. Depending on the candidate's experience level, I can focus on different aspects of the problem... overall design, performance & algorithms, eventual layout of services/components in AWS, etc.

Yes, but to be fair, I am not convinced that such a method would yield drastically worse results than what is already done at many places. I am not totally being facetious about that either!

It's a jungle. People get hired or rejected for all kinds of reasons, meritocracy has less to do with it than we would all like.

The best approach is to keep one's professional network well-maintained so that when it comes time to change, your reputation precedes you. That's not always possible. Some jobs really are filled from candidates who drop their resume into an anonymous applicant vat on the web and hope for the best. But I think the best-fit jobs are often obtained when you know someone and they know you.

Meh, in the Midwest plenty of jobs pay enough for that, 6-figure tech jobs put you at 3-4x the median income (31k here in Indiana), but plenty of other jobs absolutely pay enough to buy a house (teaching - my wife makes just shy of double median income as a high school teacher, nursing, law enforcement, fire fighting, all sorts of trades, etc).

Well... ya know. Things have been weird lately.

My wife and I bought 20 months ago with me making 39k and her making upper 40k. We bought this house with zero down at 170k and it's now estimated at 240-250k per the mortgage company and Zillow. We have about 1200sqft on the ground floor then about 1200 in the basement with a little over half of an acre, we're 30 minutes outside of Indy. House is 1960s.

A new construction house in Plainfield, immediately adjacent to Indy, you get 2 bed, 2 bath, 2 car garage, basically no yard with the house at 1504 sqft is starting at 290k right now and can get a 3 bed with similar sqft for closer to 300k. If you picked the neighborhood well, and were ok with not having the latest and greatest features, a single person could still probably pull a mortgage in a safer neighborhood without issue.

>somewhere around 40k ~ 50k? (which is what high school teachers in the area seem to earn

So this varies wildly. My wife was getting the higher end of that at the rural school she was teaching at, she's moved one school district over and took a considerable pay bump - mind you she has like 12~ years of experience, and once she finishes her masters she'll get a 4-5k pay bump at her next (annual) contract renewal automatically.

Name me one interview method that actually has better results than that? Okay, lets eliminate the ones that are obviously unqualified from the ones we paste up, is your method still better?

Most people interviewing honestly have no reason to believe they have a better method. There has been a fair amount of scientific research about how to select good employees, but none of that has made it to the people interviewing. I don't know much that will help, but HR really should be finding scientific basis for how to interview and training people on that.

Once we admit "eliminate the ones that are obviously unqualified", there's no longer a principled distinction between dartboarding and what we actually have, it's just a matter of degree of filtering.

The optimal level of filtering is almost inherently going to look higher to employers and lower to applicants based on their incentives. Fixing this is a coordinated action problem.

There should be some kind of test that would be recognized by the industry, that you could attempt once every six months for example, and that would positively assess your ability to code. You would get a score that you could show to recruiters (if you wished to). Some recruiters would accept only 95/100, others 90/100, etc. There could be language assessments as well.

I don't understand why this doesn't exist. Or maybe it does exist and is simply ignored? What would it take for companies to trust such a system?

Write such a test. Give it to all the engineers whose work you know well, and see if it can accurately predict what they brought to your team. I would be very surprised if you could both spot good talent and dead weights reliably.

The downside is some people have barely scraped by in the interview and turned out to be absolute rockstars and day 1, and some people have aced the process and driven everyone else mad with incompetence. So it could be improved.

And maybe that's just on us not writing the perfect questions yet, but a bigger problem is that once we've used a question enough someone will post it online and suddenly a suspicious number of candidates are able to show up and rattle off all 3 optimal solutions in 15 minutes. Weird! I suspect a standardized test approach to software engineers would get this problem even worse.

This system wouldn't replace the personality interviews, etc., but only measure technical abilities.

If I go by mainstream, then I guess it would contain some coding task, where you might have to solve algorithm stuff, that you will probably never encounter on the job, or some fake OOP "everything is a class" or "I must use [hot web framework of the month] for trivial things" kind of thing. None of that really tells much about a devs true skill.

I think the problem might be, that jobs are so divers as developer. For some jobs maybe the hot web framework of the month is really all you need to know, while other jobs might require you to think about how a system needs to be redesigned to run on some kind of multi server environment.

I guess there could be multiple such tests, for each area of expertise one. It would for sure be a lot of work to put them together. One would also need rotating problem sets or questions.

Also: Who is going to create these tests? I hope the idea is not big tech or some kind of government participation. Big tech would quickly make it a filter for only themselves, making their tech stacks assumed knowledge in the tests, and government would probably come up with something hopelessly backward like testing your Cobol skills or demanding you write an HTML 4 website, while you have gotten used to more semantic HTML 5 years ago.

I think it is a nice idea, but there are many questions about how it could be usefully implemented.

This is how language certification works (think TOEFL, IELTS), and that industry still suffers from a massive amount of fraud. If you make a certificate like this too expensive, it serves as a barrier for entry for candidates. If you make it too cheap, the people administering the test will start pushing through candidates as quickly as possible without any regard for academic honesty.

I don’t understand how this is hard. I’ve hired dozens of engineers in the last 10 years. I’ve never needed to resort to any google level leetcode tactics. It’s never made sense to me if the goal is to hire a quality software engineer that can get the job done. Maybe that’s not the goal for companies that make interviewees do this performative bullshit.

Thinking about it, I think this is a good approach. Duration is right, you're left alone to think, and it's pen and paper so while low tech it does show your own reasoning and your own knowledge of the language (a typo here or there is not critical to the exercise).

It could be an interview. Or a series of interviews. Just like every other job.

The recurrence of those complaints indicates that the process could be improved to benefit both parties. Everything you listed can be made better for all. The reasons they're not have to do with a mix of convenience, traditionalism, mimicry and other social factors.

Think of all the good reasons companies had to have workers on site a few years ago, but can somehow still make it work remotely today.

Take-homes exist because companies suck at interviewing tech workers. It should be enough to simply review some code while on a call.

Companies should hire senior engineer consultants to do technical interviews. A staff engineer with 15+ years experience can suss out how good another engineer is in 1.5 hrs.

Not that there's an approved method, but the best one IMO (and which I've been using succesfully for 25+ years) is to carefully read the person's resume and have an in-depth conversation about projects they have worked on. No trick questions, no whiteboard memorizations, just a normal conversation about the work they claim in their resume they have done.

I actually think that'd have, statistically speaking, similar results as right now for a lot of companies that aren't Google.

Perhaps the reason why things are so is that a good chunk of tech revolves around advertising, and it’s easy to think of resumes as ads if you work in that space day in and day out.

My post was not meant to imply that home assignments are a wrong tool to filter out candidates.

It's how it is conducted that makes it a toxic practice. Not providing any meaningful feedback or not paying for a work that takes too much time is what makes it not acceptable.

I never had to

then (or instead) we might do the opposite: I should have a project on github (or similar) that you can look at beforehand, let you pick an issue, etc etc

if the issues are 6 hours issues, the commitment is on both sides: the company has a team member spending those 6 hours too

Here is your homework, we expect someone at your level to spend no more than two days on it, here is your $800, have fun.

I love it.

Nevertheless, I would absolutely not spend 6 hours on a take home assignment without compensation. Capitalists get carried away sometimes...

We then walk through their notes (if they made any), and the code sample itself together. I have them make any observations, critiques, suggestions, or other thoughts together with me. This gives me an idea of how they think, what issues they saw, how they would improve things, how familiar they are with the specific language, and coding in general. It also gives an opportunity for some light “conflict” resolution , if I push back on their thoughts.

This has worked really well. Those that don’t do well on the spot can make notes ahead of time (but aren’t expected to spend time coding for hours) and those that are confident can walk through it live.

The guy also asked me a few relatively simple technical questions, then said "Okay I know you can handle the job, let's see what you really know," asked me some really difficult questions, when I said "I don't know" to some he actually spent a few minutes teaching me the concepts.

That same guy was the lead programmer on some famous arcade games, btw. Did a lot of assembly programming back in the day. He had serious technical chops.

Got a job offer the next day. 1 interview, 1 interviewer, a little over 30 minutes spent.

Best interview experience I ever had. If more interviews were like that I wouldn't feel dread every time I felt the urge to switch jobs.

Also if that's all someone of his caliber needed to determine applicant quality, I don't see why everyone else feels the need to go through all this other bullshit.

Flipping it around, it takes someone of that caliber to be able to determine applicant quality with just that. Can we replicate it without having to spend some of your most valuable employee-hours, let alone in a way that doesn't leave you open to accusations of all sorts of bias?

I've long felt that 60 minutes is sufficient for a competent interviewer. In a past life, I was tasked with interview-slots where I had to both assess the candidate and double-check the signal other interviewers got, and I would spend:

  - 5 minutes on intros,
  - 15 minutes on a coding exercise,
  - 15 minutes on architecture discussion about something else,
  - 15 minutes on "behavioral" questions about something other than *those*,
  - and 5-10 minutes on "do you have any questions for me."

I love the fact that your interviewer got it down to 30 minutes, and I especially love that part of his interview process was sitting down with the candidate and teaching something new on-the-fly. (If I had to guess, it was your "I don't know" -- followed by how you handled being taught something -- that sealed the deal for your offer.) That sounds way better than a lot of the behavioral-question fluff that I used to try when I was still finding my way as an interviewer. I'll have to give that a try.

It was such a good trigger for discussion and we could easily measure a candidate's fit in moments. Some would just go "yeah this code's perfect" and not argue at all, some would spend ages with irrelevant details, and the couple of people who immediately looked at the diagram and spotted the most glaring OOP issues turned out to be great at their job.

One swift interview process I did included a single short page of code and the invitation to (with pen and paper) review it; I was given some time to think about it on my own and then to talk it over with the technical interviewer.

I liked that one and they had what I thought was an above average quality of developer when I joined. Anecdotal but interesting.

I've had 4ish interviews since that job, and all of them gave an on-the-spot code reading assignment to walk through their code to find the bugs. It let me see who has old style coding standards, who takes advantage of modern C++ utilities, and that the interviewers are competent enough to walk through coding examples, too.

The one thing I didn't feel just asking for review/discussion accounted well for was their ability to build/add something new to the code, and so we have followed up the code review/discussion with a very specific/small exercise to evaluate the process (architecture, pseudo-code) they'd use to do that, and then discuss that as well.

Depending on the tweak it can also make the most basic of applicants fail to find matches entirely e.g. ask for a “YcomBinator” instead of a “FizzBuzz”.