Limitations and pitfalls of the job interview

Find them through word-of-mouth.

I use a gig to hire process for this. It works very well. I've been meaning to write more about it but I also get income for helping with hiring around this model so im a bit conflicted. The whole answer is long and complex. Basically: give candidate a proper task on your project and evaluate them based on that work - the "interview" is less than an hour, the "work" is longer (many hours (and you pay for it)) - provides a solid evaluation across their skill-set

Usually the ones who do terrible in the interview but the resume is solid. That person knows how to do their job but can't sell themselves. When they end up finding work they rely on good work.

The opposite is a great interviewer. They will have an even better resume. Rarely are the best workers but can somehow stage what little they do into looking like a top performer. Will likely move on when the going gets tough.

I'm incredibly nervous about job interviews. I'll start sweating in the first two or three minutes even over Zoom. I recently "fell into" a job because my university supervisor recommended me to a friend of his at a small business in which my only test was a code review I could do the day before. But I worry that for any future job because I'm terrible at algorithm questions, and I suspect (and I doubt this is just impostor syndrome) that I'm simply not great at algorithms, despite a small cachet of personal projects, which aren't that impressive either.

that would really only be a big competitive advantage if great people who don't interview well were more numerous than those who interview at least adequately, or if those great people were greater than the great people who do interview adequately.

I guess it would still be something of a competitive advantage though if you were a great person who got hired despite interviewing poorly you might be more grateful than those who interview well.

But anyway I don't know that anyone has the stats on how many great people interview poorly - I would of course only put myself as average, albeit lucky, and I interview poorly half the time but some times I interview really well, for some reason, and when it clicks like that I get the job. So I assume if there is hope for as bad an interviewee as myself there must be hope for all the other poor interviews out there.

Do great people really interview _that_ poorly? It's certainly possible, but it seems almost an edge case that's not worth trying to exploit. Rather, I feel the main competitive advantage would be to become better at interviewing.

Learn how to evaluate people on their skills, rather than your own personal belief on how a problem should be solved. Understand how someone is thinking and approaching a problem, instead of a yes/no checkbox. Be able to determine what a candidate's strengths are and how you can best utilize them, rather than how to fit them into a pigeonholed role you have imagined.

It's simpler. Hire people who don't suck and train them.

And, amazingly enough, you find those people generally become quite good.

Or who don't interview at all. [0]

I've seen great devs intern twice at the same company while in college and spend several years there as full time right after graduating, only jumping ships when a friend at an other company specifically reached out.

They are essentially invisible to any recruiters.

[0] https://www.joelonsoftware.com/2005/01/27/news-58/

This sounds like what most internships are intended to be?

How much does it cost to employ one of these apprentices?

Sounds like an excuse to pay people who aren't as good at leetcode less...

This makes sense and it's a wonder that most companies aren't doing it. There are a lot of people who can do the work with the right apprenticeship/training. IMO, there really isn't a shortage of people who can learn to do the work, but there is a shortage of companies willing to make the investment in people.

at the moment the comment immediately below this is advising folks to find an internship, and in many ways that's what you're describing - a role with a limited timeline and a low minimum bar, but within which some people will be able to demonstrate abilities and promise far beyond that minimum.

It's reasonable, but it doesn't always work out. One of the larger heartbreaks of my professional mentorship time was bringing in someone who seemed like they could be a "diamond in the rough" but was just unable to ever quite pull it together. Watching this person's limited successes and repeated failures and their understandable, almost always mature emotional responses, and being unable to help them get over the hump was pretty frustrating for all parties involved. I also think it was short-term bad for my career: I felt judged for putting so much energy into someone who wasn't quite working out, and I don't think that opened any doors for me personally.

So - it's still a risk! What I think is that when it works it's great, but the people doing the hiring, evaluation, and training are still taking a fairly time-and-resource intensive risk, and when it doesn't work it's no fun at all. Gives me a lot more sympathy for folks who take the safe route.

Maybe there's a paraphrase of "nobody ever got fired for choosing IBM" along the lines of, nobody ever gets dinged in performance review or passed over for promotion if they only hire candidates who can sail through whiteboard-algorithms questions.

My experience, as someone who has advocated for hiring people along the same lines, is that this is a pitch that everyone will agree is a good idea. But then when it comes time to actually hire someone under it, people will hem and haw about whether or not they have the capacity to mentor people like this.

Usually it then won't happen unless they fit a very specific "comfortable" mold of person that they believe can be a "self-starter" which usually just means someone who's similar to person/people deciding on the hiring in various ways.

I don't know how to find them, and leetcode and interview puzzles clearly aren't it. However, we've all worked with folks that get way more done than others. We've also worked with people that are a net negative for company. Your paid internship only kinda works at the entry level, and doesn't fix that the filter is broken for mid and senior level.

This is an interesting approach. My concern would be that companies too often consider their senior engineers to be purely technical and set them to work on "the hard problems," rather than intentionally setting aside part of their days for mentorship, exploration, and thought leadership.

That culture shift is going to be difficult for organizations that don't already embrace it. It's not something you can quantify easily for an executive board.

I like your approach, in fact several people when I started development truly believed that the first 2 years or so, you were only supposed to fix bugs and things like that.

The one problem I see with the approach, and this is an issue with the company not your idea, is that they don't have people to train entry level developers. Most of the senior people I've met are incapable of doing it. They lack real expertise or an ability to effectively communicate and deal with people, or they are simply burned out from it. I've seen a number of places where the senior person is tasked with doing that and it takes up all of the person's time. They get punished for being promoted to that role. Heck I can say that I did for a while too. I took a lower position so I could write code and not deal with all of the politics and stress of leading people.

Seems like a no-brainer to me. Most skilled professions provide some sort of apprenticeship track where you balance some mundane tasks with more complex tasks working with skilled professionals in the discipline to learn the trade better. You're not paid at industry high rates initially but provided a reasonable timeline for full competitive pay employment into the profession.

New and young surgeons don't start out day one on the job after six years or so expected to perform a successful open heart surgery, like software engineers are essentially expected to do. You also don't have civil engineers designing full dams or bridges on day one of their job after their bachelors or masters.

Software on the other hand thinks that for some reason, you transition from student to expert in the blink of an eye or can simply pick up what you need in a few weeks. It's completely unrealistic and businesses need to realize the value and necessity of apprenticeships and mentoring.

The problem with this though is that technology is so diverse (now more than ever) that a certain amount of skill you learn at a business is going to be non-transferable as opposed to other professions where their craft is mostly constant.

This means employees are a little less interested in these commitments because it can tie their skillsets to a specific employer if the employer isn't keeping with popular industry trends. It's also a cost employers and employees often don't want to pay in a world where employer/employee loyalty is non-existent. I think for apprenticeships to work, they need to provide transferable skills/knowledge and or provide some basis of loyalty and long term commitment goals between an employer and employee. Both of these seem like incredible obstacles in the current development climate.

I think an apprentice role with:

- a real chance and a clear path to 'upgrading' to a dev role

- generally good integration with the team (AKA not a person 'over there')

- mentoring & pair programming (for example for bug fixes)

- time scheduled for learning

Can be both attractive for an inexperienced applicant and very useful for a team. Just note that if you take an apprentice or even intern, then you have a responsibility of teaching and helping that person grow.

Also note that some of the things you mentioned, specifically QA and documentation, are quite hard to do well. There needs to be some guidance.

The danger is that people just/only give an apprentice tasks that nobody else wants to do. Some of that is fine, but I've seen people give interns/apprentices tasks which required expertise but were 'boring'. This is a failure in my eyes, because now your apprentice is overwhelmed and demotivated.

There is a shortage of talent but it’s self-induced. There is no common baseline of competency. So when talent seems rare or absent what is cheaper: waiting for talent to materialize or lowering the level of acceptance.

The problem with that is that the new lower level of acceptance only provides temporary relief for the current shortage. Later developers see this new lower level of acceptance the same way prior developers saw the prior level of acceptance and thus the bar must be lowered further because the shortage rate remains unchanged.

This is a great idea for apprentices/entry level talent. However what I see in FAANGs is that though we claim to have a shortage, the reality is that demand is low (internal headcount) and supply is high (for ELTs). The leetcode style coding interviews is very very pushed for so that we can have a standardized process whether that is what the job entails or not. After all most of the work being done is on some custom stack anyway. The downside of this it ends up impacting experienced engineers who are being evaluated on the standardized tests rather than experience sadly. I feel this may even be the desired outcome!

I'm an advocate for when it works, but it takes real commitment and effort. It takes engineers who want to mentor and see it as part of their responsibilities. It takes managers willing to mentor mentors and hold them accountable.

It takes all of that AND it takes the luxury of a company that has the excess in time and money to invest like that. Some companies don't. I've been in both companies that do and don't. When you're running a tight budget, you can't responsibly hire talent that is going to take a year to do a job you need done today.

> There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process.

I think there are ways for both of those things to be happening simultaneously. (Well, sort of- employers claim a talent shortage, but really it's a shortage of talent at prices they wish to pay.) The fundamental problems are that it's not possible to measure a broad swath of candidates' abilities, and that hiring an engineer is very expensive.

I interview people all the time who have job in "top" companies, who then proceed to do a pretty poorly in the interview. Now that could be the interview's fault, or my fault, bad luck/nerves, or at the very least you can say the interview may not provide an accurate depiction of the candidate's abilities. And I am sympathetic to that, I've been on the other side of that and I know what that's like. But the two fundamental problems remain.

We have roughly this concept in my org (field consulting for a major cloud provider). I've been very involved on the training side and on having people directly on my team. Some notes from my experience

1) We still have a pretty intense interview process. We largely aren't taking people from code camps, but people with programming experience in university but who may have not been CS majors.

2) To work, it is necessarily VERY labor intensive. I ask teams taking on of our early "apprentices" to expect to have a senior level person spend at least an hour a day with them for at least a month, and multiple hours a week for a year.

3) You need to have long timelines- On-boarding is hard with well trained with lots of experience. In my experience, "apprentices" often take 6 months plus to be value adding. For a project that will be over in 8 months, this can be hard to swallow. The program and adoption has to be driven at a strategic level.

4) The benefits of the apprenticeship program often do not accrue to the group doing the investment. If it takes 6 months to get someone to the point where there are adding value on average and then another 6 months to the point where they are more than covering their salary and cost, then they are a year into the position. We see a lot of our people choosing to transition at around 18 - 24 months in role. We just sunk a ton of time into people to get them competent, but the benefits of that training are going to another group or company and would have been better off hiring no one.

5) Despite all the above, many of the best people in my org have come through the program. Beyond just being good at their jobs, they bring a diversity of background and experience that really adds our ability to execute on problems.

I'm a big supporter of apprenticeship type programs and think they pay off in the end, but as I've described there are a lot of failure points along the way.

There's nothing wrong with apprenticeships but if senior hiring remains unfixed then what is the apprenticeship for? As long as going from one company to another is a major hardship with risks and drop out tech is not really a career path.

I think this is the way that hiring will work in the future, and companies will be slow to adapt it... until a few companies show amazing results, then everyone will get onboard, in order to lock down good results early.

Seems similar to https://www.joelonsoftware.com/2006/02/10/processing-interns...

I imagine a big part of the success of this approach, though, is that the companies have the proper orientation towards the technical apprenticeship.

So, if the technical apprenticeship goes well, of course the apprentices benefit, but I suspect the members of their teams that support them also derive massive benefit.

What a cool opportunity for less-senior developers, to play a role in helping the technical apprentices make a large impact.

I'd love to talk more about this with you. I didn't find your email address - would you be willing to share it, or send me an email at josh@josh.works?

this is a domain I've spent a lot of time on, and have only scratched the surface.

This is good for entry level candidates but how does someone who has finished this type of apprenticeship find their second job?

> a rapidly growing population of devs who feel like they're locked out due to the technical interview process.

I’m not convinced all these articles about “hiring is broken” and “interviews are broken” actually help with this problem. They are pining for something that may not exist (and may not be possible), and failing to help candidates understand and excel within the current system’s imperfections.

I get the impression that many young devs have skewed expectations and aren’t practicing job interviews before attempting them, and believe that their coding skills are the only things that should matter. The article here reinforces those expectations by repeatedly talking about evaluating competency without acknowledging that competency in soft skills like writing and communication and attitude are often at least as important as competency in software engineering, for example.

That said, I would very much agree with your approach and that a technical apprentice is a nice way for both the candidate and the company to learn about each other. Internships naturally do this without necessarily having the expectation of hiring the intern - though I’ve seen a lot of interns hired because they prove themselves competent.

One problem with a technical apprentice role as an alternative to longer interviews is that you have to expect to not hire a large percentage of the apprentices (otherwise there’s no point). In that sense, the apprenticeship becomes a much more demanding interview, and the commitment and risks are much higher for both the candidate and the company. As someone who does a lot of interviewing and resume reading and hiring, I’m not sure I would change my interview process if I hired more apprentices (but I already spend a lot of time looking for potential over experience.)

I think it’s a fantastic idea and applaud you for your work. The major hurdle is leading companies only want to hire senior devs. Why spend money and implement a training program when you can outsource it. There seems to be 3 paths in. One, go to a top 10 CS college. As a hiring manager, our internship choices were broken down by school with less than a dozen choices: Stanford, Harvard, MIT, Berkeley, CMU, etc. and a few diversity conferences. The candidates resumes where literally partitioned in folders for each school or “diversity”, so to peruse through hundreds of candidates you had to go by school or conference, with no way to see who had interests or experience in distributed systems, front-end, AI, etc. without choosing a school or conference to look through. I couldn’t believe how biased it was. Two, go work at a startup or small company for below market wages to get experience and try to work your way up to better and better companies. Three, work overseas for a couple years, pay full price for a masters in the US, and then work the H1B masters recruiting pipelines.

While there are exceptions the bootcamps seem to be geared toward path two. I wish bigger companies had training programs. I was working with a veteran who recently graduated from a local college and helping him with interview prep. He couldn’t pass the phone screen for the role I had available and ended up working for a small local consultant which seemed to be more IT focused than dev. I couldn’t in good faith just hire him without support from the team. I wish companies had training programs to hire local people into these jobs, but there really isn’t a shortage of talent that requires them to set these programs up. The shortage is in quality senior devs who could get into a top company but are willing to work for less elsewhere. Anyone who sets up one of these training programs and doesn’t pay FAANG salaries, is just training up candidates to move to FAANG. I guess in a way path two and three really are the training programs you are talking about.

And the stuff you are talking about regarding documentation, testing, etc. also sounds like other tangential roles like TPM or quality, which unfortunately are just being put on developers themselves at many places. I think most companies should have more people in these roles with the aspiration of moving into dev. Maybe a “training” role focused on this could help, but you may also run into resistance from people who are in these roles in organizations.

My previous employer did this pretty well. They had a paid internship program, but they also had started as an AS/400 shop writing RPG code, which none of the local colleges taught anymore.

So, they basically developed their own course, and kept it fairly consistent over several years. The first 20 or so hours was some computer based learning modules they had purchased to teach fundamentals and syntax. After that was a series of well documented training assignments.

For the first assignment, they'd be handed an existing report program with several bugs that they'd have to figure out. After that, they would start on a simple CRUD program that they would expand on. At the end was a capstone assignment that simulated a real project from interviewing a "stakeholder" to gathering requirements, writing documentation, and implementing the solution before finally promoting it through the change control process.

Altogether it was 150-200 hours of training, which corresponded to about 2-3 months for a student working part time.

The company recorded everyone's performance, so after the first dozen went through the program, they had a solid baseline for comparison to tell if someone was falling behind or blasting ahead. If a trainee proved they were solid, they might get to skip the last assignment. If they were horrible, it would quickly become apparent and after a few chances to turn things around, they'd be let go.

I ended up on the team responsible for running the training program. Even as the development started shifting to Java, they still used the RPG training for a long time, since it was at least a gauge of a person's ability to pickup unfamiliar tech. Part of my job was to help develop a Java version of the course to eventually become the new default.

Reviewing the assignments was kind of fun and taught me to appreciate people in QA roles. Submissions didn't have to be perfect, but they had to meet a certain level of quality before the trainee could proceed.

Sometimes someone would bomb one of the early assignments, and that was okay, even if fixing the issues and resubmitting took longer than normal to finish. The real red flag was repeating the same mistakes over and over again.

Even though the training program was created for interns, a few of the dev managers would have all their new hires, including senior engineers, go through the same program. Normally the full time hires would "graduate" early, but I know of at least one mid-level dev who didn't make the cut at all. The hiring manager was thankful to have dodged a bullet, and have the historical performance data to back up his decision when he went to talk to HR.

> There's a growing rift in software between employers saying "there's a talent shortage" and a rapidly growing population of devs who feel like they're locked out due to the technical interview process. Many of the engineers not being hired are recent bootcamp grads but there are also tons of CS majors that can't seem to "crack" the interview process.

I'm extremely skeptical of bootcamps, especially after learning that some of the TA's at these are hired to help with teaching as little as two months into the program as students[0].

I'm afraid that a lot of these bootcamps train the students on "practical and applied skills" that makes them one trick ponies. ie, they know how to do one thing and one thing only and if the project's stack change it's unclear if they will be able to adapt.

> This has been a great way to shift interviews away from algorithms and more towards finding people can add immense value to technical teams even without having on-the-job programming experience.

I'll play devil's advocate here and say that algorithms are a pretty good proxy for on-hire performance. I can, as an interviewer, expect most grads from serious CS programs to have had an algorithm class. Being able to demonstrate that they are capable of learning algorithms and applying them gives me confidence that they will be able to learn new stuff fast when joining the team.

It's a sink or swim situation where I believe that it's very hard to teach CS fundamentals on the job but relatively easy to teach new tools and new frameworks. So I would rather hire someone with strong fundamentals

[0] https://nymag.com/intelligencer/2020/02/lambda-schools-job-p...

+2 for this. Worked for me with two separate companies!

One of them I had an internship and they never told me to leave, so I just kept working (and getting paid) until eventually they hired me full-time!

I've seen internship to offer rates exceed 80% :P

Lots of Big Tech is in that general range. I actually don't know of any top companies where the offer rate is ~30%.

My company (defense contractor) has a goal of hiring more than 50% of our interns.

In most of Wall Street, internship to offer rates effectively start at 100% but some people during the course of internship manage to cause the employer to rethink the offer, so the final result is anywhere between 90-98%

Well, not at JPM, but most everywhere else.

I'd go so far as to say, at least within tech, your primary goal during undergrad is securing one or more internships.

I look at internships before grades and the school.

When I interview fresh grads, if they have internships, that's what we talk about.

When I have interns on my team, my goal is to hire them. At one large tech firm I was at, we had a goal of hiring 50% of our internship pool. It was the primary way we brought in new talent.

30% is very low for big companies, I’ve never heard of somewhere being lower than 50% and 75-90% seems more standard (though offer does not necessarily lead to an acceptance).

This message is expressed very well here [1]. Tl;dr internships are helpful to students for a variety of reasons, like making applicants more valuable to employers, making programming less of an abstract concept, and exposing them to interesting subfields of computer science.

[1] https://getatechinternship.com/2020/04/27/why-do-i-need-an-i...

Unfortunately, this has two sides.

I've noticed that in banking - and I'm not talking about investment banking, or high-finance in general, but regular consumer banking - there's been a trend to basically hire woefully overqualified people for the lowest positions around - I'm talking about bank greeters, customer support, and what not, and then train them from there.

This could very well be a local thing, but there are so many people today qualifying for these jobs - lots of BBA and MBA candidates out there, willing to do pretty much anything to get a foot inside.

When I was interning for a bank, even the greeters (basically the person that just greets the clients, and forwards them to the right people within the bank - a receptionist, really) had a Bachelors degree, many were working on their Masters.

The more sought after positions had been re-labeled "graduate programs" or "trainee programs", and were aimed at the top-shelf students. While the rest pretty much had to get a foot inside by working their way up from the bottom.

So you suddenly have a ton of highly educated candidates applying for jobs that only 15 years ago required a HS diploma, if that even.

Then when they're first inside, they tend to get moved around internally - as a lot of positions only get posted internally.

It's almost the same way with internships. Internships are there to practically train and select future company workers. If you do well, you get a return offer - if not, well, at least you have some experience.

With the rising number of graduates, I can foresee a future where candidates are being divided into the regulars and the elites. The regulars will, no mater how qualified they are, will have to start at the rock bottom, proving themselves for $8.5/hr, while the elites are trained for leadership/management-track positions.

Ok, we'll replace it with some of the mud in the headline above.

How would a trial period work?

Someone always suggests this. The issue is that if you did this, 95% of the candidates that would agree to this kind of setup would be the kind you didn't want.

If I'm sitting on 2 offers, one is a hire and one is a "Let's see how this works out after 2 weeks of work", I'm going to take the first one. And that says nothing for the necessary benefits question in the states, where changing jobs often involves expensive (in money or time) changes to health care insurance.

As a company you're also competing against other companies for hires. Good candidates can get offers from multiple companies. If you're going to tell candidates to make an opportunity cost sacrifice of several weeks of work just to the the possibility of an offer then you better be offering something extremely valuable to the candidate. Otherwise why would the candidate take the chance on your interview process if they can secure an offer from other companies without paying the opportunity cost?

The result is that this interview process will likely only be pursued by candidates not able to get offers from other companies.

> In an ideal world a trial period would ensure both the employees and employers are a fit. But that could be abused as well if it becomes the norm.

I was talking to our work HR director about this and given that US is mostly "at will" employment, either side could decide to end the employment at any time so a trial period doesn't really mean much. Secondly its hard on the employee if we let them go on short notice so we try to hire from a long term perspective.

In an ironic cycle, many employers also market their services and products in this fashion - over the top marketing, fake enthusiasm for the customer, over-selling features, constant talk about "community", virtue-signalling with social media posts on hot button political topics, etc, etc. To be sure, I'm not saying everyone and everything is fake, but it's interesting to just climb out to the bank, clear the clutter and just observe how the river flows.

> It's a sad that we can't be honest or humble but in this system we have to sell ourselves, fake enthusiasm for the hiring company is a must, do whatever it takes to pass the interview then think later if we take the position or not. If not, somebody else with the same capability or or less will snatch that job.

As someone who’s given hundreds, maybe thousands of interviews, personally I would advise against this. Being fake about your interests is not more likely to help you get the job you want and one that fits you well, if it even works at all. Being honest about your interests with yourself and your potential employers is the best way to end up being where you want to go.

You can show excitement for specific topics that a company works on, and it’s okay to like the company’s products, or their work environment, but people who are enthusiastic fans of a company without specific reasons to want to work there are, in my experience, not more likely to get hired.

> Plus that interviews like tests are gameable.

This is true, and it’s good to understand so that your expectations don’t go crazy. You are competing against other people, and you have no idea how good they are. All you can do is your best.

In the U.S. you can be fired for no reason, so the hypothetical trial period is basically just hiring people without interviewing them and then firing them as soon as you realize you made a mistake.

> The next best interview would be a portfolio.

I tried using my (limited) open source hobby project portfolio as a substitute for coding interviews. Companies either didn't take me up on it, or still also required me to do their regular take-home. Twice now, I have had two companies ask for the same take-home, although in the first case they asked me to re-do the work in their preferred language.

I imagine a good compromise might be a small piece of "contract work" where a company presents a small representative task as a project for a candidate to complete and the candidate actually gets some form of compensation for their time. There are definitely problems to this approach, but in a best case scenario, the result is a win-win situation even if a candidate doesn't get hired. At the moment every candidate that doesn't get hired represents a net loss for both parties (time for both and opportunity for the candidate)

> All these "competency tests" are good for is catching blatant lying. Is this a serious problem?

Of the people I interview that claim they have years of experience, mastery over multiple languages, and expertise in various frameworks, a solid 80% or more can't pass fizz-buzz in any language they choose.

Agree on the test stuff. When talking to someone who can goes deep in details you mostly know that he's not a lier; then you have the trial period to fire him if he is.

> Is this a serious problem?

You would be astonished, absolutely flabbergasted, at the number of "senior engineers" who interview well, talk great about projects, but cannot demonstrate basic programming skills (e.g., convert an integer to a string representation, or write fizzbuzz).

Competency tests have helped me get in the door.

That said, they seem to work best when they're part of an overall interview process. I think it's a mistake to look at only the highest scores and interview those people, they should only weed out the bottom scores and follow a more typical (do they fit? can they learn it?) process for the rest.

> Why would a practical test be more effective than a discussion about prior work experience? Short coding tests under pressure are extremely unrepresentative of real work and I'm not sure homework-style interviews are much better. I personally don't want to spend an entire weekend on your test and I've dropped opportunities for that reason in the past.

These are good points, and the tests I have given are specifically designed to avoid these issues.

Personally I do this:

* Come up with a simple but realistic 1 or 2 hour task, and write up the request in plain English (do not write a tech spec). It should be task you'd expect anyone to be able to easily do on day one without any assistance.

* Include a short narrative about the end user that clearly implies a specific requirement or two, but don't spell out it out as an explicit requirement.

* Omit a small but important detail that any reasonable person would ask.

* Instruct them to provide a solution to the users problem, and ask questions if something isn't clear.

These are pretty simple to evaluate too:

* Does the code run? (i.e. can the candidate write basic code?)

* Does it meet the user's explicit needs? (i.e. can the candidate follow basic instructions?)

* Does it meet the user's implicit needs? (i.e. does the candidate write code to spec, or do they think about the bigger picture?)

* Did the candidate ask a question about that obvious missing detail? (i.e. does the candidate speak up, or will they make assumptions?)

You would be surprised with how many people don't have the ability to apply their ability to write code to solve simple problems.

> All these "competency tests" are good for is catching blatant lying. Is this a serious problem?

It absolutely is, there are plenty of companies who have no staff capable of verifying a candidates technical abilities

Hang in there. I have a friend who's in a similar position, she's interviewed and been ghosted a few times and it has really gotten her down. It can take time but eventually a company will come to their senses and realise your value.

> because if they don't live up, it's a simple conversation to refer back to the expectations that are set and help them achieve , or worst-case, offer them severance.

That is a bad hire. You are describing a PIP and then firing someone that you wasted time and resources recruiting, on-boarding, and training.

> I can understand social filters when it comes to friendships, sex and intimate relationship, but for jobs, I will never understand why they exist.

Because jobs are just as social as intimate relationships, if not more so. Up to about the 2010s, the majority of marriages came from getting to know someone at work.

Even if nothing intimate does come from work, it's still people you have to see 8 hours a day for years on end. If someone is repulsive/annoying/toxic, it WILL make you miserable at work, and people are very wary of disrupting a well-oiled collective.

Nice analysis.

In my hiring process, we use a number of filters to gather the data we're looking for to make a decision. That requires a bunch of different steps. By the time we're done, we've spent at least 8-10 hours talking with this person.

From a technical perspective, we do the following:

- A short screen to go over the resume and ensure we've got a rough fit to the right role.

- A simple consistent coding exercise using coderpad. (surprisingly some fail)

- A series of consistent open-ended questions we ask everyone about their tech background, such as, what was one of the most difficult bugs you ever fixed?

- A set of consistent design/architecture problems: "given this design, what problems do you see? How would you fix them?"

- Another consistent, more involved coding exercise with an existing code base that is VERY much related to the work they'll be doing.

- A Q&A session on a wide range of technical topics. Goal is NOT for someone to know everything, it's to get a bit of map of their strengths and weaknesses. We found we make assumptions of what someone knows based on our background and their resume. We try to make this fun.

- Another set of behavioral and situational questions with a shared scoring rubric on values such as teamwork, collaboration, communication and leadership.

And then we have to take all of that data and look at it holistically and across a wide range of candidates. And even then we'll make mistakes, but we keep trying to optimize it, reduce bias, and make it better for candidates and us alike.

One last note: I like to finish my first interview with the question:

"Is there anything about yourself that you really want me to know that we haven’t discussed?"

Because I know I've only had ~40 minutes to get to know this person. I have my agenda of what I want to know, but I could easily miss a lot. So I want to give them a chance to represent themselves in the broadest way possible.

Yikes, I don't know about that. If somebody asked me if I could program in, say, Perl, I'd say I knew what it was but that was about it. That's like somebody asking if I can speak Chinese: I know what it sounds like, but no, I can't.

But on a serious note - if some interviewer ask you outright "Have you programmed in [x], and what's your opinion on it?", try to be positive.

I used to be very honest about my opinion on languages, but my experience is that if you start being too honest (on the negative side) regarding some language you're being asked about, it will have few upsides.

For whatever reason, some devs. are very personal about the tools and languages being used, and will even get hurt or agitated by criticism.

So whenever I get asked about that now, I just try to come up with the positive things I enjoy about [x] language.