Hacker News Reader

Comment by icsa | Hacker News Reader

The churn rate of current software development practice is quite rapid. When you took several years off, you "fell out of the job market". In effect, you need to reboot your skill & tool set to make current.

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.

View on HN

> I've been a professional software interviewer (600+ interviews) and have seen most very experienced software developers do quite poorly during interviews.

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.

Interviews at FAANG don’t really work like that. The typical interviewer has very little say in metrics used to evaluate the candidate. Their job is to evaluate the candidate based only on those metrics, with little room for anything else.

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).

Also the 'metrics' being used to make the final decision are secret, most likely not known even by the interviewer. This prevents gaming the system but the lack of transparency makes it easy to imagine that MANGA companies choose new hires the same way that South Park depicted the FED making economic decisions: with a headless chicken running around and finally falling down on a big diagram.

> How does this serve the company trying to hire someone?

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.

Like you said,

> 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?

> 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.

If you "have seen most very experienced software developers do quite poorly during interviews" then you are the problem. Change the way you interview.

+100

thanks. that is a good observation. tomorrow i will be talking with a meta recruiter who has already emailed me that i am "100% what they are looking for" ...but ... maybe would you like passing these coding tests first???

WTF! It's your job to find people who can do the work. It is NOT the applicant's job to fit your preferred interview design. Talk about arrogance!

It's a description of reality. We can agree the situation is unfair, and that the big companies show an arrogant approach, but if you want to get hired you have to conform to what is asked and expected.

I get what you're saying but this attitude is what essentially says "Developers are ok with this crap so keep doing it please". Or, in other words, you say it's unfair but then participate anyways and whatever you say no longer has value.

It really doesn't take much effort. Non compliance to this kind of interview BS would make at of these unfair practices go away.

Maybe it is his job to execute the interview design.

Absolutely! You get fired if you don't. The hiring firm wants a quantitative & unbiased comparison of all candidates.

I take it you have never heard about the Criteria Cognitive Aptitude Test (or similar) that every candidate has to take nowadays even before being invited for a technical interview.

I’ve spent past 2 years interviewing at all sorts of companies (from FAANG to small startups to fintech) while working at my current place, and just recently accepted an offer.

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.).

If an applicant needs the job more than the company needs that applicant, then yes it is the applicant who will have to blink first.

There are thousands of people looking for jobs at any particular moment who "can do the work."

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.

> As such, good or great interview skills (i.e. algorithms, data structures, time & space complexity) are a pre-requisite to getting a job.

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...

absolutely on the skills evaluations! delivering code cant be summed up on a spreadsheet

The technical interview is designed to be a small-scale exercise in delivering code.

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.

> 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.

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.

> The interview requirements & assessments are driven by the hiring companies and not the headhunters

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...

> I've been a professional software interviewer (600+ interviews) and have seen most very experienced software developers do quite poorly during interviews.

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.

For additional information regarding current technical interviews please refer to this class offered by the Stanford University Computer Science department:

CS 9: Problem-Solving for the CS Technical Interview

https://web.stanford.edu/class/cs9/

> 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.

What are those start up skills?

I was referring these common interview 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.

I don't see anything special in this list

>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?

Data structures:

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.

It feels very standard, don't all language have it in their standard libs?

C# has all of this + LINQ (very handy list comprehension?)

Java probably too + it has streams

Idk about other

> It feels very standard, don't all language have it in their standard libs?

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.

dont forget graph theory. FB caught me off guard on a takehome project which involved contact tracing (very timely in 2021) Dyjkstra's algorithm (spelling?) and backward tracing through graph nodes

Yes, I forgot Depth-First Search/Traversal and Breadth-First Search/Traversal.

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.

Excellent list, thank you!

I agree, we interviewed some potentially skilled people that just didn't interview well. Even when I interview, I must have someone give me several warm up interviews.

you are right, but maybe if they asked me "whats your best area"? and then asked me to do something imaginative in that area then perhaps that would reveal more of a developer's talent than mere algorithm testing...??

IMO, the reasons for algorithm testing are the following, but not limited to:

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.

Reply on news.ycombinator.com