I'm just tired of the whole tech interview process. I've prepped for days for interviews only to have them fall apart because they asked something I hadn't prepped for or some kind of gotchya riddle was asked. What I've found works best is to just convince myself I really don't care either way if I get the job or not - that's when I do my best. When I really want the job, that's when I do my worst.
While I'm currently not working (for money, anyway) I'm fortunate to be in a position to not have to look for work. That could change, of course (for example, if the SCOTUS strikes down the ACA I'll need to find a job with insurance). Just thinking about interviewing in this current environment makes my stomach tie up in knots. But for now, I'll be over here working on my own interesting problems.
Especially when many people will never use them in prod. My organization asks questions about DS and algos in the interviews now.
Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. But we judge candidates on it.
> Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly.
Not only that - I often see atrocious code. Stuff like comparing boolean expressions against true/false. Stuff that makes me question basic competence of the person writing it.
Eh IDK. Leetcode type questions are starting to slip into many industries and types of companies. I recently interviewed at large finance (not trading firms, retail banking/investment) and insurance companies. They both asked LC medium/hard.
I was honestly taken a back. These companies aren’t known for “high” standards and make up for the lack of interesting work with WLB (or at least it comes across like that.
Just like how everyone copied google Qs a decade ago (how many toothpicks can a tree yield...). I’m fully expecting everyone to copy FAANG like interviews because someone in HR thinks it might signal better hires, and why wouldn’t you want better hires right?
Not at a FAANG company but I will ask stuff that might show up as “easy” on leet code.
Examples: run length encoding problem or a bit extracting/setting question. I want to see if the candidate can formulate a simple state machine and they understand bit manipulation. I target the bit manipulation questions for firmware/embedded software roles, which very much involves reading and setting bits from hardware registers all day long.
So if they ask the same questions at Google and same at BigInsuranceCo, why work for a lower salary at BigInsuranceCo.
If the interview is the same, you are better off working at some one who pays better. As a side effect eventually there could across the board better pay.
This post reeks of elitist/holier-than-thou attitude that the whole industry has unfortunately been feeding into. I also suspect that it is why there's so little diversity in tech and why there's this absurd notion that there's not enough "qualified" candidates to fill positions.
1) is something that I abhor because it allows the interviewer to assume very little of the responsibility for communication, which is an exercise for both people to come to a consensus of what the task is at hand. Instead of saying "did I communicate this effectively", it's saying "it's the listener's fault for not understanding me."
2) is very similar to 1) in that it also absolves the interviewer of any responsibility for communicate. It's also an absurd proposition because it's saying it is the interviewee's job to keep me, the interviewer, entertained. This is absurd because the purpose of interviews is to vet a candidate, if that's not the purpose, then the interviewer should make it more clear that an hour's worth of a jester's time is being requested.
3) is specifying a criteria that might make sense for recent college graduates or if the candidate knows what to prepare for. In my experience, no such guidance is typically given, the most I've seen is "prepare for questions that might be relevant to the role/job posting." The interviewer fails to consider does he/she have a full time job? Did the interviewer actually provide materials for he/she to study? If the questions the OP cited were not actually provided, how do they know to prepare for those types of questions.
> Instead of saying "did I communicate this effectively", it's saying "it's the listener's fault for not understanding me."
The problem is that customers, PMs, and managers often don't communicate clearly either. Being able to ask the right clarifying questions is part of being a software professional. It's completely fair for new grads to lack that skill but experienced people should have developed it.
I completely agree on 2 and 3 though. Guess some people have become so used to the status quo that leetcode no longer seems like an aberration.
> The problem is that customers, PMs, and managers often don't communicate clearly either.
Exactly. One of my favorite interview challenges is to write an input validation that checks for a valid SSN. The actual code should be pretty trivial for a competent programmer; but the real test is if they ask for what "valid SSN" means (123-45-6789, 123456789, 123 45 6789, all of the above?) If they jump right to the code based on an assumption, without even thinking or asking about it, that signals that they're likely to make such assumptions in the field.
1) is a measure of a candidate's ability to handle incomplete or unclear requirements, which are a fact of life for the vast majority of working developers.
2) you're conflating "engaged" and "entertained". If you're engaging the interviewer then they can help guide you when you're going astray. If you're not the chances of them realizing you're headed down the wrong path decreases.
3) how is the candidate's current employment status relevant to their preparedness? The things listed in the article are the kinds of things you can expect to encounter at most technical interviews. You can expect to be asked about a project you've worked on, you can expect to be asked about data structures and algorithms, you can expect to be asked about software development best practices. If you were interviewing to be a barista would you need to be told to expect to answer questions about coffee?
I disagree, the OP reads as genuinely trying to help people pass interviews by giving them some insights. Even if the information may seem obvious to you, or annoying or elitist, or whatever, as long as it's valuable to some readers, then his effort is worth it.
At the end of the day, all tech companies compete with each other to hire people who exhibit a growth mindset and show strong signs of perseverance. That's why they give you challenges to overcome on the spot. Past experience will help you start higher-up on the ladder, if you get an offer, but it won't mean crap if you can't demonstrate your willingness to push through the challenges.
You're only holding yourself back if you dismiss advice instead of welcoming any and all tips and tricks to improving your chances.
Well, yes. The interviewee is supposed to impress the interviewer, not the other way around. The onus is on him to get hired. They're flooded with applicants. A smart applicant can thrive in any system, no matter how bad - otherwise, they're not very smart.
If you'd hire people based of how much they could lift, you'd see how the smart, driven, competent people coming in suddenly have much bigger muscles.
The system is never broken. You are broken for failing to adapt to it. If you fail to adapt to it, there are hundreds willing to take your place.
> The interviewee is supposed to impress the interviewer, not the other way around.
Interviews are two-sided auditions.
If there was a genuine talent shortage as we keep hearing about, the asymmetry would be the other direction; while it would still be two-sided, the bigger burden would be on the interviewer as the representative of the prospective employer to impress the prospective employee.
The system is functioning as designed. But if you're implying that it can't be improved then I don't know if I agree with that. For instance, it might be possible that savvy candidates use interviews to vet whether they want to work there, because for every offer they get, there are hundreds more they could get (and often up to a dozen that they do get).
If that is the case, then it's possible that a broken system could end up coming into existence in a company that:
- has a revolving door of expensive attrition
- loses all the good talent so that ones that remain aren't good at their jobs
- slowly ossifies into place
- can't seem to get things done
- eventually loses its customers
- loses market position, growth and relevance
- becomes a bankrupted carcass eventually stripped for parts by a distressed asset firm
Sounds familiar? I agree that if you fail to adapt to the system, there are hundreds willing to take your place. But where we may disagree is whether I'd envy any of them. I'll tell you one thing, though -- I've never had to sacrifice my career trajectory to just put up with this kind of nonsense. In fact, the places I've had to put up with it the most are the places where I've grown the least and leaving opened up a much better opportunity afterwards.
How useful are interviews in general? I've been led to believe that an interview is a very poor indicator of future performance[0], and that an interview biases the hiring decision in typically negative ways.
My thought is the purpose of a job interview is to weed out people who are an obvious poor fit for the job temperamentally, and to verify that the interviewee has a working understanding of the relevant skills that they listed in their resume. Beyond that, actual job performance depends on a lot of factors that are very difficult to assess in an interview.
I think a lot of companies have deluded themselves into thinking they've designed some sort of unique interviewing system that can guarantee good job performance (instead of reducing the incidence of catastrophically bad performance), but honestly, job performance itself is very hard to measure in any objective way once you disregard the extremes.
Just because a misused tool is bad at doing the thing you're misusing it for doesn't mean that it doesn't have utility when used for its actual purpose.
You can just get on the phone with them. Talk shop for an hour. Tell them about problems your company is having. Ask them how they would solve them. An experienced engineer can determine a person's relative skill level this way.
Algorithm quizzes aren't the only way to reduce false positives. Can we say definitively that they are the best?
This is true. This is the advice I've been following: do your best, but never forget that it's basically random chance. Also consider a career change to a field without hilariously ridiculous interview practices.
I've recently started doing interviews for my company, and while there are definitely candidates that we have been on the fence about accepting that would probably have been a great fit, in the end, the false positive rate is more important to us than the false negative rate. Maybe we missed out on some great candidates but the criteria we used to evaluate them also allowed us to avoid a lot of very bad candidates. The perfect interview process doesn't exist, we have to make do with the fact that whatever the interview process is, we will miss out on great candidates and end up making an offer to candidates that will not work out. But indeed: for candidates, this means that you shouldn't take rejections to heart too much: you might have been a great fit for the role and a bad fit for the interview process. If you're consistently getting rejected for positions for which you believe you are qualified, maybe you need to get better at interviews, or maybe you're not as qualified as you may think.
> If you're consistently getting rejected for positions for which you believe you are qualified, maybe you need to get better at interviews, or maybe you're not as qualified as you may think.
This comment represents everything that is wrong with your technical interview process. Big yikes.
I think they’re great for analyzing communication skills if nothing else. Depends on the role, but for some positions that’s all or a big part of the job.
Really nothing I haven't read before. Apparently these are all mistakes a candidate can make.
I would appreciate it if companies finally acknowledged that interviewing is a two-way street.
I have cancelled way more interviews due to red flags happily waved by companies than companies have rejected me because I failed one of the 8 algorithms questions.
This adequately represents the 1:1 experience of one technical interview.
Let me cherry-pick an example: You mention that you don't read a candidate's CV before your one interaction with them (the technical interview). As you say, this is a debatable choice (I find it somewhat acceptable).
At that point, has anyone else at your company read the candidate's CV and cover letter? Sounds stupid, but you would not believe how many people ask about specific topics ("So have you worked with a relational database before?") not in order to ask deeper questions about knowledge or experience, but just in order to tick off checkboxes on their HR form. (This is not made up, this has actually happened to me.)
This bigger issue of a company never asking themselves "How do we as a company show that we actually give a shit about each candidate, and are not just looking for a butt in an office chair" is where in my experience, lots of companies are still completely failing at self-reflection.
Case in point - “given a list of numbers, return two numbers ...” is a poor question, because it does not state that the return values must come from the list given.
It is already a two-way street in that as a candidate you chose the company, and expect specific things from them. If they don’t deliver on that part you will walk away.
To me parent’s point is that any company acting as if you’d unconditionally accept their offer if they made one is a recipe for failure.
Yes I agree. A huge red flag is if the interviewer is leaning back in the video call trying to get you to see the spaceX logo embroidered on their shirt when they don’t work there anymore.
> #2 - Not keeping your interviewer engaged
> It is extremely simple, just think out loud
Yes, "think out loud" is better than being completely silent, but given that many hiring decisions are based on how the interaction feels, including the quality of the communication _in order to assess thinking skills_, candidates can see huge returns by learning specific communication techniques.
I make videos on this topic (technical and non-technical interview and negotiation skills), and happened to have just made a video on what to say while writing code:
Noting that I had a really intense negative emotional reaction to this video. It's possible that I'm just not your target audience, and certainly the depth of response felt... disproportionate, but I thought I might share my reaction in case it was useful to you.
I think there was a combination of things that straight away disposed me negatively towards it - the negative title (stop X!), the negative introduction (stop x, again) and also the camera being so close to your face. It had the effect of feeling like I was being simultaneously negged and mansplained to by some overly aggressive dude (no doubt more an artifact of my own life experiences more than the video. Stop telling me what to do, Dad.). It felt very you-tube, but like, the uglier parts. I stopped watching pretty quickly.
Glancing at your profile, it seems like you have a number of videos titled "Stop X". I'm noting here that you describe this video as "a video on what to say while writing code." There's a clear value prop there: What to say when writing code! But it doesn't exactly come through in the first exposure to the video. I'd watch a video on "what to say while writing code" because I have my own opinions on it, and am interested in comparing my mental model with someone else who's spent time thinking about good communication in a coding context. Feeling scolded by said video made it a solid pass.
I think I read something purporting to be research about how closeup pictures on faces tend to elicit stronger emotional reactions.
I did like that you were modeling perspective taking - "your interviewer is a programmer who can read your code." Building a capable theory of mind is long term work, and it's work that people who are drawn to computers often don't do.
Anyways, thanks for sharing it, and taking the time to make those videos. It seems like a worthy project.
It did leave one gap though - it assumes my handwriting is legible! Many companies (at least pre-COVID) still expect people to hand write code on a whiteboard, under immense time pressure Most people aren't used to writing on a whiteboard, and many interview rooms inexplicably have a combination of large markers and a small whiteboard, which often leads to my output being of marginal readability. Narrating what I'm writing can help move past that.
I tend to avoid it except things that are "obvious" but I tend to forget, like you know - there's SOLID and everybody understands it differently and applies it differently, I never remember the theory behind it.
I believe going without preparation means that you're "pure" - you're talking only about stuff you know or understand, not just seen 10h ago on some blog.
When it comes to questions I really love open questions like design something or try find security issue
I think the most valuable preparation you can do is asking yourself long and hard what the other side is looking for, and what you bring that they might be looking for.
This is valuable for yourself as well, because you can avoid places where the role they have in mind for you doesn't fit your expectations
When you prepare for the behavioural questions, give answers of real situations that you are very familiar with, and avoid "keyword soups". I've seen quite a few candidates failing interviews because they gave almost canned answers that seem to hit all the right points, but once you dig deeper they aren't able to elaborate more.
Most tech interviews especially for engineers are a one-sided power dynamic that does nothing except make the candidate nervous and eventually rejects them arbitrarily. The ones that do get a job seem to think that that's the only way to interview people and this cycle continues. What happens is this becomes a boys club that excludes anyone else.
This is more apparent for people with anxiety too. My mind shuts down during whiteboarding, yet people generally seem to think I'm smart outside any of those scenarios.
I've already been employed for several years at different places, doing a whole range of things, and it's weird that I have to practice some arbitrary exercises in order to demonstrate to a company that I can work. This has led to me landing at companies that don't require the bizarre jumping-through-hoops that filters for the desperate and "committed".
And so far, I've not only yet to see interview-style programming on the job, I've seen utterly atrocious practices.
Absolutely. There's no reason to do this. No one has written code on a whiteboard at work. To do this just for interviews is very silly. You've to also second guess what the interviewer expects from you. Not every interviewer is calibrated the same way.
If I could it my way, I'd start with a 30-minute briefing session on the coding test that's to follow. 1-1.5 hour coding project - implement an API or something. 45 minutes where you review some code (maybe intentional bad code). 1 hour writing a design document. 1 hour presenting the design doc to a couple of team members. Couple of behavioral sessions with team members/manager.
I work for a FAANG company. The interviews were quite stressful, and my goal for every question was to push through and at the very least make some progress instead of giving up.
I don't make use of any of the algorithmic skills I was interviewed on, but I do have to push through stressful situations regularly and make progress in a timely fashion. I do think that if I weren't able to do that during an interview situation, I wouldn't have been able to do that on the job.
Maybe I wouldn't have any stress in my current position if I were 10x smarter or 10x more experienced/knowledgable, but that would also indicate that I were underleveled.
I'm certain there are many smart and skilled individuals that wouldn't be able to consistently make it past a tech interview loop unless they put in lots of "unnecessary" extra work.
Can you expand on why you believe these sorts of interviews don't offer good signal? Having gone through a couple of these interview cycles, I felt the behavioral questions adequately demonstrated how I'd perform in similar situations.
Behavioral questions are fine. Some like top grading are not. I had someone ask me about my choices right from my senior year in high school and my choice of college, etc. Well, I was extremely depressed in high school and didn't do well in my entrance exams, got into an average college but was actively programming by myself and turned my life around in my junior year in college. I wouldn't have fit into the interviewer's expected stereotype of someone who has been excellent since high school.
Readit News
Most normal developers. Spending you time on leetcode means you want to get in a faang. Most people are going for other roles.
While I'm currently not working (for money, anyway) I'm fortunate to be in a position to not have to look for work. That could change, of course (for example, if the SCOTUS strikes down the ACA I'll need to find a job with insurance). Just thinking about interviewing in this current environment makes my stomach tie up in knots. But for now, I'll be over here working on my own interesting problems.
Has complexity or efficiency ever come up in a team discussion? Nope. Do we have use for high efficiency solutions at scale? Not particularly. But we judge candidates on it.
Not only that - I often see atrocious code. Stuff like comparing boolean expressions against true/false. Stuff that makes me question basic competence of the person writing it.
I was honestly taken a back. These companies aren’t known for “high” standards and make up for the lack of interesting work with WLB (or at least it comes across like that.
Just like how everyone copied google Qs a decade ago (how many toothpicks can a tree yield...). I’m fully expecting everyone to copy FAANG like interviews because someone in HR thinks it might signal better hires, and why wouldn’t you want better hires right?
Examples: run length encoding problem or a bit extracting/setting question. I want to see if the candidate can formulate a simple state machine and they understand bit manipulation. I target the bit manipulation questions for firmware/embedded software roles, which very much involves reading and setting bits from hardware registers all day long.
If the interview is the same, you are better off working at some one who pays better. As a side effect eventually there could across the board better pay.
Companies that wouldn't have leetcoded you 5, 10, years ago are now doing so. The difficulty of leetcode questions is going up too.
Also, takehome problems are becoming more common - not instead of leetcode interviews, but in addition to.
1) is something that I abhor because it allows the interviewer to assume very little of the responsibility for communication, which is an exercise for both people to come to a consensus of what the task is at hand. Instead of saying "did I communicate this effectively", it's saying "it's the listener's fault for not understanding me."
2) is very similar to 1) in that it also absolves the interviewer of any responsibility for communicate. It's also an absurd proposition because it's saying it is the interviewee's job to keep me, the interviewer, entertained. This is absurd because the purpose of interviews is to vet a candidate, if that's not the purpose, then the interviewer should make it more clear that an hour's worth of a jester's time is being requested.
3) is specifying a criteria that might make sense for recent college graduates or if the candidate knows what to prepare for. In my experience, no such guidance is typically given, the most I've seen is "prepare for questions that might be relevant to the role/job posting." The interviewer fails to consider does he/she have a full time job? Did the interviewer actually provide materials for he/she to study? If the questions the OP cited were not actually provided, how do they know to prepare for those types of questions.
The problem is that customers, PMs, and managers often don't communicate clearly either. Being able to ask the right clarifying questions is part of being a software professional. It's completely fair for new grads to lack that skill but experienced people should have developed it.
I completely agree on 2 and 3 though. Guess some people have become so used to the status quo that leetcode no longer seems like an aberration.
Exactly. One of my favorite interview challenges is to write an input validation that checks for a valid SSN. The actual code should be pretty trivial for a competent programmer; but the real test is if they ask for what "valid SSN" means (123-45-6789, 123456789, 123 45 6789, all of the above?) If they jump right to the code based on an assumption, without even thinking or asking about it, that signals that they're likely to make such assumptions in the field.
2) you're conflating "engaged" and "entertained". If you're engaging the interviewer then they can help guide you when you're going astray. If you're not the chances of them realizing you're headed down the wrong path decreases.
3) how is the candidate's current employment status relevant to their preparedness? The things listed in the article are the kinds of things you can expect to encounter at most technical interviews. You can expect to be asked about a project you've worked on, you can expect to be asked about data structures and algorithms, you can expect to be asked about software development best practices. If you were interviewing to be a barista would you need to be told to expect to answer questions about coffee?
I think you're taking an overly unfair view of what the author meant.
We know what's wrong with that statement in this climate.
At the end of the day, all tech companies compete with each other to hire people who exhibit a growth mindset and show strong signs of perseverance. That's why they give you challenges to overcome on the spot. Past experience will help you start higher-up on the ladder, if you get an offer, but it won't mean crap if you can't demonstrate your willingness to push through the challenges.
You're only holding yourself back if you dismiss advice instead of welcoming any and all tips and tricks to improving your chances.
If you'd hire people based of how much they could lift, you'd see how the smart, driven, competent people coming in suddenly have much bigger muscles.
The system is never broken. You are broken for failing to adapt to it. If you fail to adapt to it, there are hundreds willing to take your place.
Interviews are two-sided auditions.
If there was a genuine talent shortage as we keep hearing about, the asymmetry would be the other direction; while it would still be two-sided, the bigger burden would be on the interviewer as the representative of the prospective employer to impress the prospective employee.
If that is the case, then it's possible that a broken system could end up coming into existence in a company that:
- has a revolving door of expensive attrition
- loses all the good talent so that ones that remain aren't good at their jobs
- slowly ossifies into place
- can't seem to get things done
- eventually loses its customers
- loses market position, growth and relevance
- becomes a bankrupted carcass eventually stripped for parts by a distressed asset firm
Sounds familiar? I agree that if you fail to adapt to the system, there are hundreds willing to take your place. But where we may disagree is whether I'd envy any of them. I'll tell you one thing, though -- I've never had to sacrifice my career trajectory to just put up with this kind of nonsense. In fact, the places I've had to put up with it the most are the places where I've grown the least and leaving opened up a much better opportunity afterwards.
[0] https://80000hours.org/podcast/episodes/will-macaskill-moral...
I think a lot of companies have deluded themselves into thinking they've designed some sort of unique interviewing system that can guarantee good job performance (instead of reducing the incidence of catastrophically bad performance), but honestly, job performance itself is very hard to measure in any objective way once you disregard the extremes.
Just because a misused tool is bad at doing the thing you're misusing it for doesn't mean that it doesn't have utility when used for its actual purpose.
Algorithm quizzes aren't the only way to reduce false positives. Can we say definitively that they are the best?
This comment represents everything that is wrong with your technical interview process. Big yikes.
I have a hard time following this conclusion - how do you know this?
That's the entire point, you don't, you only think you do.
I would appreciate it if companies finally acknowledged that interviewing is a two-way street.
I have cancelled way more interviews due to red flags happily waved by companies than companies have rejected me because I failed one of the 8 algorithms questions.
https://aitorvs.github.io/post/most_common_interviewer_mista...
Let me cherry-pick an example: You mention that you don't read a candidate's CV before your one interaction with them (the technical interview). As you say, this is a debatable choice (I find it somewhat acceptable).
At that point, has anyone else at your company read the candidate's CV and cover letter? Sounds stupid, but you would not believe how many people ask about specific topics ("So have you worked with a relational database before?") not in order to ask deeper questions about knowledge or experience, but just in order to tick off checkboxes on their HR form. (This is not made up, this has actually happened to me.)
This bigger issue of a company never asking themselves "How do we as a company show that we actually give a shit about each candidate, and are not just looking for a butt in an office chair" is where in my experience, lots of companies are still completely failing at self-reflection.
you wanting the company to acknowledge that its a two-way street is evidence that it's not. It's very rare.
> I have cancelled way more interviews due to red flags happily waved by companies than companies have rejected me
You can boycott a business too if you don't like it, but that doesn't make it a two-way street. You have very little leverage over the business.
Yes I can? I can walk away from the interviewing process. They have invested in recruiting just as much if not more than I have in interview prep.
Their employees are paid just the same for technical interviews than their normal work.
To me parent’s point is that any company acting as if you’d unconditionally accept their offer if they made one is a recipe for failure.
Yes, "think out loud" is better than being completely silent, but given that many hiring decisions are based on how the interaction feels, including the quality of the communication _in order to assess thinking skills_, candidates can see huge returns by learning specific communication techniques.
I make videos on this topic (technical and non-technical interview and negotiation skills), and happened to have just made a video on what to say while writing code:
https://www.youtube.com/watch?v=sv42PpY-nK8
I think there was a combination of things that straight away disposed me negatively towards it - the negative title (stop X!), the negative introduction (stop x, again) and also the camera being so close to your face. It had the effect of feeling like I was being simultaneously negged and mansplained to by some overly aggressive dude (no doubt more an artifact of my own life experiences more than the video. Stop telling me what to do, Dad.). It felt very you-tube, but like, the uglier parts. I stopped watching pretty quickly.
Glancing at your profile, it seems like you have a number of videos titled "Stop X". I'm noting here that you describe this video as "a video on what to say while writing code." There's a clear value prop there: What to say when writing code! But it doesn't exactly come through in the first exposure to the video. I'd watch a video on "what to say while writing code" because I have my own opinions on it, and am interested in comparing my mental model with someone else who's spent time thinking about good communication in a coding context. Feeling scolded by said video made it a solid pass.
I think I read something purporting to be research about how closeup pictures on faces tend to elicit stronger emotional reactions.
I did like that you were modeling perspective taking - "your interviewer is a programmer who can read your code." Building a capable theory of mind is long term work, and it's work that people who are drawn to computers often don't do.
Anyways, thanks for sharing it, and taking the time to make those videos. It seems like a worthy project.
It did leave one gap though - it assumes my handwriting is legible! Many companies (at least pre-COVID) still expect people to hand write code on a whiteboard, under immense time pressure Most people aren't used to writing on a whiteboard, and many interview rooms inexplicably have a combination of large markers and a small whiteboard, which often leads to my output being of marginal readability. Narrating what I'm writing can help move past that.
I tend to avoid it except things that are "obvious" but I tend to forget, like you know - there's SOLID and everybody understands it differently and applies it differently, I never remember the theory behind it.
I believe going without preparation means that you're "pure" - you're talking only about stuff you know or understand, not just seen 10h ago on some blog.
When it comes to questions I really love open questions like design something or try find security issue
This is valuable for yourself as well, because you can avoid places where the role they have in mind for you doesn't fit your expectations
When you prepare for the behavioural questions, give answers of real situations that you are very familiar with, and avoid "keyword soups". I've seen quite a few candidates failing interviews because they gave almost canned answers that seem to hit all the right points, but once you dig deeper they aren't able to elaborate more.
I've already been employed for several years at different places, doing a whole range of things, and it's weird that I have to practice some arbitrary exercises in order to demonstrate to a company that I can work. This has led to me landing at companies that don't require the bizarre jumping-through-hoops that filters for the desperate and "committed".
And so far, I've not only yet to see interview-style programming on the job, I've seen utterly atrocious practices.
If I could it my way, I'd start with a 30-minute briefing session on the coding test that's to follow. 1-1.5 hour coding project - implement an API or something. 45 minutes where you review some code (maybe intentional bad code). 1 hour writing a design document. 1 hour presenting the design doc to a couple of team members. Couple of behavioral sessions with team members/manager.
I don't make use of any of the algorithmic skills I was interviewed on, but I do have to push through stressful situations regularly and make progress in a timely fashion. I do think that if I weren't able to do that during an interview situation, I wouldn't have been able to do that on the job.
Maybe I wouldn't have any stress in my current position if I were 10x smarter or 10x more experienced/knowledgable, but that would also indicate that I were underleveled.
I'm certain there are many smart and skilled individuals that wouldn't be able to consistently make it past a tech interview loop unless they put in lots of "unnecessary" extra work.