So... you've 1) realized you're dealing with experienced people and 2) yet discarded them based on irrelevant "interview skills"?
How does this serve the company trying to hire someone?
FWIW, the couple of times I've interviewed someone -- I've always given the guy a 2nd chance if I've seen he's obviously nervous or just not on a good day, but has the material. Even an autistic nerd like myself can spot that and have the common decency to look past trivial human weaknesses.
Besides, I'd rather pick a genuine human being as a colleague rather than some overbearing, over-social, potentially arrogant prick whose competitive urges are liable to disrupt technical decision making down the line. Those types belong in the suite & tie department, not in tech.
Part of the reason is standardisation. There is lots of training given to avoid bias. I think you’ve misunderstood what the parent meant by interview skills. The criteria don’t select for social skills (beyond the basic), but rather for algorithmic skill. However, most day-to-day development will not require as much of it, which is the parent’s point.
I think most people are aware that the system is not perfect, but the process of determining the metrics (as far as I understand it; I’m a fairly new interviewer) is pretty data based. It’s been optimised to hire people without relying heavily on the interviewers all being very experienced (because that doesn’t scale enough for FAANG).
The metrics are known. However, their weights may be unknown.
What is missing from the interview process is actionable feedback.
Some firms provide practice interviews (for pay) with detailed feedback.
The interviews are designed to evaluate algorithm & data structure knowledge and proficiency. Most experienced software engineers have not kept up to speed with such knowledge since they were in school. It is not their fault, as most jobs/projects don't require maintaining such knowledge in order to be effective on a day-to-day basis.
N.B. The interview firm I worked provided the option for a second interview if the candidate believed that the first interview did not provide an accurate assessment of their skills.
In any STEM profession, one's academic knowledge "expires" in 5 years or so. Continual learning & practice (incl. interviewing skills) is a requirement to maintain employability in a field.
> most jobs/projects don't require maintaining such knowledge in order to be effective on a day-to-day basis.
This is common knowledge to any developer - you really don't need the academic angle most of the time.
So... how does rejecting on that basis serve the company trying to hire someone?
One way to describe the rationale is that the hiring firm is hiring for 2-sigma capabilities versus 0-sigma or 1-sigma capabilities.
The ability of a software engineer to "shift gears" to the 2-sigma skill set when outlier conditions (e.g. debugging rare events, performance issues et cetera) occur is a form of insurance against having to contract outside resources.
N.B. I am one of those outside resources that gets called in when none of the FTE staff can resolve a difficult (aka "burning platform") problem.
It really doesn't take much effort. Non compliance to this kind of interview BS would make at of these unfair practices go away.
If you are searching for your next position out of need, then you are not special. The employees who can afford to have egos are those who are being recruited.
Only counting those where i got all the way to the final rounds, my sample size is roughly 15-20. Not even once have I encountered anything even remotely similar to the Criteria Cognitive Aptitude test, and neither have I heard of it from friends of mine who were interviewing as well. I had a couple “take home programming challenge” things as a filter before the initial interview, but they were either leetcode-like or project-based, not some diet coke version of IQ testing.
With that in mind, it seems blatantly wrong to say that “this is everywhere these days”. Out of curiosity, what type of companies did you encounter that tested you with a cognitive aptitude test? No need for company names if you arent comfortable sharing, just curious about what type of companies those were (e.g., small startups or big tech or non-tech big companies or etc.).
This is so wrong. Headhunters are acting like typical bureaucrats and instead of adapting their approach to make it better at finding the actual talent (the whole point of their job), they push for developers to fit their stereotype tests better.
Just like back in the school when we had to learn what professors want to see in essays, instead of learning to actually write better...
The interview requirements & assessments are driven by the hiring companies and not the headhunters.
Scaling technical interviews of this kind has created $1 billion companies recently.
Technology employers want an unbiased assessment of a candidates skills - like any other firm.
And it's exactly what drives the bureaucracy, the transfer of responsibility. All you need to do is blindly follow the request in the most defensive possible way and no one will ever be able to accuse you of screwing it up. So you have headhunters who just follow the clients' briefs, client's HR follows their playbooks to cover their asses, and as long as they all get paid in the end of the month, who cares if you miss to hire some really talented people. It's developer's mistake, they should have prepared better for the test.
And I'm not trying to accuse anyone here of being guilty in particular, just to point that the whole process of hiring is deeply flowed by the very design. On the brighter note, it motivates a lot of really smart people to stay out of big corp world and go indie, which is actually great...
Some firms provide take-home problems/projects - typically with a time limit. Their objective is to provide a more realistic scenario for writing code while evaluating the candidates technical skills.
It seems that -- to use some old AI jargon -- the difference is between "forward chaining" vs "backward chaining". Forward chaining is all about the set of tools and techniques to work towards a variety of problems. Backward chaining is all about starting from a specific problem and and curating the best tools and techniques.
Very experienced programmers will have spent most of their time Backward Chaining. New programmers will have spent most of their time focused on Forward Chaining.
Here is where I see the disconnect: it may take days to learn a new tool or technique. However, it can take years to learn how to curate the best tool or technique. Long term thinking is undervalued.
CS 9: Problem-Solving for the CS Technical Interview
What are those start up skills?
Understanding the problem
Stating one's assumptions
Verifying one's assumptions
Selecting a data structure appropriate for the problem
Selecting or describing an algorithm appropriate for the problem
Selecting test cases appropriate for the problem
Writing the code
Verifying the correctness of the code
Understanding & communicating the time & space complexity of your solution
N.B. IMO, the best programming language for technical interviews is Python. It provides many built-in data structures and methods that make one's solutions brief and eliminate the need to write a lot of boilerplate code.
>It provides many built-in data structures and methods that make one's solutions brief and eliminate the need to write a lot of boilerplate code.
Could you name some? the most important / handy in your opinion?
vector/list
dictionary/hashmap/hash table
queue
priority queue
heap
Methods/Algorithms:
min/max
insert/delete
contains key
list comprehension
N.B. I've done most of my interviews in C and watching me code has been referred as "watching paint dry" because of all of the boilerplate code that I have to write.
C# has all of this + LINQ (very handy list comprehension?)
Java probably too + it has streams
Idk about other
Many do. However, ease of use is an issue.
Some interviews don't allow you to look up the names of types & methods nor use IDEs that provide pop-up lists of types & method names.
You have to everything in a basic editor w/o IDE support.
Those two algorithms are the workhorses of graph algorithms.
Advanced graph algorithms include Dijkstra's algorithm, Minimum Spanning Tree, Strongly Connected Components, among others.
In addition, dynamic programming (DP) also shows up as a more advanced algorithm/technique in high-level interviews.
Unbiased assessment of candidates for "apples to apples" comparisons
See if the candidate has skills deeper than typical day-today skills that can called on if needed
Demonstrate an understanding of performance trade-offs that have profound economic impact on the delivered solution(s)
Demonstrate the ability to create solutions beyond "textbook" solutions when required
Screen out quickly candidates who lie about their technical capabilities on their resume
I hope the above list is useful and/or helpful.
In addition, you must reboot your interviewing skills. I've been a professional software interviewer (600+ interviews) and have seen most very experienced software developers do quite poorly during interviews. The interview skills required for FAANG-like companies and startups alike are very different from the skills required to work as a typical software engineer.
The interview is the gateway to getting the job. As such, good or great interview skills (i.e. algorithms, data structures, time & space complexity) are a pre-requisite to getting a job.
I hope that the above advice is useful and helpful.