8 ms·

I'm not going to dive into the specifics of my thoughts on this question. I think a lot of comments here address this. But does anyone else get embarrassed of

I'm not going to dive into the specifics of my thoughts on this question. I think a lot of comments here address this. But does anyone else get embarrassed of their career choice when you read things like this? I've loved software since I was a kid, but as I get older, and my friends' careers develop in private equity, medicine, law, {basically anything else}, I can tell a distinct difference between their field and mine. Like, there's no way a grown adult in another field evaluates another grown adult in the equivalent mechanism of what we see here. I know this as a fact. I just saw a comment last week of a guy who proudly serves millions of webpages off a CSV-powered database, citing only reasons that were also covered by literally any other database. It just doesn't feel like this is right.

brunooliv 1y ago
Agreed, this is just terrible for the field as a whole it’s like we’re regressing or something
- joquarky 1y ago
  When I started writing code for a living 30 years ago, we were mostly left alone to solve problems. Now it feels like I'm back in high school, including strict irrelevant rules to be followed, people constantly checking in on you, and especially all of the petty drama and popularity contests.
esafak 1y ago
Which part, the fact that you have to answer such questions to get a job? Those other fields are more established and have formal barriers to entry.
ThrowawayR2 1y ago
Lawyers have law school after a degree, a bar exam, legal liability for malpractice, and ongoing licensing requirements. Medicine has medical school after a degree, a 5+ year residency under close supervision with significant failure rates, legal liability for malpractice, and ongoing licensing requirements. So explain to us what it is that you "know this for a fact" regarding how they have it easier. Most of the people reading this, myself included, would never have been allowed into this industry, let alone been allowed to stay in it, if the bar were as high as law or medicine.
- tkiolp4 1y ago
  The difference is that if you fail medicine, it’s ok (it’s hard). But if you fail to get a job because of the stupid “async queue” author’s problem, well, that’s depressing.
  - Manuel_D 1y ago
    I'm not so sure. Failing your residency means your medical career is basically done, and you have to basically start a new career from scratch in your late 20s. Chances are you'll have debt from not just undergrad but also med school. By comparison, failing a leetcode interview means you've got to find a new company to interview with.
  - thedevilslawyer 1y ago
    How's failing medicine not depressing!
    - bryanrasmussen 1y ago
      failing medicine is depressing in the original sense of giving personal depression, failing stupid leetcode and not getting job is depressing in the more modern sense of the world is stupid and not well-organized.
      - thedevilslawyer 1y ago
        That's like, your opinion. Any argument you can make for leetcode, one can make on the medical certification exam as well.
- glitchc 1y ago
  Perhaps the bar should be as high as law and medicine if we want people to take our industry just as seriously.
  - FpUser 1y ago
    Nope. In my opinion Wild West in software is much preferred model. If one wants to create software and sell it there should be no barriers. It is one of the the very few fields that give chance to simple people with no money to break out and live decent life.
chis 1y ago
I think a lot of fields of engineering have analogous questions actually. EEs ask to explain a circuit or draw a new one. Mech Es ask to design some piece of simple hardware with a clever catch. Interviewing is just hard, it’s impossible to cover breadth of knowledge in 45 mins so we end up with little brain teasers. This particular question is a bit ill formed and confusing I will say. But that might serve as a nice signal to the candidate that they should work elsewhere, so not all is lost.
trhway 1y ago
The higher layer of people in our industry aren’t subjected to those questions. They are evaluated and get jobs more like in law and medicine, ie based on connections and track of record. Me and you are just not of that high layer. We’re kind of laborers given those simple aptitude tests. When I was on track to get into the higher layer 15 years ago I got that my last job just by invitation and half an hour talk with VP. Next offer and other invitations came soon the same way, yet I got lazy and stuck at the current job simplemindedly digging the trench deeper and deeper like a laborer.
lmm 1y ago
> does anyone else get embarrassed of their career choice when you read things like this? On the contrary, it makes me proud. In private equity, medicine, or law, if you have the right accent and went to a good school and have some good names on your resume, you can get a job even if you're thoroughly incompetent - and if you're a genius but don't have the right credentials you'll probably be overlooked. In programming it still mostly comes down to whether you can actually program. Long may it continue.
- anon_e-moose 1y ago
  Leetcode has nothing to do with actually programming a project that lives long enough to deliver value.
coherentpony 1y ago
> It just doesn't feel like this is right. I know the feeling. The author says this is one of their favourite interview questions. I stop to wonder what the others are. When I'm interviewing a candidate, I'm trying to assess really a few things: 1) the capability of the person I'm interviewing to have a technical conversation with another human being; 2) how this person thinks when they are presented with a problem they have to solve; and 3) can this person be trusted with important work? For 1) and 2), coding interviews and the types of artificially constructed and unrealistic scenarios really aren't helpful, in my experience. I care a lot less about the person being able to solve one specific problem I hand them and I care a lot more about the person being able to handle a much more realistic scenario of being hand handed an ill-defined thing and picking it apart. Those conversations are typically much more open-ended; the goal is to hear how the person approaches the problem, what assumptions they make about the problem, and what follow-ups are needed once they realise at least one of their assumptions is wrong. This is a really hard thing to do. For example, I imagine (but do not know) that when a medical practice hires a doctor for a certain role, there is an expectation that they already know how the human body works. For an ER doctor, you might care more about how well that person can prioritise and triage patients based on their initial symptoms. And you might also care about how that person handles an escalation when a patient presents not too awfully but is in fact seriously ill. For a GP, it's probably more important for a practice to care more about healthcare philosophy and patient care approaches rather than the prioritisation thing I mentioned above. I'm spit-balling here, but the point is these two situations are both hiring doctors. You care less about what the person knows because there is a tacit assumption that they know what they need to know; you're not giving the candidate a trial surgery or differential diagnosis (maybe... again I'm not a doctor so I don't actually know what I'm talking about here). If I'm hiring a software engineer or performance engineer, I am trying to figure out how you approach a software design problem or a performance problem. I am not trying to figure out if you can design an async queue in a single-threaded client. This problem doesn't even generalise well to a real situation. It would be like asking a doctor to assume that a patient has no allergies. Item number 3) is "Can this person be trusted with important work?" and this is basically impossible to determine from an interview. It's also impossible to determine from a CV. The only way to find out is to hire them and give them important work. CVs will say that a candidate was responsible for X, Y and Z. They never say what their contribution was, or whether or not that contribution was a group effort or solo. The only way to find out, is to hire. And I've hired candidates that I thought could be trusted and I was wrong. It sucks. You course-correct them and figure out how to get them to a place where they can be trusted. Hiring is hard. It's a massive risk. Interviews only give you a partial picture. When you get a good hire it's such a blessing and reduces my anxiety. When you hire a candidate you thought would be good and turns out to be an absolute pain to manage it causes me many sleepless nights.
000ooo000 1y ago
It's because our profession seems to attract a number of intellectually insecure people who thrive on these little puzzles and the associated minutiae as a means of feeling a sense of superiority. They all think they've figured it out: the best way to tell if someone is a Good Dev or a Shit Dev. Of course, administering the test, there's no way they could possibly be anything but the Good Dev. It is embarrassing. Don't believe me? Why can't they help but blog about it?
- throwaway2037 1y ago
  The real problem: How you accurately evaluate a candidate without these questions? I dislike them as much as the next person, but I don't know a better way. Literally, all the best tech firms and ibanks do it. They pay the most and are most profitable. They must be doing something right. The real trick is finding a "fractically complex" question with many levels. The one in this blog is pretty good! No candidate can solve it perfectly in the allotted time, but you can have a good discussion about the "edges" of the problem -- where good candidates shine.
  - rjst01 1y ago
    If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.
    - akoboldfrying 1y ago
      In my experience the signal is pretty strong.
      - rjst01 1y ago
        Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?
        1y ago
throwaway2037 1y ago
I heard that private equity does the equivalent. They show you balance sheet of a potential takeover candidate then ask for feedback. I assume that good candidates will need to do some Excel to answer their questions. Also, interviewing for trader roles at ibanks is similar. Show a trading scenario, ask what they would do and why. I guess law must be similar as well.
- no_wizard 1y ago
  The difference to me is this: they're real analyst questions that you will have likely dealt with before in some detail, and not an obscure algorithm I maybe haven't seen since college or a leetcode not particularly real world presented or relevant brain teaser. They're things you actually do, and I imagine most people applying to these roles have done, either in exercise (say in college) or in previous jobs. Its still a practical assessment. Where software interviewing is different is the assessments aren't grounded in being all that practical
anon12512 1y ago
Don't know how many experience you get but other fields have a lot of these. Accountance have certificates, finance / quant have to solve headmaths type of problems.
saagarjha 1y ago
I had lunch with a friend who was trying to get a job at a law firm and they told me that their interview was just vibes and if they asked him actual law questions it would be refreshing. So maybe things aren't necessarily greener on the other side?
weego 1y ago
They build teams in their own broken image of what a good programmer should be, and then get to manager and director and mould entire companies the same way. They become hotbeds of intellectually rich but functionally and productively inept individuals who value spending resources indulging in esoteric side quests instead of driving businesses forwards in ways that are 'just sustainable enough'. I've always been on the periphery of FAANG 'level' situations trying to focus on the surface where tech and humans meet and as the 3 decades of my career have gone on, software engineering has become more and more ludicrous and bubble like to the point where it, and the developers working on it, are now just the annoyance between me and my goals.
higeorge13 1y ago
Of course it's not right. Let's be honest, our profession is in the era where software engineer = factory worker, and the worst part is that we have been playing music chairs right for the last couple years. So yeah all these professions have some steady status/wealth/qol progression and upgrade while people gain years of experience, while in software development it doesn't matter how many years of experience we have, which companies we worked on, their sector, whether your company is using the saas we were working on, etc.; we are going to get judged by trivia questions and leetcode.
rockostrich 1y ago
Other fields definitely involve similar lines of questioning in interviews. Medicine and law are special cases because they have their own set of standards that must be passed before you can even get an interview, but private equity interviews definitely include case studies/technical questions in a similar vein to the one shared in this post.
Twirrim 1y ago
I used to give a code review task, of some particularly egregious python code. I'd provide all help with the syntax, and emphasise strongly upfront I don't expect them to know python or its syntax. It has proven to be a low stress task for candidates. They're not trying to solve a brain teaser, they're just doing something that's going to be part of the job. Reading code, understanding what it is doing, and providing feedback to make it more maintainable. When all around me in this FAANG type role are engineers giving leet code esque questions, I was trying to be a breath of fresh air for them. Sadly, I need to rethink this now, because you can throw it in an LLM and it'll give you a nearly complete answer. I've already had one candidate clearly do that.
- actinium226 1y ago
  The most "refreshing" interview I had was one where the guy had a list of like 100 questions about C++, and he would just go through and ask "do you know what SIMD is?" or "are you familiar with smart pointers?" or "tell me about templates" (most were less open ended than the template one). If I responded yes, he'd follow up, and it was more of a discussion. If I said no he'd just move on to the next one (sometimes I'd ask what it was and he'd explain). At one company I lobbied hard against standardizing our interview on a question designed to test the candidate's multi-threaded knowledge. I insisted that if we needed multithreading, we could just ask the candidate, and ask them to elaborate. Fortunately I won that little battle. Sometimes in interviews you get tunnel vision and you can't see the forest through the trees, and you don't realize that the interviewer is asking you about multithreading because they're being coy. That's the kind of shitty interview we need to avoid, because it leads to the false conclusion that the candidate doesn't know about multithreading when actually you just don't know how to ask.
quietbritishjim 1y ago
> But does anyone else get embarrassed of their career choice when you read things like this? What specifically is embarrassing about it? None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work. They're also fairly discussion based rather than having one silly trick answer (like the XOR trick that came up recently here). The whole point of an interview is to check that the candidate can do their job. What would you propose instead? We don't bother to interview and just cross our fingers and blindly hope they'll know what they're doing? I can only assume that the real reason for your objection is that your job actually doesn't involve solving problems like these ones. Well, that's fair enough, and then I'd expect the interview for your position to look different. But why would you assume that there are no jobs that really need these skills? Your comment about using a CSV file for a database seems unrelated. Maybe I missed the real point of your comment?
- anon_e-moose 1y ago
  > None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work. Really? Do you invert linked lists all day? When the last time you had to traverse a binary tree? Genuine questions. I'm sure there has to be a mismatch between what we define as "those questions". > They're also fairly discussion based They're also performed wildly differently with no standards at all. I've had good coding interviews with the coding as a starting point for a conversation. But I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. The latter is particularly great at hiring professional interviewers rather than actual professionals at the job.
  - quietbritishjim 1y ago
    > I'm sure there has to be a mismatch between what we define as "those questions". When I said "these questions" in my comment, I meant the questions in the article. That's what this discussion is about! Those are not inverting linked lists or traversing binary trees. They're about networking, asynchronous actions and time outs. And yes, I do deal with those things all them. Maybe not every day, but certainly multiple times in each project. Ever had to deal with a timer where it might still be triggered even after you've cancelled it [1] (because its underlying implementation has already fired but the callback is still waiting in the completion queue)? Or even trigger twice because you then re-set it while the first callback was still in the queue? That's just an example, but that's exactly the sort of fiddly condition that permeates every corner of a heavily async or multithreaded / distributed system. If your work involves that then it's totally fair to ask about them in interviews. [1] https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/basic_deadline_timer/cancel/overload1.html https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/... > ... I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. ... Well, I agree, that's bad. But, as you say, the same questions can go either way depending on the interviewer. The very reason that I mentioned these being "discussion based" in my comment was because I took it as read that silly tricky questions are bad and to make the point that these questions don't seem to be designed for that. Are we not allowed to ask technical questions in an interview just because some interviewers are bad? Should we be "embarrassed" about the questions in the article, as was said in the comment that I was replying to? That was what I was objecting to.
morsecodist 1y ago
Not really. These other industries are evaluating people somehow. Whether it's vibes, connections, resume, or some sort of technical evaluation you'll have a grown adult evaluating you. Hiring will always feel a bit lame and arbitrary, you have limited time and information to pick someone. You're not going to be able to understand candidates fully and you'll probably pick wrong a fair bit. So we come up with criteria that's a bit arbitrary but you need at least some effort and smarts to meet them so it's at least a bit correlated with a good hire. I don't think the non technical methods are any more or less dignified.
mdavid626 1y ago
SW engineering is rather young, compared to others, like construction, medicine, law, etc. It doesn’t have good established patterns, which is followed by everyone.
deleted 1y ago
[deleted]
DavidWoof 1y ago
I think the "sendOnce" question is fine. Software development is just different than other professions, and you get a lot of candidates who talk a good show but can't actually program at all. For a decent dev, this isn't programming, it's typing. But all the "ok, now add this feature..." stuff is just a sign that the interviewer is an insecure asshole. And you get insecure asshole interviewers in other professions as well, asking about obscure laws or diagnoses. Software is still a bit of a craft, and it's perfectly reasonable to ask a job seeker on a construction site to go hammer a nail. But nobody is going to follow that up with a bunch of "OK, now do an L-joint" just to show off their own knowledge.
catlover76 1y ago
[dead]
prats226 1y ago
Isn't it because there is a difference in your field and other fields? 1) Scope - Other fields like law, medicine atleast are impacting one unit at a time, vs software which is impacting large number of users through your work. I am sure research interviews will go through similar process? 2) Feedback - Just basis past work, you would get a good sense of their aptitude. Very hard to do it in programming without you spending a lot of time going through their work? 3) Subjectivity - Wrt coding, very good way to get objective output in interview by getting other person to write code, can't do that in medicine for example?
bravesoul2 1y ago
I had a favourite interview question when I was 3 years in. My boss tempered my enthusiasm by letting me ask it but made it not a requirement to be hired so more of a bonus "extension question". Glad they did that. I was being rediculous. I assumed "anyone who used this framework must have come across this problem" but was just an assumption.
MichaelRo 1y ago
Well, that's because in law, you can't attend a 4 week bootcamp, call yourself a lawyer and inflate the ranks of desperate looking for a job. Now, also remote. And as a doctor, you can't attend a 4 week bootcamp, call yourself a doctor and inflate the ranks of desperate looking for a job. And at least you gotta be in person, no remote. Much of the problems of software engineering stem from the highly inflationary nature of it's people. There's a trillion of us already and more keep coming. That's what you get when there's a dozen for everything: a dime's worth.
cdaringe 1y ago
> But does anyone else get embarrassed No. > there's no way a grown adult in another field evaluates another grown adult … There is. Demonstrating competency over a common and interesting problem is the baseline. Are queues commonly needed? Yes. Is task processing commonly async? Yes. Fantastic, then what precisely is the problem? What is most puzzling to me is that people are confounded when even low standards are set for each other. This isn’t a high bar.
red-iron-pine 1y ago
there are formal regulatory boards for most of this. Lawyers gotta pass the bar, medical folks have their own board exams, finance has things like CPA or CFP certifications, etc. Most Mechanical / Electrical / Civil Engineers have formal accreditation processes, too. IT is something of a clusterfuck but even there we have things like CCIE or RHEL or Windows Certs that can prove a minimum level of competency. The lack of regulation makes it easy for anyone to be a dev but also means there is no formal minimum standard.

brunooliv 1y ago

Agreed, this is just terrible for the field as a whole it’s like we’re regressing or something

joquarky 1y ago
When I started writing code for a living 30 years ago, we were mostly left alone to solve problems. Now it feels like I'm back in high school, including strict irrelevant rules to be followed, people constantly checking in on you, and especially all of the petty drama and popularity contests.

esafak 1y ago

Which part, the fact that you have to answer such questions to get a job? Those other fields are more established and have formal barriers to entry.

ThrowawayR2 1y ago

Lawyers have law school after a degree, a bar exam, legal liability for malpractice, and ongoing licensing requirements. Medicine has medical school after a degree, a 5+ year residency under close supervision with significant failure rates, legal liability for malpractice, and ongoing licensing requirements. So explain to us what it is that you "know this for a fact" regarding how they have it easier. Most of the people reading this, myself included, would never have been allowed into this industry, let alone been allowed to stay in it, if the bar were as high as law or medicine.

tkiolp4 1y ago
The difference is that if you fail medicine, it’s ok (it’s hard). But if you fail to get a job because of the stupid “async queue” author’s problem, well, that’s depressing.
- Manuel_D 1y ago
  I'm not so sure. Failing your residency means your medical career is basically done, and you have to basically start a new career from scratch in your late 20s. Chances are you'll have debt from not just undergrad but also med school. By comparison, failing a leetcode interview means you've got to find a new company to interview with.
- thedevilslawyer 1y ago
  How's failing medicine not depressing!
  - bryanrasmussen 1y ago
    failing medicine is depressing in the original sense of giving personal depression, failing stupid leetcode and not getting job is depressing in the more modern sense of the world is stupid and not well-organized.
    - thedevilslawyer 1y ago
      That's like, your opinion. Any argument you can make for leetcode, one can make on the medical certification exam as well.
glitchc 1y ago
Perhaps the bar should be as high as law and medicine if we want people to take our industry just as seriously.
- FpUser 1y ago
  Nope. In my opinion Wild West in software is much preferred model. If one wants to create software and sell it there should be no barriers. It is one of the the very few fields that give chance to simple people with no money to break out and live decent life.

chis 1y ago

I think a lot of fields of engineering have analogous questions actually. EEs ask to explain a circuit or draw a new one. Mech Es ask to design some piece of simple hardware with a clever catch. Interviewing is just hard, it’s impossible to cover breadth of knowledge in 45 mins so we end up with little brain teasers. This particular question is a bit ill formed and confusing I will say. But that might serve as a nice signal to the candidate that they should work elsewhere, so not all is lost.

trhway 1y ago

The higher layer of people in our industry aren’t subjected to those questions. They are evaluated and get jobs more like in law and medicine, ie based on connections and track of record. Me and you are just not of that high layer. We’re kind of laborers given those simple aptitude tests. When I was on track to get into the higher layer 15 years ago I got that my last job just by invitation and half an hour talk with VP. Next offer and other invitations came soon the same way, yet I got lazy and stuck at the current job simplemindedly digging the trench deeper and deeper like a laborer.

lmm 1y ago

> does anyone else get embarrassed of their career choice when you read things like this? On the contrary, it makes me proud. In private equity, medicine, or law, if you have the right accent and went to a good school and have some good names on your resume, you can get a job even if you're thoroughly incompetent - and if you're a genius but don't have the right credentials you'll probably be overlooked. In programming it still mostly comes down to whether you can actually program. Long may it continue.

anon_e-moose 1y ago
Leetcode has nothing to do with actually programming a project that lives long enough to deliver value.

coherentpony 1y ago

> It just doesn't feel like this is right. I know the feeling. The author says this is one of their favourite interview questions. I stop to wonder what the others are. When I'm interviewing a candidate, I'm trying to assess really a few things: 1) the capability of the person I'm interviewing to have a technical conversation with another human being; 2) how this person thinks when they are presented with a problem they have to solve; and 3) can this person be trusted with important work? For 1) and 2), coding interviews and the types of artificially constructed and unrealistic scenarios really aren't helpful, in my experience. I care a lot less about the person being able to solve one specific problem I hand them and I care a lot more about the person being able to handle a much more realistic scenario of being hand handed an ill-defined thing and picking it apart. Those conversations are typically much more open-ended; the goal is to hear how the person approaches the problem, what assumptions they make about the problem, and what follow-ups are needed once they realise at least one of their assumptions is wrong. This is a really hard thing to do. For example, I imagine (but do not know) that when a medical practice hires a doctor for a certain role, there is an expectation that they already know how the human body works. For an ER doctor, you might care more about how well that person can prioritise and triage patients based on their initial symptoms. And you might also care about how that person handles an escalation when a patient presents not too awfully but is in fact seriously ill. For a GP, it's probably more important for a practice to care more about healthcare philosophy and patient care approaches rather than the prioritisation thing I mentioned above. I'm spit-balling here, but the point is these two situations are both hiring doctors. You care less about what the person knows because there is a tacit assumption that they know what they need to know; you're not giving the candidate a trial surgery or differential diagnosis (maybe... again I'm not a doctor so I don't actually know what I'm talking about here). If I'm hiring a software engineer or performance engineer, I am trying to figure out how you approach a software design problem or a performance problem. I am not trying to figure out if you can design an async queue in a single-threaded client. This problem doesn't even generalise well to a real situation. It would be like asking a doctor to assume that a patient has no allergies. Item number 3) is "Can this person be trusted with important work?" and this is basically impossible to determine from an interview. It's also impossible to determine from a CV. The only way to find out is to hire them and give them important work. CVs will say that a candidate was responsible for X, Y and Z. They never say what their contribution was, or whether or not that contribution was a group effort or solo. The only way to find out, is to hire. And I've hired candidates that I thought could be trusted and I was wrong. It sucks. You course-correct them and figure out how to get them to a place where they can be trusted. Hiring is hard. It's a massive risk. Interviews only give you a partial picture. When you get a good hire it's such a blessing and reduces my anxiety. When you hire a candidate you thought would be good and turns out to be an absolute pain to manage it causes me many sleepless nights.

000ooo000 1y ago

It's because our profession seems to attract a number of intellectually insecure people who thrive on these little puzzles and the associated minutiae as a means of feeling a sense of superiority. They all think they've figured it out: the best way to tell if someone is a Good Dev or a Shit Dev. Of course, administering the test, there's no way they could possibly be anything but the Good Dev. It is embarrassing. Don't believe me? Why can't they help but blog about it?

throwaway2037 1y ago
The real problem: How you accurately evaluate a candidate without these questions? I dislike them as much as the next person, but I don't know a better way. Literally, all the best tech firms and ibanks do it. They pay the most and are most profitable. They must be doing something right. The real trick is finding a "fractically complex" question with many levels. The one in this blog is pretty good! No candidate can solve it perfectly in the allotted time, but you can have a good discussion about the "edges" of the problem -- where good candidates shine.
- rjst01 1y ago
  If you're involved in the hiring process at your org at all, and they ask these type of questions, I'd encourage you to try to as-objectively-as-possible evaluate how much of a signal they actually provide.
  - akoboldfrying 1y ago
    In my experience the signal is pretty strong.
    - rjst01 1y ago
      Are you able to share how you evaluated this? Is this based on gut-feeling or is it data-driven?
      - 1y ago

throwaway2037 1y ago

I heard that private equity does the equivalent. They show you balance sheet of a potential takeover candidate then ask for feedback. I assume that good candidates will need to do some Excel to answer their questions. Also, interviewing for trader roles at ibanks is similar. Show a trading scenario, ask what they would do and why. I guess law must be similar as well.

no_wizard 1y ago
The difference to me is this: they're real analyst questions that you will have likely dealt with before in some detail, and not an obscure algorithm I maybe haven't seen since college or a leetcode not particularly real world presented or relevant brain teaser. They're things you actually do, and I imagine most people applying to these roles have done, either in exercise (say in college) or in previous jobs. Its still a practical assessment. Where software interviewing is different is the assessments aren't grounded in being all that practical

anon12512 1y ago

Don't know how many experience you get but other fields have a lot of these. Accountance have certificates, finance / quant have to solve headmaths type of problems.

saagarjha 1y ago

I had lunch with a friend who was trying to get a job at a law firm and they told me that their interview was just vibes and if they asked him actual law questions it would be refreshing. So maybe things aren't necessarily greener on the other side?

weego 1y ago

They build teams in their own broken image of what a good programmer should be, and then get to manager and director and mould entire companies the same way. They become hotbeds of intellectually rich but functionally and productively inept individuals who value spending resources indulging in esoteric side quests instead of driving businesses forwards in ways that are 'just sustainable enough'. I've always been on the periphery of FAANG 'level' situations trying to focus on the surface where tech and humans meet and as the 3 decades of my career have gone on, software engineering has become more and more ludicrous and bubble like to the point where it, and the developers working on it, are now just the annoyance between me and my goals.

higeorge13 1y ago

Of course it's not right. Let's be honest, our profession is in the era where software engineer = factory worker, and the worst part is that we have been playing music chairs right for the last couple years. So yeah all these professions have some steady status/wealth/qol progression and upgrade while people gain years of experience, while in software development it doesn't matter how many years of experience we have, which companies we worked on, their sector, whether your company is using the saas we were working on, etc.; we are going to get judged by trivia questions and leetcode.

rockostrich 1y ago

Other fields definitely involve similar lines of questioning in interviews. Medicine and law are special cases because they have their own set of standards that must be passed before you can even get an interview, but private equity interviews definitely include case studies/technical questions in a similar vein to the one shared in this post.

Twirrim 1y ago

I used to give a code review task, of some particularly egregious python code. I'd provide all help with the syntax, and emphasise strongly upfront I don't expect them to know python or its syntax. It has proven to be a low stress task for candidates. They're not trying to solve a brain teaser, they're just doing something that's going to be part of the job. Reading code, understanding what it is doing, and providing feedback to make it more maintainable. When all around me in this FAANG type role are engineers giving leet code esque questions, I was trying to be a breath of fresh air for them. Sadly, I need to rethink this now, because you can throw it in an LLM and it'll give you a nearly complete answer. I've already had one candidate clearly do that.

actinium226 1y ago
The most "refreshing" interview I had was one where the guy had a list of like 100 questions about C++, and he would just go through and ask "do you know what SIMD is?" or "are you familiar with smart pointers?" or "tell me about templates" (most were less open ended than the template one). If I responded yes, he'd follow up, and it was more of a discussion. If I said no he'd just move on to the next one (sometimes I'd ask what it was and he'd explain). At one company I lobbied hard against standardizing our interview on a question designed to test the candidate's multi-threaded knowledge. I insisted that if we needed multithreading, we could just ask the candidate, and ask them to elaborate. Fortunately I won that little battle. Sometimes in interviews you get tunnel vision and you can't see the forest through the trees, and you don't realize that the interviewer is asking you about multithreading because they're being coy. That's the kind of shitty interview we need to avoid, because it leads to the false conclusion that the candidate doesn't know about multithreading when actually you just don't know how to ask.

quietbritishjim 1y ago

> But does anyone else get embarrassed of their career choice when you read things like this? What specifically is embarrassing about it? None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work. They're also fairly discussion based rather than having one silly trick answer (like the XOR trick that came up recently here). The whole point of an interview is to check that the candidate can do their job. What would you propose instead? We don't bother to interview and just cross our fingers and blindly hope they'll know what they're doing? I can only assume that the real reason for your objection is that your job actually doesn't involve solving problems like these ones. Well, that's fair enough, and then I'd expect the interview for your position to look different. But why would you assume that there are no jobs that really need these skills? Your comment about using a CSV file for a database seems unrelated. Maybe I missed the real point of your comment?

anon_e-moose 1y ago
> None of these questions seem especially hard, and they're exactly the sort of problem that I face on a daily basis in my work. Really? Do you invert linked lists all day? When the last time you had to traverse a binary tree? Genuine questions. I'm sure there has to be a mismatch between what we define as "those questions". > They're also fairly discussion based They're also performed wildly differently with no standards at all. I've had good coding interviews with the coding as a starting point for a conversation. But I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. The latter is particularly great at hiring professional interviewers rather than actual professionals at the job.
- quietbritishjim 1y ago
  > I'm sure there has to be a mismatch between what we define as "those questions". When I said "these questions" in my comment, I meant the questions in the article. That's what this discussion is about! Those are not inverting linked lists or traversing binary trees. They're about networking, asynchronous actions and time outs. And yes, I do deal with those things all them. Maybe not every day, but certainly multiple times in each project. Ever had to deal with a timer where it might still be triggered even after you've cancelled it [1] (because its underlying implementation has already fired but the callback is still waiting in the completion queue)? Or even trigger twice because you then re-set it while the first callback was still in the queue? That's just an example, but that's exactly the sort of fiddly condition that permeates every corner of a heavily async or multithreaded / distributed system. If your work involves that then it's totally fair to ask about them in interviews. [1] https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/basic_deadline_timer/cancel/overload1.html https://think-async.com/Asio/asio-1.10.6/doc/asio/reference/... > ... I've also had it super strict on rails, interviewer silent and just expecting you to one-shot the optimal path. ... Well, I agree, that's bad. But, as you say, the same questions can go either way depending on the interviewer. The very reason that I mentioned these being "discussion based" in my comment was because I took it as read that silly tricky questions are bad and to make the point that these questions don't seem to be designed for that. Are we not allowed to ask technical questions in an interview just because some interviewers are bad? Should we be "embarrassed" about the questions in the article, as was said in the comment that I was replying to? That was what I was objecting to.

morsecodist 1y ago

Not really. These other industries are evaluating people somehow. Whether it's vibes, connections, resume, or some sort of technical evaluation you'll have a grown adult evaluating you. Hiring will always feel a bit lame and arbitrary, you have limited time and information to pick someone. You're not going to be able to understand candidates fully and you'll probably pick wrong a fair bit. So we come up with criteria that's a bit arbitrary but you need at least some effort and smarts to meet them so it's at least a bit correlated with a good hire. I don't think the non technical methods are any more or less dignified.

mdavid626 1y ago

SW engineering is rather young, compared to others, like construction, medicine, law, etc. It doesn’t have good established patterns, which is followed by everyone.

deleted 1y ago

[deleted]

DavidWoof 1y ago

I think the "sendOnce" question is fine. Software development is just different than other professions, and you get a lot of candidates who talk a good show but can't actually program at all. For a decent dev, this isn't programming, it's typing. But all the "ok, now add this feature..." stuff is just a sign that the interviewer is an insecure asshole. And you get insecure asshole interviewers in other professions as well, asking about obscure laws or diagnoses. Software is still a bit of a craft, and it's perfectly reasonable to ask a job seeker on a construction site to go hammer a nail. But nobody is going to follow that up with a bunch of "OK, now do an L-joint" just to show off their own knowledge.

catlover76 1y ago

[dead]

prats226 1y ago

Isn't it because there is a difference in your field and other fields? 1) Scope - Other fields like law, medicine atleast are impacting one unit at a time, vs software which is impacting large number of users through your work. I am sure research interviews will go through similar process? 2) Feedback - Just basis past work, you would get a good sense of their aptitude. Very hard to do it in programming without you spending a lot of time going through their work? 3) Subjectivity - Wrt coding, very good way to get objective output in interview by getting other person to write code, can't do that in medicine for example?

bravesoul2 1y ago

I had a favourite interview question when I was 3 years in. My boss tempered my enthusiasm by letting me ask it but made it not a requirement to be hired so more of a bonus "extension question". Glad they did that. I was being rediculous. I assumed "anyone who used this framework must have come across this problem" but was just an assumption.

MichaelRo 1y ago

Well, that's because in law, you can't attend a 4 week bootcamp, call yourself a lawyer and inflate the ranks of desperate looking for a job. Now, also remote. And as a doctor, you can't attend a 4 week bootcamp, call yourself a doctor and inflate the ranks of desperate looking for a job. And at least you gotta be in person, no remote. Much of the problems of software engineering stem from the highly inflationary nature of it's people. There's a trillion of us already and more keep coming. That's what you get when there's a dozen for everything: a dime's worth.

cdaringe 1y ago

> But does anyone else get embarrassed No. > there's no way a grown adult in another field evaluates another grown adult … There is. Demonstrating competency over a common and interesting problem is the baseline. Are queues commonly needed? Yes. Is task processing commonly async? Yes. Fantastic, then what precisely is the problem? What is most puzzling to me is that people are confounded when even low standards are set for each other. This isn’t a high bar.

red-iron-pine 1y ago

there are formal regulatory boards for most of this. Lawyers gotta pass the bar, medical folks have their own board exams, finance has things like CPA or CFP certifications, etc. Most Mechanical / Electrical / Civil Engineers have formal accreditation processes, too. IT is something of a clusterfuck but even there we have things like CCIE or RHEL or Windows Certs that can prove a minimum level of competency. The lack of regulation makes it easy for anyone to be a dev but also means there is no formal minimum standard.