I tend to follow the same pattern when I do the interviews. I agree that the technical part can be easily taught if the candidate has proper engineering foundation.
But I still ask technical questions. But only on the technologies the candidate did put on his resume. I want to check if the candidate understood the technologies he used.
After that I ask a more logical question. Not especially a real-life work problem. Like Sebastian Gebski says, it is more to see how the candidate reacts towards a problem and how he tries to solve it. I always start this exercise by saying to the candidate that there is no good or bad answers and that I want him to talk to me like if we were two colleagues trying to solve the same problem. And of course I help the candidate when he's stuck. The goal is also to assess his communication skills, which is a very understimated skills amongst developers.
I like the idea of asking tech questions based on the tech listed on candidates resumes. And, sorry to call you out, but I feel a duty to point out your use of gender pronouns.
I recommend using 'they/them/their' in place of (s)he or 'he/she' as it flows better for the reader. For example... see how the candidate reacts towards a problem and how they try to solve it.
The reason that people now prefer "they" instead of "he" is that it causes a bias towards a gender when discussing things. If you're talking about something that has typically been male-dominated, it's kind of unfair to use "he" when talking about unknown people. So people prefer the use of "they" now, even though it's supposed to be plural. English just doesn't have a neutral pronoun otherwise.
Your English appears better than most native English writers, so while the tip given is valid, you should feel confident in your skills. Even re-reading for tell-tale signs, I’d have not guessed you weren’t a native speaker if you hadn’t mentioned it.
Teams need a portfolio of brains optimised for different and often complimentary workloads. Try to figure out what mental workload the candidates brain is optimised for and if it’s a fit for your team.
If you’re going to war and recruiting infantry. Some people can lift 200 pounds easy but can’t run half a marathon. You likely want both types on your team.
I wouldn't want to go to war with squads where half of them can't carry the standard load and the other half can't keep up with a day's march. That seems a recipe for getting team performance down to the lowest common denominator.
Certainly you need to have a baseline for capabilities. All teams have specialist roles be it infantry, sports or software.
A better analogy: the guy who wins the Nobel prize is not necessarily one who churns out the most papers. You could consider each type a speciality and you want both.
Soldiers are largely cannon fodder. The system is designed so that they can be easily replaced if they die, which they inevitably do in war. I don't want to die at the keyboard, that's not the kind of workplace I want to join.
Every time one of these interviewing posts bubbles up I skim it to see if the author mentions things like: company size, team composition, the nature of the work the team is doing, the nature of the industry the company exists in, the way hiring decisions are made, the desired properties of their hiring process, their offer rate, acceptance rate, turnover rate, the amount of time positions tend to stay open for, or really just anything that would offer some context on what, specifically, their interview process is optimized for or achieving.
Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.
By the way, when you're doing something nebulous in an interview like seeing "how the candidate thinks" what you're often doing (all too frequently without realizing) is looking for justification for a decision you've already made based on whether or not you like the candidate. The fact that you have them writing code on a whiteboard doesn't instantly make the whole thing an objective process.
EDIT: You can test the above by making a "prediction" about the candidate's performance after the intro and comparing your prediction to your final decision after the interview.
It seems like you might accidentally be testing your ability to predict their ability to solve the whiteboarding problems given their resume.
As an example, at one company we noticed that applicants with a certain level of educational achievement were dramatically less likely to be able to solve the problems we used than candidates with slightly higher or slightly lower levels of academic achievement. So if I made predictions about candidates, that's one factor that would influence my prediction, but it wouldn't necessarily mean that my subconscious bias was causing the candidates not to come up with a BFS.
I could've phrased that better. You're making a prediction about your ultimate hiring recommendation, not about whether they complete the problem or answer your questions correctly or not. The point of this exercise is not to produce useful data but to draw your attention to your own decision-making.
> not to come up with a BFS
But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
Sure. At some other company, I interviewed a bunch of candidates in a section that was mostly about knowing how the protocols we dealt with work and how one might build a toy version of the software we worked on. For a section like this, it's easy to help candidates too much or too little, or to let one's preconceived notions about the candidate color one's recommendation too much. I am again concerned that I may have some actual ability to predict the candidate's performance (to the extent that people's knowledge of protocols and understanding of how to write server software exists as a real thing rather than a thing that I made up) from their resume, but now I additionally worry that as far as debiasing goes, just making predictions and comparing them to outcomes will not be doing nearly enough. I would prefer not to have such a section, but I am usually not in charge of these things.
> But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
I did not say that the interview process at that company was my favorite or was the same as the one in the OP.
That said, my experience as a candidate at FAANG and smaller-but-not-super-small companies has generally been that I must at a minimum solve the problem, and that sometimes I must also solve it exactly the way some rubric says it is to be solved, so that providing an unusual approach that uses half the space and just as much time as the best approach the department has heard of also causes one to fail.
To be a little more precise: unless you're going into an interview totally unprepared, there is a résumé that you've read, hopefully read carefully. I make a decision, based on said résumé, whether I would like to hire that candidate. Maybe "decision" is too strong a word. Hypothesis. Yes, hypothesis is better.
That means I have some sort of mental model of what the candidate might be like, what they can do and whether and how they fit.
If the person is invited for the interview, the hypothesis is "yes, I would like to hire this person".
The purpose of the interview is to try to disprove the hypothesis. If you fail to disprove the hypothesis, hire the person.
A lot of companies instruct their interviewers to "default to no" when making hiring recommendations. Effectively the opposite of what you're suggesting.
I knew a lot of interviewers at those types of companies who wouldn't bother to read resumes, either. They'd cite "bias" or something.
I recently applied to the Civil Service in the UK and they asked me to produce an anonymised CV, namely remove my name and contact details
In principle I like the idea but I think they should ask to also remove the company names and perhaps dates, as it could be straight forward to work out who you are based on companies and dates.
As to how effective to remove bias, it's hard to say as I've not seen any A/B testing done with this, but give the massive push to get minorities on board, I'd hazard a guess that it's not as effective as they had hoped
> "default to no" .. opposite of what you're suggesting.
Not necessarily, just depends on how easy/hard you set the bar for disproving the hypothesis. It also is somewhat inherent in that you really are trying to disprove the hypothesis.
On the other hand, if, after reading the résumé, I do not want to hire this person, why on earth should I go on to interview said person?
The "default to no" part is, IMHO generally correct, because false positives are a lot more damaging/costly than false negatives. My perspective may be warped here, because I have worked for companies that get LOTS and LOTS of applicants. At some the team would screen hundreds of résumés a week, of which maybe 1-2 were somewhat interesting, and that was after the HR screen. Oh, and I also got to clean up after one of the candidates → colleagues I said no to and the rest of the team approved... ¯\_(ツ)_/¯
I think the oft-repeated adage "A players hire A players, B players hire C players" kind of falls into this.
"A" players want to hire people better then themselves who elevate both themselves and the team.
Not getting into how most "B" players see themselves as "A" players (dunning-kruger?), unconscious biases, or people who are just bad at playing interviewer (esp. people who have done it a certain way for their entire careers and are unwilling to even think that a different process might yield betterresults).
Don't you find resumes incredibly low-resolution? "4 years of Java experience" seems... Just not that predictive of ability. Could mean they're great, it could mean they're a disaster. Many people with 2 years experience will be significantly better (& cheaper), because they put the work in to improve faster.
Most resumes say more than that, though: they'll tell you where the person worked for those 4 years, and give some indication of both the type and level of work they did.
If I were hiring for a position that required X years of Java experience, and saw a resume that said "X years of Java experience" (or even "4X years") without any further elaboration—no section of actual work experience—I'd be, at best, deeply skeptical.
I mean I was being hyperbolic. My point is, none of that stuff is high-resolution information. It doesn't strike me as a reliable proxy for ability. And we all know that! Blindly hiring off resumes (let's assume we've filtered out all the people who outright lied) would be a disaster.
You pass on the resumes you don't find interesting, and yes, that's probably most of them. At that point in the process, it is the resume writer's job to make their resume interesting, not the reader's job to figure out what about this blandness might be a hidden gem.
And if that leaves nobody, you keep looking. One company I was at that was pretty good at hiring would much rather leave positions open than hire "the best of the current lot". Other companies were the other way around, and ended up with much lower quality.
And certainly if "N years of X experience" is all there is it won't be particularly interesting. Pass.
If you have improved faster, there should be work that you've done that you can reference, know-how you've amassed that you can assert you have (and I can somehow check). And if you've done the work of someone with 10 years experience, but you've only been at it for 2, yes, that will be noticeable. Very much so.
So make your resume interesting. Without going beyond what is there. One candidate had as his headline that he was a "Software Architect". Cool! First, very obvious question: "So what's Software Architecture". Stammer...stammer...and then after a while some random buzzwords about "best practices".
Now obviously there can be various different answers, and while I have my preferred and that one is obviously correct (Hah!), you should at least have something reasonable to say there if you make that the headline of your resume.
Ok, but every other company is also thinking this. If you only interview candidates who are exceptionally good at advertising themselves, you're selecting for applicants that are harder to hire relative to their actual abilities. The valuable talent is better than they seem on their resume. Do you not worry about identifying that?
Like, the "it will be obvious" thing... I'm just not convinced. Sure, if you speak to someone you can tell pretty quickly, but on a resume? What concrete evidence would you expect to see from someone who's only been in work for 2 years? I can think of a lot, but not much that you could convey in that format.
> The valuable talent is better than they seem on their resume.
Don't really think so. Don't confuse "plain" with "uninteresting".
I remember coming across my dad's resume at some point. It was plain as heck, but included such choice sentences as "Experience leading a national car manufacturer" (paraphrased). Ahh. Tell. Me. More.
> Do you not worry about identifying that?
Not particularly, no. First, I don't really believe that this is true, second, I worry a lot more about false negatives than I do about false positives. Third, it's really not that hard.
> Sure, if you speak to someone you can tell pretty quickly, but on a resume?
That's why you have the combination: the resume tells me if the person is interesting, the interview tells me if that was actually true.
> I can think of a lot, but not much that you could convey in that format.
Why not? Unless you're mixing up the two (again). I also see that I couldn't convince someone that I am interesting on the resume (in a "beyond doubt" fashion). But that's not the resume. That's the interview. The interview is about triggering interest.
I think you're making this harder than it is.
Heck, just write: "After only two years on the job I was doing the work of people with 10 years seniority". There, done. Interesting? Definitely. True? Well, it better be, and I am going to see if that is true to my satisfaction.
After all, it could be that the people there just sucked.
This is how I do it too - normally I'll take a thorny real life issue we've just had and decouple it from extraneous things I don't want to test and use that.
I'm intensely suspicious of people who believe that this isn't possible.
One company asked me to find a bug in a library in a language of my choice out of a small list of languages in a bit under an hour. So I pick a language from a list of languages none of which I use regularly, and until the interview I was not sure which of dozens of combinations of tooling will be used by the project. It seemed like a reasonably sized bug that someone who was not worried about time pressure and had worked on a project tthar used the same tooling could reasonably do in the time given. So I failed, and I passed comparably difficult sections at other companies that I did not want to work at as much.
> So I pick a language from a list of languages none of which I use regularly, and until the interview I was not sure which of dozens of combinations of tooling will be used by the project.
It seems an ok technique, if you understand that the person does not use those languages, because maybe what you are testing is how well they approach something they do not know anything about.
I had this happen to me in one interview https://news.ycombinator.com/item?id=13295212 using Python which I didn't know very well. Despite it not working out I thought it was one of the better interviews I've had.
An hour. It's important to test your interview with people whom you know should pass as well though.
If you give it to somebody you know you'd want to hire and they take 4+ hours to do a 1 hour task that's kind of a red flag. I'll bet your company didn't test their test.
"mainly to check the chemistry between a potential new-joiner and the team members"
"Chemistry" is just an excuse to allow unconcious bias to run rampant IMHO. New hires shouldn't need to enforce the existing culture of the team you have by matching it.
They should be adding to it, not neccessarily emulating it.
right. So when you’re done throwing the algorithm on the board, the candidate either implements it from memory because he’s a new grad from college, or has to deal with the overhead of communicating fending off your questions and “helpful” suggestions. It’s annoying and random and and gets you less interesting of candidates on net.
I swear, I was just dealing with this a week ago. “Excuse me, Mr. Interviewer. I can either answer your questions about what’s going on here or attempt to fix the last let of this code. Which is more valuable to you?” Proceeded to use silence to fix code. Puzzle solving uses the uninterrupted brain.
And just the other day, I had the SQL schema question to design a schema … for a calendar! Worst interview question I ever experienced, honestly. Nearly no one designs calendars and they’ve got lots of ways to trip you up because recurring events are exciting. (Also, when I did design something decent with two tables and was asked to query both with a single SQL statement my interviewer didn’t understand UNION but that’s another matter.)
I like take home projects augmented with short exercises to verify that I’m not a plagiarist who’s incompetent at code. If you want to assess my puzzle solving capabilities let me play a Zachtronics game like SpaceChem or the like.
I gotta ask... are companies you're interviewing with expecting you to have memorized particular algorithms? Or to be perfect with syntax?
In my most recent round of interviews, I found almost no one expecting me to recall a particular algorithm and implement it for a solution to a problem, but I did find plenty of questions that involved dealing with data structures, and writing my own code and algorithms to solve those problems.
Maybe I've been fortunate with not having been asked questions like "implement the quick sort algorithm"?
In this case it's a "distance between two employees in an org chart", which is basically a trivially modified closest-common-ancestor algorithm. The complication was that there was no ability to index into the tree at an employee and climb upwards, and they didn't want to incur the overhead of building that at the start.
That's fine in and of itself, but when I'm having a bit of a time pruning the common-ancestor paths, I want to use all 7 brain-registers for the problem instead of devoting 2-3 for communication, or, worse, having to flush everything from cache to analyze and respond to your "hint".
"is (s)he actually having fun (when solving challenging problems)"
I don't know about anyone else, but for me personally, it's a bit difficult to have fun when I'm unemployed and need a paycheck.
You might even say that interviews are testing for how financially secure you are. You can only truly relax during a job interview if you don't actually need the job.
Too relaxed might make you not care if you get the job, and not willing to put up with the typical hiring interview's little irritations - which was what happened to me last week .
At my company, we interview a lot of intern / newgrad candidates who are also considering careers in finance. The less these people know about what "real work" in the tech industry actually consists of, the better our chance of closing them. The main goal of the interview is to present a fun puzzle that will make them like us.
I don't know, my main question these days when interviewing someone is "how effectively can you turn money into work?". I don't care if you're having fun, I don't care if you're motivated by the company's vision, I don't care if your work is your hobby[0], I care about what kind of impact you'll have on the business.
Telling me "I will come in for 8 hours make things you want made, the way you want them, for money, and then go home" is fine by me.
[0] Some of these are bonuses or predictors of general suitability sometimes, but none is a deal-breaker.
> That's why my interviews are aimed to check how does the individual think (instead of verifying her/his memorization skills). How does (s)he approach problems, split them, classify them, explore possible solutions? When does (s)he abandon the path that doesn't look promising anymore? Is (s)he able to effectively share her/his thoughts (verbally, graphically, in code)? What about focus - does (s)he navigate in terms of a given goal or roam chaotically around?
This sounds a lot like system design or leetcode-esque interview questions, which is the trend among tech companies in the US.
> The problems candidates are facing at my interviews usually have NOTHING in common with the company's domain, BUT they have a super-low entry level (e.g. they are about common problems everyone encounters every day): building up the context takes seconds (literally), so the candidate can focus on tackling the problem, not understanding its basics.
Are they system-design questions? This post could use some examples of interview questions the author has asked.
49 comments
[ 3.4 ms ] story [ 91.2 ms ] threadThe trend of what people like to blog or comment is a different thing!
If you’re going to war and recruiting infantry. Some people can lift 200 pounds easy but can’t run half a marathon. You likely want both types on your team.
Not sure how that relates back to software.
A better analogy: the guy who wins the Nobel prize is not necessarily one who churns out the most papers. You could consider each type a speciality and you want both.
Soldiers are largely cannon fodder. The system is designed so that they can be easily replaced if they die, which they inevitably do in war. I don't want to die at the keyboard, that's not the kind of workplace I want to join.
Nine times out of ten that stuff is absent and the post is just a bunch of opinion and conjecture.
By the way, when you're doing something nebulous in an interview like seeing "how the candidate thinks" what you're often doing (all too frequently without realizing) is looking for justification for a decision you've already made based on whether or not you like the candidate. The fact that you have them writing code on a whiteboard doesn't instantly make the whole thing an objective process.
EDIT: You can test the above by making a "prediction" about the candidate's performance after the intro and comparing your prediction to your final decision after the interview.
It seems like you might accidentally be testing your ability to predict their ability to solve the whiteboarding problems given their resume.
As an example, at one company we noticed that applicants with a certain level of educational achievement were dramatically less likely to be able to solve the problems we used than candidates with slightly higher or slightly lower levels of academic achievement. So if I made predictions about candidates, that's one factor that would influence my prediction, but it wouldn't necessarily mean that my subconscious bias was causing the candidates not to come up with a BFS.
> not to come up with a BFS
But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
> But it's not about whether they solve the problem, it's about observing their problem-solving process... right? ;)
I did not say that the interview process at that company was my favorite or was the same as the one in the OP.
That said, my experience as a candidate at FAANG and smaller-but-not-super-small companies has generally been that I must at a minimum solve the problem, and that sometimes I must also solve it exactly the way some rubric says it is to be solved, so that providing an unusual approach that uses half the space and just as much time as the best approach the department has heard of also causes one to fail.
Abso-fucking-lutely, pardon my French.
To be a little more precise: unless you're going into an interview totally unprepared, there is a résumé that you've read, hopefully read carefully. I make a decision, based on said résumé, whether I would like to hire that candidate. Maybe "decision" is too strong a word. Hypothesis. Yes, hypothesis is better.
That means I have some sort of mental model of what the candidate might be like, what they can do and whether and how they fit.
If the person is invited for the interview, the hypothesis is "yes, I would like to hire this person".
The purpose of the interview is to try to disprove the hypothesis. If you fail to disprove the hypothesis, hire the person.
I knew a lot of interviewers at those types of companies who wouldn't bother to read resumes, either. They'd cite "bias" or something.
In principle I like the idea but I think they should ask to also remove the company names and perhaps dates, as it could be straight forward to work out who you are based on companies and dates.
As to how effective to remove bias, it's hard to say as I've not seen any A/B testing done with this, but give the massive push to get minorities on board, I'd hazard a guess that it's not as effective as they had hoped
Not necessarily, just depends on how easy/hard you set the bar for disproving the hypothesis. It also is somewhat inherent in that you really are trying to disprove the hypothesis.
On the other hand, if, after reading the résumé, I do not want to hire this person, why on earth should I go on to interview said person?
The "default to no" part is, IMHO generally correct, because false positives are a lot more damaging/costly than false negatives. My perspective may be warped here, because I have worked for companies that get LOTS and LOTS of applicants. At some the team would screen hundreds of résumés a week, of which maybe 1-2 were somewhat interesting, and that was after the HR screen. Oh, and I also got to clean up after one of the candidates → colleagues I said no to and the rest of the team approved... ¯\_(ツ)_/¯
"A" players want to hire people better then themselves who elevate both themselves and the team.
Not getting into how most "B" players see themselves as "A" players (dunning-kruger?), unconscious biases, or people who are just bad at playing interviewer (esp. people who have done it a certain way for their entire careers and are unwilling to even think that a different process might yield betterresults).
How to you drill down & distinguish?
If I were hiring for a position that required X years of Java experience, and saw a resume that said "X years of Java experience" (or even "4X years") without any further elaboration—no section of actual work experience—I'd be, at best, deeply skeptical.
And if that leaves nobody, you keep looking. One company I was at that was pretty good at hiring would much rather leave positions open than hire "the best of the current lot". Other companies were the other way around, and ended up with much lower quality.
And certainly if "N years of X experience" is all there is it won't be particularly interesting. Pass.
If you have improved faster, there should be work that you've done that you can reference, know-how you've amassed that you can assert you have (and I can somehow check). And if you've done the work of someone with 10 years experience, but you've only been at it for 2, yes, that will be noticeable. Very much so.
So make your resume interesting. Without going beyond what is there. One candidate had as his headline that he was a "Software Architect". Cool! First, very obvious question: "So what's Software Architecture". Stammer...stammer...and then after a while some random buzzwords about "best practices".
Now obviously there can be various different answers, and while I have my preferred and that one is obviously correct (Hah!), you should at least have something reasonable to say there if you make that the headline of your resume.
Like, the "it will be obvious" thing... I'm just not convinced. Sure, if you speak to someone you can tell pretty quickly, but on a resume? What concrete evidence would you expect to see from someone who's only been in work for 2 years? I can think of a lot, but not much that you could convey in that format.
Don't really think so. Don't confuse "plain" with "uninteresting".
I remember coming across my dad's resume at some point. It was plain as heck, but included such choice sentences as "Experience leading a national car manufacturer" (paraphrased). Ahh. Tell. Me. More.
> Do you not worry about identifying that?
Not particularly, no. First, I don't really believe that this is true, second, I worry a lot more about false negatives than I do about false positives. Third, it's really not that hard.
> Sure, if you speak to someone you can tell pretty quickly, but on a resume?
That's why you have the combination: the resume tells me if the person is interesting, the interview tells me if that was actually true.
> I can think of a lot, but not much that you could convey in that format.
Why not? Unless you're mixing up the two (again). I also see that I couldn't convince someone that I am interesting on the resume (in a "beyond doubt" fashion). But that's not the resume. That's the interview. The interview is about triggering interest.
I think you're making this harder than it is.
Heck, just write: "After only two years on the job I was doing the work of people with 10 years seniority". There, done. Interesting? Definitely. True? Well, it better be, and I am going to see if that is true to my satisfaction.
After all, it could be that the people there just sucked.
A truly challenging real-life scenario can fit just fine after some alterations.
I'm intensely suspicious of people who believe that this isn't possible.
One company asked me to find a bug in a library in a language of my choice out of a small list of languages in a bit under an hour. So I pick a language from a list of languages none of which I use regularly, and until the interview I was not sure which of dozens of combinations of tooling will be used by the project. It seemed like a reasonably sized bug that someone who was not worried about time pressure and had worked on a project tthar used the same tooling could reasonably do in the time given. So I failed, and I passed comparably difficult sections at other companies that I did not want to work at as much.
Seems like this is where they went wrong...
I had this happen to me in one interview https://news.ycombinator.com/item?id=13295212 using Python which I didn't know very well. Despite it not working out I thought it was one of the better interviews I've had.
If you give it to somebody you know you'd want to hire and they take 4+ hours to do a 1 hour task that's kind of a red flag. I'll bet your company didn't test their test.
"Chemistry" is just an excuse to allow unconcious bias to run rampant IMHO. New hires shouldn't need to enforce the existing culture of the team you have by matching it.
They should be adding to it, not neccessarily emulating it.
Which is a good filter, for better or worse.
Think sororities and fraternities recruiting pledges. For better or worse.
I've long accepted that I simply don't fit into most orgs.
"Oh yea, JIRA Agile SOA dynamic typing FTW, woohoo!"
I can say the words. But most people sense on some level that I'm lying.
However, they don't often move efficiently, or even in the right direction.
I swear, I was just dealing with this a week ago. “Excuse me, Mr. Interviewer. I can either answer your questions about what’s going on here or attempt to fix the last let of this code. Which is more valuable to you?” Proceeded to use silence to fix code. Puzzle solving uses the uninterrupted brain.
And just the other day, I had the SQL schema question to design a schema … for a calendar! Worst interview question I ever experienced, honestly. Nearly no one designs calendars and they’ve got lots of ways to trip you up because recurring events are exciting. (Also, when I did design something decent with two tables and was asked to query both with a single SQL statement my interviewer didn’t understand UNION but that’s another matter.)
I like take home projects augmented with short exercises to verify that I’m not a plagiarist who’s incompetent at code. If you want to assess my puzzle solving capabilities let me play a Zachtronics game like SpaceChem or the like.
In my most recent round of interviews, I found almost no one expecting me to recall a particular algorithm and implement it for a solution to a problem, but I did find plenty of questions that involved dealing with data structures, and writing my own code and algorithms to solve those problems.
Maybe I've been fortunate with not having been asked questions like "implement the quick sort algorithm"?
That's fine in and of itself, but when I'm having a bit of a time pruning the common-ancestor paths, I want to use all 7 brain-registers for the problem instead of devoting 2-3 for communication, or, worse, having to flush everything from cache to analyze and respond to your "hint".
I don't know about anyone else, but for me personally, it's a bit difficult to have fun when I'm unemployed and need a paycheck.
You might even say that interviews are testing for how financially secure you are. You can only truly relax during a job interview if you don't actually need the job.
Telling me "I will come in for 8 hours make things you want made, the way you want them, for money, and then go home" is fine by me.
[0] Some of these are bonuses or predictors of general suitability sometimes, but none is a deal-breaker.
This sounds a lot like system design or leetcode-esque interview questions, which is the trend among tech companies in the US.
> The problems candidates are facing at my interviews usually have NOTHING in common with the company's domain, BUT they have a super-low entry level (e.g. they are about common problems everyone encounters every day): building up the context takes seconds (literally), so the candidate can focus on tackling the problem, not understanding its basics.
Are they system-design questions? This post could use some examples of interview questions the author has asked.