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.

Software engineers making 150K with only a four year degree and some leetcode have nothing to complain about. Take homes? Whiteboards? Cry me a river. Try to pass the bar or get through residency instead.

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.

The whole point of these tests and whatnot is to weed out the bad from the good. It definitely is unfair on those who are good, but I'm not really sure what the alternative is.

I dislike the take home tests as much as the next person, and only do them if I really want the job. Beyond that, it's a neccessary evil until something better comes along.