Just communicate that setting a _priority_ for a bug is fine, but a timescale isn't, as you don't know what you don't know. Then let them know what resources you need to figure it out as quickly as possible (maybe it's just space and time, maybe it's people, maybe it's expertise).
Always seems to be very popular with a certain type of engineer. I personally prefer to create much better looking diagrams in about 1/10th of the time using draw.io
I think you got your fraction reversed. Writing down the specs in plantuml will be a lot faster and generate much more consistent results at the cost of memorizing the syntax upfront. It is an investment, but if you frequently have diagrams in your docs and multiple people collaborate on them, then it's really worth it.
A shocking injustice. Innocent people went to prison for years. There was clearly a cover up at Fujitsu and the Post Office, and those accountable should now be prosecuted.
This was a good read. Many tech companies (and some non-tech companies) talk the talk about hiring from a diverse crowd, then interview them as if they're all CS bros (reverse a tree, "justify the text" bullshit leetcode nonsense, 8 hours of interviews), the exact kind of stuff that people from diverse and non-traditional backgrounds don't know and don't care about.
OTOH this is standard interview-curriculum stuff that people can prepare for, which is fair in its own way. Moving away from this can also put people at a disadvantage because it makes it harder to know how to prepare for interviews.
(I say this as someone with a weird background/employment history who'd be at a fair disadvantage in many respects if they had to get a normal job - but I know I can get a bit of normie cred by brushing up my algorithms at least...)
I would argue that “preparing for interview” is exactly what’s wrong. Nobody should be “preparing for interview”, especially the really hardcore technical kind of interview, unless the job itself really is about hardcore technical stuff. Most of the time the job isn’t hardcore technical stuff, and so the performance during interview has zero correlation with performance on the job.
To me the really bizarre thing is that I so rarely talk about things I have actually done in interviews. Even for system design ones, I am often repeating information out of a book that I read as that is the correct theoretical answer.
I suspect you could teach someone to pass a lot of tech interviews without them ever building a production system.
Talking about past projects selects for people who are comfortable talking at length in florid language about relatively little substance, and who are maybe comfortable exaggerating or stretching the truth.
The most substantial and complex projects I've worked on can end up sounding simple and boring when I describe them. It's not that I can't discuss the details, it's just that I'm not good at _selling_ them. I tend to stick to facts and give a simple overview of the project, and I'm never sure how to approach the gritty details. And honestly, the right choice at the time was likely "Pair a MySQL db with a cron job" or something, and that sounds really underwhelming in an interview.
On the other hand, I've heard people describe projects they worked on, and you'd have thought they were leading the charge on the reinvention of Internet. But when you do the math on their resume, they were two months out of university at the time.
Those types of interviews basically and inevitably end up being "tell me a good story". Non-fiction is preferred, but interesting fiction will win out over boring reality.
Focusing on the business need filled and results seems to be the best tactic here; we all hype ourselves, but if we were honest most of our work is boring "plumbing" to solve a business need. I mean, that's what we're hired to do, that's why we get paid; if we're not producing value for who we're working for, that relationship has broken down.
Most day-to-day "programming" can be broken down into that "Pair a datastore with a processor" idea, or "know enough about the problem to google/SO a fix or solution," so I don't think being honest about the mundane is a bad quality. Honestly, I think it's important enough, to make it at least a few of my questions on any formal interview, something akin to "what was a project that you thought would be simple but turned into something bigger, and how did you handle communication and management of it from that point forward?"
At my last interview (which happened less than a month ago), I said I used to do "stupid stuff with Raspberry Pis" (my exact words) and I got hired.
Maybe I was just lucky, but I think you don't have to be all "florid", just show enthusiasm when talking about what you did, and it doesn't have to come from the vocabulary; people can tell whether you're enthusiastic from your tone.
It really depends on the interviewer not wasting both our times and making it worth for everybody. I had candidates that weren't good sellers of their past experience, but I made sure to engage with them and they were in fact excellent professionals.
When interviewing you can ask the candidate for details on their MySQL + cron job and investigate how do they think, architect and build a solution and how much bullshit they're talking. Were you given a very detailed task to perform and you just did it? Or did you reach the conclusion that a MySQL DB plus a cron job would achieve the results? Why? What if the cron job failed? Draw a rough flowchart of your script, etc.
On the other hand, you can smell the bullshit of interesting fictions from a long distance when you ask those probing questions.
Now, an interview on basic CS algorithms? The only thing I would know is that you have a good memory and can recall the Cracking the Code Interview book.
The same thing actually applies to DS&A interviews: a person can memorize the solution to a given problem, but the interviewer can easily throw some curveballs that require deeper knowledge to handle.
It might come down to who is doing the interview: if you're a founder, or a team leader, and have done a lot of project management, you're likely to ask better questions about constraints, considerations, teamwork, etc, and get a better read on a candidate from questions about past experience. OTOH, a programmer giving an interview may not really care that much about those aspects or have a realistic idea of what a reasonable answer sounds like, and will thus tend to just jump through the interview hoops--and be more susceptible to, well, nonsense. On the other hand, they may actually be interested and invested in low-level technical questions.
I've had really good tech interviews that were challenging and even fun, and I don't think I could've faked my way through. I've never had a good experiential interview. But then, I've only ever interviewed for front-line programming jobs at large companies.
You can teach that. You can even pass most tech interviews without having ever touched version control or knowing how to use it. Maybe that's an easy thing for candidates to pick up once hired, but then so are algos you never need in day-to-day programming (like sorting), because you can simply look them up should you ever need to implement that.
It's all a bit broken. Best method I've seen so far is to sit down with candidates and pair on some code, and it's still got issues.
I have nearly 2 decades of experience and when I was asked to write a console log hello world app by a teenager and the CEO , who stared at me silently - well - I just couldnt bring myself to do it, fear of failure at such a simple task in such an OTT scenario mean I quit the interview on the spot as I did not want to know what the judgement could be.
Im not saying its right, just that it didnt come naturally to me to be in that situation.
You should not be taking an interview so seriously that you freeze under such a situation.
If you feel it's out of your control, it could've just been a bad day, but you may be suffering from something like generalized anxiety or a similar problem, you might want to look into that with a health professional.
It wasn't anxiety as much as knowing that if I faltered even a little that this particularly interviewer would say no. I had not written fizz buzz in a few years and decided that the fact I thought about it for a few seconds meant I had already thrown the interview away.
Im just saying its thanks to my instinct that I have been so successful in my life, and I have never lost anything by refusing fizz buzz, yet have attained good things.
Maybe its survivorship bias.
It goes against my rules to proceed in interviews I think don't lend themselves to the situation.
So what's the alternative? You can talk about work history but now you're locked out of the FAANG track if you don't start with an internship there because very few jobs are going to work at the same scale. Of course you could go learn about systems design at scale but now you're back to preparing for interviews.
You can just sit and chat like you're friends but that's going to bias the interview process to "people who I like" which is just "people who are like me".
I'm sure there are LeetCode questions that are more & less predictive of success but it does have the benefit of removing much of the bias in the hiring process, at the expense of requiring candidates to do some prep work. If you don't want to do the prep work then there are plenty of other places you can work.
I think one challenge in these conversations is that people talk about what the interview process should or shouldn't look like without talking about what the interview process is trying to optimize for. And each person is going to have different ideas of what they should be optimizing for in an interview so they'll have different interview solutions. Then you argue about the solutions but the reason you disagree is because you're starting with different goals.
Exactly. And, just like unpaid internships, being able to invest a many hours every day into "preparing for an interview" is something that many people can't afford to do.
1. FizzBuzz, always, unironically; this easily weeds out 99% of the people who can’t program. I don’t even ask for an elegant solution, just a solution that works, in any language they choose.
2. Open question/toy problem that doesn’t involve hardcore technical knowledge, just common sense. The question is framed in a way that the candidate can grasp an actual use case - e.g. “How would you design a database for a public library?” I would explain concepts like PK and FK on the spot if needed. I even let them use the internet to look up whatever they need. The idea is not to see how much stuff they have memorized from leetcode, but to see their thinking process and whether they are resourceful and ask the right questions. Seriously, some people don’t even know what keywords, not even approximate ones, to use to Google stuff.
Resourcefulness and asking the right questions have much higher priorities on my list of things to look for in candidates.
How else can I know that you know how to program though?
Fizz buzz is literally a couple IF statements and a loop.
As an interviewer, I need to know that you aren't just completely making everything up.
This is an actual problem. There are actually people who, for some reason or another, made up a bunch of stuff on their resume and literally do not know how to use a loop or IF statement, and there is no way to know this, unless you ask them to do it.
It is not an insult against you. It is just that an interviewer needs some small very easy check, just to make sure that you didn't completely make everything up.
> Why dont you test how I drink from a cup of water to ascertain that I am able to function as a normal human being?
> Where is the line drawn?
The line would be drawn at the place where like 20% of people who interview at places legitimately can't solve fizz buzz.
If I lived in a bizarro universe, where 20% of people that I talk too legitimately can't drink a glass of water, then I might have to test for that as well.
Fortunately, we aren't in that kind of situation yet.
> If there is 20 years of programming experience it could be perceived as an insult in my opinion.
Ok, and what about the people who put 20 years of programming experience on their resume and are just making everything up, and legitimately don't know even the basics of coding?
Thats the problem that exists in the world. That there are people who you have no way of knowing how to actually code at all, and exaggerated to an extreme degree on their resume.
How else would you suggest figuring out if the person that I am talking to basically just completely made everything up, or is instead just such a good talker that they can bluff their way into people thinking that they know what they are doing?
Heh. I don't claim my method is perfect, but I believe it's reasonably better than hardcore leetcode stuff. FizzBuzz is the kind of problem that doesn't need any preparation to solve for any person who can program. In fact, if I sense that the candidate already knows FizzBuzz too well, I can skip right over it and head over to the open question/toy problem. The candidate could try to bluff me about FizzBuzz, but that's not going to help them at the open question/toy problem. :P
being able to reason about expense & cost, being able to appreciate the path the computer has to take, has real value, even if it's not called upon day to day. it's just more pleasant working with people who bother to develop algorithmic insight.
Yes, but you don’t need to know how to “reverse a b-tree” for that. You just need to be aware of something called algorithmic complexity and big-O notation. You don’t even need to know how to determine the big-O for all the known algorithms and data structures: they can be readily looked up in reference books.
I agree that there's a lot of advanced data structures not worth memorizing and testing for rote knowledge is lame. and yet:
while there's a lot of other things I value in coworkers, and I want a diverse mix, I really trust a coworker much more who I know can reason through, can see how the code will execute, and understand what that implies, can find & state the significance.
there's a lot of here & now tests of ability in programming, to understand syntax, language, side effects, &c. but bring able to reason about runtimes, about this then that then that... it's the bigger picture. we have some pretty basic promise questions in our interviews, & it's so remarkable how many people get cut for now being able to understand sequencing, how a little async behavior trips so many up. not quite the classic algorithm test, but to me, they seem extremely similar in that they want the dev to be able to order & comprehend how things work.
I agree that a lot of pushback against algorithms is deserved. they are misused as a hiring bar frequently. but there is also things I value a lot, & they help elaborate whether a dev grasps coding situations or no.
As an honest question, why do you want to work for places who interview and hire so pedantically?
As a person with a diverse background and even more diverse interests, who likes to use jobs to learn things I don't know rather than simply apply things I do know, I use interviews as a natural filter. It can be rather unpleasant and frustrating at times, but in the end, it's better I don't work for some place that interviews like they got their process out of some Silicon Valley playbook.
Who said I did? I don't particularly; I'm self-employed and have been for a long time.
When I see people getting all het up over technical interviews on various moral grounds, one notes that they often forgo reflecting over the possibility that any replacements could be even more bullshit/arbitrary/exclusionary.
Yeah ok, makes sense. (Apologies for making you spell out the question again; I could've probably inferred what you meant and answered that in my earlier reply).
I have a history of self-employment and little formal education in programming per se. It might put potential employers at ease to be able to exhibit some conventional chops, and that kind of interview segment would give me an opportunity to. And algorithm-questions being more or less role-agnostic might mean less preparation rather than more for interviews when one is doing a bunch. OTOH if you want a particular role you should probably better brush up on what's needed for that role and show each application you make some individual love rather than hoping that you can carpet bomb tech company interviews in your city with algorithm-knowhow-powered interviews and get a job out of it.
Given how theoretical this discussion is for me, I feel like I'm slipping into being some kind of devil's advocate role now. I would like to apologise to anyone (basically everyone else here will have more experience with tech interviews than I have) who's reading this rolling their eyes.
No worries. I was basically just using your comment as a jumping point to say what I wanted to say anyway, as one does. Haha.
My experience has been rough and painful at times, because I tend to be very pragmatically and interest driven in terms of what I learn, outside of being pragmatic about what might be asked in interviews. I also do not have a computer science degree, as I studied mathematics, but I self-study on interests of mine and take interviews as they come. This has made interviews rough at moments, but it's worked out so far, because I would likely be very unhappy at a place that quizzes me on something I could learn over a weekend or two if needed and grades me solely on that. I had one particular interview that wasted an hour and a half on tree questions, then a few more hours on random discussion topics and behavioral questions, and they never once asked me about prior work or side projects. It was a complete waste of time and energy, for both of us, and I have held that interview experience as a prime example of what I have read about Silicon Valley and FAANG-style interviews.
> Moving away from this can also put people at a disadvantage because it makes it harder to know how to prepare for interviews.
This just proves that you can memorize a cheat sheet. What good is having interviews if they are so predictable that the applicant basically just repeats himself over and over again? That isn't an interview. That is gatekeeping. "Do you know the secret handshake?"
I don't know the entire multiplication table by heart, but I know how to multiply. But that's not what interviewers are testing for. They basically want to see you rattle off a chart from memory as though that's a non-arbitrary universal indicator of capability.
A skilled interviewer can take the classic CS interview questions and combine them or take them in unexpected directions. Memorizing the solutions won't help with that, and it'll quickly become clear if your understanding is shallow.
Of course, that doesn't really change the fact that the content of the questions has little to do with the work you'll end up doing. But I've done brainstorming with coworkers, and none of us had any ideas for interview approaches that would work better--except maybe those 2-day take-home projects that everybody hates. I think I remember a paper claiming that random acceptance would work about as well as the current interview process.
I have come to totally agree with this. The leetcode interview process actually disadvantages experienced professionals and advantages inexperienced upstarts with time to study.
Yeah, it probably is a good proxy for agism, given how well it correlates with university material that will very naturally rot from disuse (in most programming jobs).
Wouldn't that just be interviewing a candidate based on their capability to prepare for interviews and not actually interviewing for candidates who would be effective at their jobs once hired? Could this be a false assumption that these are correlated, or a decent indicator of one over the other?
I honestly didn’t really think it was all that interesting a read. Author burned out developing new products after an angel round “ruined” their company. Author wouldn't work at FAANG for “idealogical” reasons. Author doesn't know basic data structures and algorithms and applied to companies that index on that type of skillset. Author’s tool belt is Windows and they’re looking to join macOS shops.
It’s a string of poor decisions/planning followed by an unproductive rant. I don’t particularly like leet code style interview questions either, Author could take a few months and brush up if they’re a proficient engineer or if they’re really opposed then pre-filter companies based on their interview style. Author could find a corporation outside of FAANG that isn't idealogically abhorrent. Author could look for windows shops. Author could consult (sounds like they’ve been successful with this approach).
I suspect the author just isn’t that great of an entrepreneur and tried to pivot into a high paying engineering role they just aren't really qualified for either.
I agree about the SF observation at the end. If SF culture isn't working for you then explore elsewhere. I wish more people realized this before assuming they need to be in the bay area to be successful. It’s a pretty limiting and potentially damaging assumption and I’ve seen people get super distraught about the idea of being anywhere else because they drank all the VC urban tech hub cool-aid and are just starting to come down.
I couldn't help being struck by "I needed to take a break and get over my burnout." Must be nice... I've been continuously employed since 1992 because I've had no choice but to be continuously employed since 1992. Burned out or not, the bills don't stop coming: if you're in a position to "take some time and focus on yourself" in between jobs, you're in a very fortunate place.
You do not need to be a CS bro to learn the basics of data structures & algorithms. If you're a self-proclaimed autodidact, couldn't you just learn it yourself?
Of course, hnewslets who get filtered by such interviews will come downvote in force.
The basics? Yes, certainly. The hyper-specific bits and pieces that show up over and over again in interviews? Not so much. Those are selected because they can fit into an interview time slot and be graded consistently despite widely varying skills among the interviewers. A lot of important and interesting algorithms are too complicated for that, but knowing them is no help in an interview. Mostly those interviews test for recent exposure (either from being a recent grad or from having the luxury of spare time) which is not strongly correlated with ability to perform the job itself and can even be considered discriminatory.
I disagree completely. As someone from a non-traditional background, I think CS interviews dramatically increases the opportunities for me. I can’t change my background, but I can prepare for coding interviews.
I can’t help but feel that people who think otherwise have never worked in literally any other field for any amount of time. Like it or not, you have to narrow down any candidate pool to like 1% of applicants before doing any sort of in person interviewing. Most places do this by only hiring people with degrees. If you’re talking about a job that’s going to pay as much as a software engineer, you can probably get away with only hiring people from elite universities, or who have connections within the company.
Frankly to me the author comes off as arrogant and entitled. He feels he shouldn’t have to prove his worth because... he ran a failed startup? Then when his friends give him a job, literally the definition of nepotism, that still isn’t good enough? What does OP want? A system where only the best jobs are gained by nepotism?
I think that puts a negative tone on people with other degrees than CS, even if they have good software experience, or are older with life commitments. Jobs and interviews in past did not ask this stuff, yet it's now implicitly considered prep. It's biased towards new CS grads and young folks.
Many/most? companies needing devs do not use/need these CS "fundamentals", which do not automatically correspond with tech skills needed to do product development, at least in SaaS world.
Not really, no. At least nowhere I’ve worked. Currently I work at a company that recently went public and operates near FAANG scale. There are some interesting technical debt issues to overcome and these are challenging. But they’re not arbitrary or capricious. Most importantly they’re not correlated at all with our interview questions, which are designed to select people with recent exposure to mid- and upper-level textbook CS problems. That is, they’re going to naturally select from privileged groups (generally white and wealthy Asians who have attended top-tier universities).
I dont agree many of the word problems on Leetcode i.e simple and medium dont even need you to read a datastructure or algorithms book, what is required is some good logic and basic knowledge of a language. Then its just the way you approach the problems so they are actually very good problems and will definitely make you think better, clever and maybe just maybe make you a better programmer. It is more like solving math puzzles in school, no one can deny the usefullness of those math puzzles in making you think hard.
That's what I wondered about too.. OP knew about HN but hadn't picked up about how interviews apparently work at a lot of companies nowadays - the whole 'leetcode' stuff. Never had to deal with that, but heard plenty about it after just couple of weeks lurking on HN.
Ah well, probably goes to show that everybody picks different threads/posts to read
It also might show some professionalism and interest if the interviewee were to ask “what kind of interview can I expect such that I can best prepare?”
Exactly. Does anyone think that even "non-self-taught" programmers may remember off-hand "how to reverse a binary tree" ? Interviews require preparation. They may be terrible selecting interview questions, but neither that nor being "self-taught" are valid reasons to claim "you can avoid preparing this interview".
> not even preparing for them as they’re the predominant format, is just showing a lack of preparation.
Why would you spend six months preparing for them when you could build and launch an entirely new product in the same amount of time, which has a much higher expected value?
If you land the job, you have a guaranteed, pre-specified income. Probably a high one, depending on the company.
The massive risk of failure with launching a product should dramatically lower the expected value. Especially since most products, even if successful, won't pay as well as the corporate job.
You must be some incredible entrepreneur for that EV to be much higher. Strong leetcode skills print money with far less uncertainty than starting a company.
Are they? I often read this on HN, but I'm starting to wonder if there's not a selection bias that's even bigger than I expected. Beyond the usual suspects, I've had more coding assignments for instance.
Social signaling is too important not to engage in "nonsense" on occasion. Geeks resist this, thinking that their special flavor of technical knowledge, which they alone possess, should transcend a million years of evolution that produced monkeysphere dynamics. The situation is laden with all manner of irony.
Agreed. I am quite ok with being a "fool", if it means working for a FAANG tier company and collecting FAANG tier compensation.
I am not going to disadvantage myself by refusing to participate in this on some questionable principle. While I agree that Leetcode-style interviews are not the overall best, I am yet to come up with an alternative that addresses all those issues without introducing massive new ones. So it is a compromise. And as long as this compromise stands, I am fully intending on getting the most out of it.
I agree, but I don't think this is a place where it is fair to expect developers to "vote with their feet" and not participate in these interviews. The companies who do data structures and algorithms interviews seem to pay the highest in the industry
You have to pay a lot (+ a lot of perks) to get folks to tolerate the amount of bullshit you put up with at a FAANG.
There is a world of other more enjoyable and educational opportunities out there they must compete with. And so the cash shovel must be pulled out.
People vote with their feet, and then a new generation of fresh grads are lured by the pay to fill their role. They’ll grow sick of it in a few years, rinse and repeat.
Sure maybe at banks or companies where IT isn't a core focus but most tech startups and medium sized companies have taken the Leetcode cargo culting to heart
Leetcode interviews are exactly how I, as someone from a non-traditional background, got a job at a tech company.
I didn’t need to know 4+ years of CS curriculum, which I never would have learned on my own. I just needed to spend some time learning algorithms and data structures, and practice using free resources on the Internet.
A pretty good deal for non-people who didn’t study CS in college.
In fact, someone who studied CS in college might be slightly miffed that they offered a job to an outsider like me just because I practiced data structures problems in my free time.
I learned CS fundamentals after graduating with a non-CS degree. It was hard, but I enrolled in a few classes through Harvard Extension School which provides access to Harvard classes to anyone and self-study.
CS fundamentals have a big impact on the kinds of programs that individuals can write. Asking questions to show that a candidate can write a DFS, leverage multiple data-structures, or do X helps ensure that the individual is capable in this regard. Even for experienced candidates with lengthy portfolios you may find that someone drifted into an operational, management, or product role and has forgotten how to effectively program.
However, the format of the whiteboard interview is awful and if one doesn't practice for it it won't turn out well. I'd love for there to be an alternative, but the other options all have their own cons.
1. Take home tests/projects
- Requires the candidate to invest time which they may not have.
- At scale this process is easily gamed.
2. Github projects/portfolio review
- Many candidates don't have time to work on open source
- The median github project has a low code standard, and is usually made for the purpose of learning something new.
3. Pair coding
- Many candidates hate pair coding, personally if a company mentions that they do this in day to day work I will not work for them.
- Difficult to calibrate.
The only alternative I've seen is a "functional interview". Where the candidate is given sample code reviews for standard applications or a broken program to debug.
> CS fundamentals have a big impact on the kinds of programs that individuals can write
Sadly, there seems to be very little correlation though. I've known programmers who graduated from a top CS school with extremely strong CS knowledge, who still write barely comprehensible code. And vice versa, people who have never been taught big-O, but who write the most maintainable, well-reasoned code I've seen. Most programmers aren't building e.g. databases, but writing software that provides business value.
Take home tests can be ok, as long as they are limited in time (<2h). I was adverse to pair coding, but found it to be not as bad as I thought, unless it's 100% pairing all the time. Well, whatever the solution, I think anything that's closer to what day-to-day work at a company looks like is going to give richer feedback/signals than whiteboarding.
Fresh graduates from university are a poor sample of top CS skills as they often lack practical knowledge of software engineering required to be productive. However this doesn't show that an individual with a strong knowledge of software engineering but mixed CS would be highly productive.
Also for #2 currently the company I work for is 'everything you write is ours'. Now in practice they do not really care but I really do not want to go through the months of BS paperwork (and yes it is that bad) just so I can put some project I have on github. So at this moment my github is mostly just 'git' fiddling things. Where I use it to fiddle with remote git, or some weird thing I got git into and how to fix it. No real code there at all. So everything I have is private.
I'm not necessarily agreeing with FAANG hiring practices here, but your comment is a classic example of the "racism of low expectations". Arguing that candidates who are "diverse" can't pass the same tests as a "CS bro" is no different from arguing that voter registration laws are racist because black people can't afford the internet, phones or cars to get registered. You're revealing quite a lot about what you think about "diverse" people without intending to.
I don't really get why "reversing a binary tree" seem to be used as an example of what's wrong with hiring. I will say, though, that if someone said "how do you reverse a binary tree?" I would have asked the follow up question: "what do you mean by that?". If asking that would be used against me, sure, that's bad hiring.
But if the answer is: "swap all the left and right nodes in a binary tree", then... isn't that pretty basic programming?
It's funny, I've heard "reverse a binary tree" as the canonical coding interview algorithm question for over a decade and I've never stopped to think about what it actually involves. But I just Googled it and it seems like you're right...and yeah I feel like if you know how recursion works and you know what a decision tree is, it seems like a pretty trivial question.
It's a common joke interview question. I don't think anyone has acutally asked it?
I find high end jobs tend to ask some form of problem that can be tackled using dynamic programming techniques. Maybe couple of easier ones in the first interview.
I agree with most people. I never use these skills in the job. I think they're a intelligence test in disguise.
Oh, if it's just a joke that went over my head then that totally makes sense! Though in fairness there are apparently-serious interview questions that are even easier (e.g. FizzBuzz, though I don't think anyone asks that anymore either) and I've been asked interview questions that aren't much harder.
I mostly agree with your impression, though even after adjusting for intelligence I bet there's a positive correlation between knowing how B-trees work and, say, having a good intuition for how to index a database.
Maybe you’re passing it to some other function that doesn’t do that, or you don’t want to add some ordering flag to the datatype because that complicates things.
But the purpose of the question of course is to be an easy question showing basic competency in recursion and pointer usage.
> the exact kind of stuff that people from diverse and non-traditional backgrounds don't know and don't care about
This attitude is condescending towards those that come from diverse and non-traditional backgrounds, most of whom are perfectly capable of learning and developing an active interest in these subjects.
To piggyback on this solid comment, a lot of times it’s us engineers who can fix this. I sat on L5 hiring committee at Google for a while and I really believe what diverse-background candidates need is more support at HC. I could sell these candidates to the committee often, with minimal effort all they needed was a champion at committee. That can be you, dear reader, at many of the big tech companies.
Mostly HC is a ton of work (eg read 8 full interview packets a week) so if you express an interest and are a decent interviewer you’re likely to get shot at it and you can make a real difference.
I've always wondered if these companies have data to support their hiring routine or if it's just a filter to convert an overwhelming number of applicants into a pool that's manageable?
On the other hand, reversing a tree and problems like fizz buzz are pretty low bars...
Having to reverse a binary tree or some other associated nonsense for a frontend UI role meant I turned the interview process at Google down. That and about 6 prospective hours of interviews for my application to then be sent to a "hiring committee" who ultimately decided if I was worthy enough of a job at Google, it just wasn't worth the hoop-jumping.
