> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."

This is a great way to end the entire job interview process and make sure you're never called back again.

Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.

> Seriously though, I hope everyone reading this recognizes how ridiculous it is. If you go into interviews thinking you can neg your interviewer, refuse parts of the interview, and they're going to love it so much that they'll offer you a job, you're mistaken.

I once flat out refused to solve a question and still got an offer.. It really depends on a lot of variables to make a blanket statement either way. One of the variables is your level of experience. After a point, the fact that the interview goes both ways can skew heavily in favor of the candidate and if you're tactful and polite you can totally get away with driving the interview away from stupid problems. If you can't, then maybe you don't belong there and maybe that's ok. It's a win-win. A job is not a blessing, it's just a job. Unless you're starving, there's no point in pretending you're drone.

It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.

As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade, if only to see how the candidate deals w/ hiring (since for the sort of roles I evaluate for, that does come up as a job task), but I suspect that I'd see a holier-than-thou attitude that I've seen from bad interviewers and that that would be a negative flag (and, no, the "I'm not fired, I quit" thing won't work with me, because - not to brag - I'm pretty confident in my interviewee skills even without cramming leetcode)

> It goes even further than the "difficult to work with" vibes. If someone has 20+ years of experience and hundreds of interviews under their belts, they ought to know about candidate caliber variability and the meaning of standardization practices, aka why interview panels are setup the way they are.

Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.

A company shouldn't have one interview process, they should have several. Some do well with live coding, some do well with take-home assignments, others do well with pair-programming. All are valid ways to show skill. And each can also be something that makes the candidate incredibly uncertain and stressed.

> As an interviewer, I might even entertain the idea of going along w/ said "two-way interview" charade

It is always a two-way interview. It's not a charade. You sound extremely entitled and elitist just by saying that. The candidate has 5 other offers waiting for them that aren't being a pain in the rear like you.

Don't "entertain the idea", you are applying to the candidate as much as the candidate is applying to the company you work for. Get over yourself.

> Most interview panels are setup badly. Most interviewers are biased. Many technical people doing interviews just want to make themselves look smart.

I'm surprised you're saying this in such a one-sided way, since you claim to interview candidates. I interview as a candidate too just like anyone else, so itemizing interview process problems is preaching to the choir. But IMHO it's disingenuous to ignore that candidates cheat, that college kids putting 10 hours on a take home assignment are very different than mother-of-three w/ 10 years experience, that bad interviewing on the part of my peers leads to me picking up someone else's slack later, and that generally speaking interview sessions are uncomfortable scenarios for everyone, no matter the format, much like code formatting styles never fully pleases everyone.

If you've been involved in defining interviewing standards, surely you must be aware that having several interview processes is even harder than standardizing on a single process: there are issues of interviewer qualification, calibration, throughput, interest, attrition, and other fun logistics things to think about. Saying every company should bend over backwards and have master interviewers fully calibrated in six different interviewing methodologies, at scale, at all times, is really not any more reasonable than a company expecting every candidate to bang out bubble sort in 30 minutes or take 10 hour take home assignments or whatever. And letting people do whatever is how you get to the Apple horror stories you see elsewhere in this comment section.

The thing about people having other options lined up goes both ways, really. Just as candidates have other options lined up, companies also have candidates lined up. In mine, HR literally needs to be mindful to not flood people w/ too many interviews each week.

> It is always a two-way interview

Oh I fully agree with the spirit here, but there is also a thing called tact. I don't go on pissing contests w/ my candidates as an interviewer and I don't go disrespecting an interviewer's time by saying "you know what, you don't know how to interview me, let me show you how I do it to you" (and yes, I believe this is tactless behavior from the perspective of myself being a candidate). If my awareness of industry standards is me being a hard-ass in your mind, I don't know what to tell you. Industry standards are what they are, ad-hoc and imperfect as they may be, and at least I try to understand the problem space and make the process better rather than just being passive aggressive about it like so many interviewing-related threads are.

When I say "I might entertain the idea", unlike sibling comments here I do actually mean exactly that: if you think you can show your skills better that way than my planned interview structure, by all means, go ahead and show me, but when I say "charade", I also mean that: I'm still evaluating you just as you are evaluating me, and if you think I'm evaluating whether "you're as smart as me(tm)", you've got the wrong impression. If your strategy as a candidate is to talk my ears off, I'm certainly open to it as an interviewer. I have had sessions like this from both sides. I'm familiar enough with this interviewing trick and how "talkers-who-dont-walk" abuse it. To be clear, I'm not saying you're one of those, but that as an interviewer, one needs to be aware of bad faith actors, and it's one of the reasons many interviewers cringe at the thought of "curveballs" like the one you suggested.

Exactly. I can answer every question on my list, and you'd think any interviewer could because we've all used our interview sheets again and again and seen every caliber of answer. If you waste my time by telling me up front you're going to ask your own questions back at me, I will end the interview and thank you for your time. Not because I can't answer your questions, but because that's not what I set aside this 90 minute block of time for and you know that.

I'm cringing just thinking what it would be like working with someone who had the gall to pull that kind of nonsense.

I don’t think the GP would want to work with you. That was the point of their comment.

Right, it's not the cringe question, it's that you don't respect mah authority in asking me back a cringe question! I think the insane people are running the asylum now.

>If you waste my time by telling me up front you're going to ask your own questions back at me

I don't see why a 20 YOE candidate with predictable capability has no right to also likewise determine how experienced, qualified or intelligent team members on the interviewing side are...

OMG the red tape at Apple is unbelievable, but this is the first time I've seen anyone mention it. On my first day at Microsoft, I checked in code. At Apple it took nearly two weeks to get granted separate access to the apps's sourcecode, secret OS version, secret Xcode version, secret new OS headers (for some reason this was a separate line item), upcoming hardware versions (which I never saw anyway).

Once up and running as a senior engineer with tons of experience, I had no autonomy and wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.

> wasn't allowed to do something as trivial as add a comment without a bug database number and two code reviews.

I mean... how else? If this is iOS for example, this potentially goes out to in the order of hundreds of millions, or even a billion or so, user devices. If you want the due diligence process not to apply for a comment, where do you draw the line? (Not withstanding that the comment may be wrong, or have an effect anyway. Yes, weird things happen at scale.)

Even if there were a class of code changes that were deemed not to need review and a "bug database number", with every build on every lever of the multi level builds, changes often need to be removed, quickly. Because they cause bad bugs, or because they collided with other changes, or for any other reason.

You want to be able to remove that change, however innocuous it may have seemed, in the quickest and most efficient way possible. Sometimes across multiple builds. Without upsetting hundreds of other engineers that have made changes as well. For that, "random commit without metadata" does not cut it.

But nobody is going to be upset if you simply add your comment change or whatever reasonable cleanup change to another change in the same project, in order to not have to open a new bug just for cleanup for example. It will then be reviewed, and have its fate tied in case of problems, with the other code. When I worked at another FAANG, it was exactly like that as well.

That actually sounds pretty par for the course in many big tech companies.

Nah. I've worked at other FAANG companies and I'm afraid that none had anything close to the Apple level of red tape. I have barely scratched the surface of describing it.

At the end of the day, you applied for the job at a company whose success is at-least partially based on the structure and rules that were instituted by those who came before you. It could be that they were put in for a very good reason. I'm all for re-evaluating rules and making modifications, but erring on the side of caution is probably a good idea as well. Just my 2c, not necessarily disagreeing with your opinion.

No one knows the degree of red tape or dysfunctions at Apple until they're actually in the company. The aura of secrecy masks what's going on.

Woah, we got a badass over here. Seriously they have 1,000 other qualified candidates lined up right behind you. I'm sure they appreciate your time and then end the interview.

I also think this comes across as someone being pretentious and arrogant, and could be a no-hire, but there’s a nugget of truth in this: interviews are two-way streets, and getting a feel for your coworkers and your environment can be as important as landing the job.

Also

> Seriously they have 1,000 other qualified candidates lined up right behind you.

I’d kill to have ten qualified candidates to interview. It’s a seller’s market.

As an interviewer I've given you a heads up before the meeting what is being tested for. Some time to practice, do pre-work, research the company, etc.

Dumping at the start of that meeting out of the blue this criteria, is not a two-way street equal reciprocation of that respect. If you'd kill for ten candidates, you can have him. I've had ~230 for 2 position this week and I'm testing for EQ also. Maybe changing requirements on people at the last minute fits in your work culture.

~250 Candidates? Sure mate, I'd be surprised if at the end of your application process 5 of them remain and are still available.

Companies are having a very hard time finding software engineers. For the first time in the history of the market, employee retention budgets are skyrocketing because recruiting is so expensive and hard. It's not rare to hear software engineers getting a sudden 30% raise out of the blue.

Because they know we're in high demand, and they know that if we switch jobs we'll get a 30% raise, at a minimum.

If you truly have a position that is averaging 100 applicants, you are hiring on the margins.

You either have a position that is so elite and aspirational that it is paid accordingly and people are flocking to it - and good luck filtering out the majority of resumes that Dunning-Krugered their way into your inbox before the elite candidate moves on. Or, you have a position with requirements so low that you can easily get candidates by the bucketful and take your time to sift through to find a diamond.

Most of us aren’t hiring on the margins.

> Seriously they have 1,000 other qualified candidates lined up right behind you.

That is really not the case right now. It's REALLY hard to even find candidates in the first place. Especially people with OPs years of experience...

Sounds like you should open a recruiting and placement agency if you have 1,000 of what everyone else is searching for high and low with limited success.

I'm not a badass, I am just laying out a baseline: I know what I'm talking about. That's all. And no, many companies don't have 1k applicants that are qualified. They have 5000 applicants in the SF area, 4900 of them are unqualified, 80 who are qualified can't write English, of the remaining 20 candidates only 8 are still on the market once you reach them, 4 pass your filters, 2 accept a job offer, and only 1 of them shows up.

That's far more realistic. In today's world, we're not looking for jobs, jobs are looking for us. Desperately so.

They don't anymore! Candidates are scarce these days.

> Seriously they have 1,000 other qualified candidates lined up right behind you

I really doubt it.

It's interesting how many people replied to this rushing to defend algorithmic hazing. Sure this is sort of a "then the whole class started clapping" type post, but there is some merit buried in here.

Somebody with 20 years experience I would like to explore that they are not a bullshit artist and not subject them to worthless leetcode questions that some desperate 24 year old will cram, pretend they never saw the question before and spam out on a whiteboard.

So you mentioned you worked at Apple... twice, plus a bunch of other high profile companies & with 20 years of experience your interviewee techniques aren't really that applicable to almost everyone here. If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole". You state a lot of desires for your employer and coworkers; I want to work with developers who are skilled, humble, joyful and nice.

And Booking, now also twice. What can I say, Apple was fun. Stayed for 12 months and then I left.

> If someone ever responded like you say you do at the start of an interview my notes would read something like "lots of great experience, seems incredibly intelligent and skilled, total pretentious a-hole".

Well, I wouldn't act like I write on an anonymous online forum like this, obviously.

So far I would say that most of my ex-colleagues would describe me as someone who is quiet, listens well, makes lots of notes on a paper, has a fancy pen with ink, and is surprisingly non-hipster despite all that.

I'm very involved with helping other developers in my social network getting the most out of job interviews and salary negotiations. I know the right ways of getting the most out of performance reviews and how to nail an interview that would otherwise make one uncomfortable.

But, point taken.

>You state a lot of desires for your employer and coworkers

They also mention bubble sort a lot. Bubble sort.

Why bubble sort? Why?!?!?

These people are offended that you would question the competency of the employer and the interviewers. They say that you need to adopt a more servile attitude.

Yeah, it's a filter we actually got from management at one company. They were looking for specifically agreeable type of developers. It was a consultancy and they needed to put 5 more developers on one of their big clients, and the client was getting sick of the previous people we had there; they were constantly fighting back against their idiots of managers.

Boss wants employees to write many hours, not have a weekly phone call from the client asking to replace another team member...

Agreeable people also stick around longer, because they think loyalty pays, and agreeable people rarely negotiate a good salary.

Spot on. And these are companies to avoid.

There are lots of un-googleable problems out there. These questions are meant to identify the people that will probably fail to solve any non-trivial programming challenge (and maybe even some of the trivial ones).

I'm not really opinionated about whether or not you should do algorithmic stuff in the interview, but I don't agree with your reasoning here.

I see chatter about how most problems can be solved with google and your CS teacher lied to you (usually on reddit, less so on HN). My experiences have not matched this. I'd estimate that a good 40-80% of my problems don't have a solution on google. It's pretty rarely an algorithmic problem though.

If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.

My experience with problems that can't be solved with a Google search is limited. I tend to use existing technologies and I stick with an architecture that has been around for long enough to have proper support online.

Still, sometimes I run into limitations with regard to TypeScript, for example. If that happens I'll go over the problem with more experienced developers. It'll be a pair-programming thing for several reasons: two pairs of eyes and two brains see and think more than 1, and you both learn something new, and you both have a little more brainpower available because you want to look good. At least I do my best a little more ;)

> If you're playing that game, are there reasons that you'd ever be copy pasting sorting algorithms from the internet? Why bubble? Don't most programming languages have libraries available to help (especially python)? I work in an area with very little sorting, but I can't imagine myself doing that in a higher level language, or even in C.

It's a silly example, I don't care what algorithm we're talking about. And no, many languages lack any sort of built-in sorting solutions. JavaScript (front-end and Node.js), for example, requires external libraries for performant solutions.

one of the things interviewers look for is great questions from the candidate. servile drones make fine code-monkeys. but if you want to put it all together, you'll need to show some attitude. pretentious? maybe, but efficiency is key. have you ever seen the old Letterman gag "don't call me Chief"? Letterman interviews people on the street calling them Chief, and the person to win the game must day "stop calling me chief".

> servile drones make fine code-monkeys.

and quite often the desire is to have servile drones.

That's a great way to turn the process into a zero sum game. I don't understand why people do it.

I once had a phone interview at a startup. The interviewer showed up 20 minutes late. And the first thing he said was, "I was in a meeting and before you ask, I can't tell you anything about it because then I have to kill you".

??? I just hung up.

It was a joke. The joke being that they received top secret confidential information, like in a spy movie.

> Before I am presented with a dumbass interviewer who throws a ridiculous question my way about algorithmic stuff, I prepare them: "Since we are both seeing if the other party is competent, I want you to know that I want you to also solve my questions. They will be slightly more difficult than the questions you pose to me."

And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.

You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.

He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.

Be kind to people. Show your maturity by understanding what is the other person's role in the process.

If you have so much knowledge and experience as you claim, you should have no problem going through the process -- your willingness to go out of your way to do this kind of shit does not show you are going to be nice person to work with.

> I would never ask a question I can't also answer from the top of my head

That is prerequisite, but not yet full solution.

You are asking candidates for things you know which means you are comparing their experience to yours. What if they have different experience and met different problems?

Ideally, you want to answer a question "Can they be productive at their new position?" which is a different question from "Do they know everything I do?"

I always remind myself that it is likely every single candidate I interviewed knows something I do not.

> Having worked at Apple, it doesn't surprise me one bit how slow they are developing simple features and fixing simple bugs. It's a red-tape hell full of not-very pragmatic engineers that are way too smart for the good of the company.

Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?

> And that is extremely arrogant. I would end interview right now. I don't care who you are and how much experience you have, I believe in "no asshole" rule.

I'm not being an asshole, the interview goes both ways. I want to know who I'm working with and whether they practice what they test for.

> You are interviewing to work at the company. The relationship is between you and the company and not between you and the interviewer. He has particular job to do which does not include responding to your out there whims.

Oh come on, stop being so subservient. It's just a company.

The company is trying to convince me to work for them. If they want to know about what I can do for them, I have a lengthy resume and 5+ references they can call.

> He is in a tough position, most likely with much less experience than you and still asked to do a difficult job of judging your experience.

It's not a difficult job, though. Their recruiter can call my references, she can check if I worked at the companies I listed, their technical people can absolutely ask me relevant questions. But if they go into the realm of leetcode nonsense, then I am absolutely going to play that game with them.

And I don't really care if I get the job or not, I can afford to not work for about 20 months if I need to, and if I reach out to any of my on-call recruiters they'll have 5 job OFFERS for me in the next 14 days.

> Be kind to people. Show your maturity by understanding what is the other person's role in the process.

Well, I'm tactful in real life, trust me. My anonymous discourse on a forum like this isn't my conduct in real life, obviously.

> I always remind myself that it is likely every single candidate I interviewed knows something I do not.

That's a real good mindset, and I think it's guaranteed. Many junior developers still teach me a lot every day in my work.

---

> Have you ever tried actually figuring out how make it more efficient rather than just complain at the engineers you are working with? Have you always been super pragmatic, fast engineer that can accomplish things at startup speeds? Or have you been just as everybody else, constantly complaining how productive you could be if only everybody around you were not dragging you?

I did.

When I got into Apple I was one of the first to introduce them to React Native for one of their in-store specialist apps that were also customer facing. High requirements for quality. I setup a small team (1 back-end dev, 1 front-end, 1 full-stack, 1 designer, 1 product manager) and we finished the software to the requirements in ~4 months where we were given 12 months.

And I think I'm extremely pragmatic, and that it's in my nature, historically speaking. I'm detail-oriented, fast, creative, and while I have my preferences, I easily change my mind when faced with new or better information.

And if I can't change or improve what I do a company (it didn't work at First American, for example), I'll just leave. I'll definitely try, but it's easy to see unbreakable walls of politics and invested third-parties who just want to write and invoice hours, not results.

A local bank I worked for, too. They promised me the world and gave me "unlimited power" to improve everything I wanted. Turns out, the unlimited power only went up to my own level, and I was still 5 levels below the hyper-social CTO who didn't know anything about the technology we were working with.

I don't like complaining, I like solutions. I bring solutions to the table. And it takes more than just me to get them implemented, especially in larger companies...

Funny thing about apple last time I interviewed there, everyone is an independent interview team. If you want to work at apple, you can, you just have to keep on interviewing and interviewing and interviewing and eventually you'll get a bite.

Did not get rejected, and I loved working at Apple despite the red tape. The only reason I no longer work there is because I moved to a different continent :)

IMO there is a difference between production code and whiteboard code. Nobody expects candidates to come up with ready-to-ship production code in 10 minutes. I don't care much for arguments about which interviewing style is better. If you find success using your method, I'm happy for you, and I only care about results. Asking someone to write code has never let me down. It has exposed a lot of charlatans who puff up their resume taking credit for their teams work, but when you ask them detailed questions they can't back-up their claimed technical prowess.

> I mean, I'd rather have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution.

I think it's pretty well known that the question, or the actual question for which this bubble sort question is just an example, is usually more about how good you are at solving a particular problem.

For example, I'd rather not have developers on my team who Google "bubble sort python" and go for a tried and tested open-source solution, because I want my developers to know that bubble sort is an O(n^2) toy algorithm mostly used as an example for an intentionally bad sorting algorithm.