Q: Why a subscription? A: Because lifetime pricing is not sustainable. We know there are similar apps with lifetime pricing out there, but it doesn't work for long-running business. The sustainability is crucial especially for note-taking apps because you will store a lot of notes in them day by day.
Q: $5 per month is too expensive. A: It is for professional use, not targeted to the mass of people. We believe it would improve your productivity worth more than $5. This is the price we would pay as a user.
Q: If lowered the pricing, you would get more customers. A: We would like to provide good, quick and warm user support. If we got a lot of users, we won't be able to support them all.
Some people prefer to pay their services directly. I would rather pay someone to host my notes, and to build/maintain the infrastructure to host my notes, than hope Google keeps finding it profitable to give me costless storage.
I'm in the camp these days of I would much rather pay someone who does one or a few related things well and charges me for them, I'm already happy with my note taking setup, but 5$ a month doesn't seem too bad for a service I actively use and enjoy.
But it's certainly not $5/mo. Something in the ballpark of $10/yr would be better.
I can buy a private VPS for $20/yr with 30gb of storage and slap sync thing on it, and find an existing markdown editor if I wanted.
That could easily pay for itself with 4 users. And that's just scraping the bottom of the barrel of low cost servers.
Yes not everyone can set up a server, and yes this takes the burden off spending time doing that. But your average software engineer with some server knowledge could set this up in a day.
I would want to add time for a bit of stress testing, backups, etc.
If I'm building something that needs to "stand the test of time", I find a day lets me relax, meander, think it through, and not get stressed over not moving fast enough.
I've also learned from experience to always over estimate these things ;)
> Inaction is equal to support of the Russian invasion
No, no it isn't, in this or in other situations. More than two choices _usually_ exist. Statements like this present a false dichotomy in an attempt to coerce people to support a preferred position or interpretation.
No, it isn't. The comment we're replying to here is about someone adding a message to their code repo that's shown to Russian viewers. Are you saying that if people don't do this, they support the Russian invasion? It seems pretty obvious when you get specific. It's simpleminded to divide people into two groups and say that anyone who doesn't agree with a _particular action_ is the enemy.
I'm glad, and I shouldn't try to pigeonhole you here either, I just think these types of conversations lose specificity quickly.
Person A: I'm doing <this thing> to support <cause>
Person B: You shouldn't do <that thing>
Person A (or more often, C): Inaction is equal to support / silence is violence
I think there is almost always more than one possible action, even in support of <cause>. Also, some well intentioned actions can hurt a cause, so inaction is obviously preferable. Or, there may be a third outcome that I like better than <cause> or <not cause>.
Let me get specific, to avoid my own criticism.
I don't know if what the original commenter is doing is worth the effort, in terms of supporting Ukraine in this conflict. There's obviously a cost, in terms of dev time and false positives (showing the message to an unintended audience). I do think it is usually annoying, distracting, and unnecessarily polarizing to add politics to technical projects, so I would lean against doing this, even if I agree with the politics. Good technical work is hard enough on its own.
I'm not terribly offended by this action, and I wouldn't criticize it on its own; but I definitely think that "inaction supports the Russian invasion" is out of line here.
Understand things like, "what is in shampoo", to take an example from the article? I like to understand things too, but there there's plenty of things to learn, and I think one can benefit from being choosy.
I wish America had more bikeable cities and better public transport too, but I don't see what that has to do with the linked article. I would also really like a dumbcar.
It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring. If you aren't allowed to consider culture fit (because it's discriminatory) or education (because it's discriminatory) or give take home work (because it's discriminatory against people with time constraints) or trust your feelings in a qualitative interview (because they're discriminatory), what can you do? Solving real engineering problems takes too long for an interview, and full-day interviews are also discriminatory against people with time constraints. You can candidates give some automated algorithms problem solving test- that's what you can do.
If leetcode is intended to avoid discrimination, in my opinion it fails miserably. As the parent poster mentioned, it certainly rules out people that don't have the resources to study, but it also rules out another class of people prone to panic disorders. I'll share my leetcode horror story to illustrate.
At the time, I had been coding for 15 years in multiple languages. Out of the blue I got poked by a Facebook recruiter and on a lark decided to go through the process. I made it through the phone calls and screen-share coding sessions just fine. I went onsite and had a several interviews that went swimmingly.
Then near the end of the day, I ended up getting a whiteboard coding challenge that involved pretty simple array manipulation and my brain absolutely locked up. In retrospect it was comical, but at the time it was incredibly humiliating. There I was just alternately staring at the whiteboard and the interviewer with what I can only imagine to be the most hopeless expression. My brain fog absolutely impenetrable.
At this point in my life, I'm fairly familiar with the condition. Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do. Then your consciousness inevitably becomes obsessed with this thought and it's all you can think about. You start panicking and soon you have absolutely zero mental bandwidth to accomplish the task and your mind is basically singularly focused with getting out of this terrible situation. It sucks.
So, I'm always a little annoyed when I hear people say, "what's the big deal with a little leetcode?"
I mean, I get it, if I actually could not solve those problems, I would not be eligible for the job. But the reality of whiteboard leetcode is that you're not screening for people that can code, you're screening out people that can have panic attacks. In my opinion, it is borderline disability discrimination.
>You start panicking and soon you have absolutely zero mental bandwidth to accomplish the task and your mind is basically singularly focused with getting out of this terrible situation
This is such a relatable description.
I don't think you even need a panic disorder to have this happen to you, this has happened to me a handful of times and it's absolutely the worst. It really is humiliating, totally ruins your day and you end up kicking yourself for several days after. I think this is just something that a lot of people do, like stage fright or something. The only way I know to avoid this is to do a lot of interviews with different companies that you don't really care about to get more confidence before you finally do get to the interview you care about, just so you don't choke during the one you want.
No. Some people have panic and anxiety disorders and need professional help and/or medications to help them. It is this kind of tone deaf advice, “just prepare more, you’ll eventually get it!” that prevents people with a panic disorder from seeking professional help for years. It is like telling someone with diabetes to just try harder to produce insulin.
And how beneficial is telling people they have a mental disorder if they experience common issues that even healthy people experience? A mental disorder has to significantly impact your life for a long period. A symptom list that consists solely of freezing up when put on the spot in a rare high-stakes situation is not going to qualify. Any teacher can tell you this happens to everyone. Stop right in the middle of lecture, point at one student suddenly, and ask them a quick question that demands a quick answer and wait. The most common response will be "uh!uh!..." even when they know the answer. It's about the situation itself that people weren't ready for, not the specific facts they were asked about. You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Spoken exactly like someone who has never had the pleasure of experiencing the vicious and debilitating feedback loop of a panic attack. Of course everyone gets nervous when put on the spot; panic disorders go well beyond that, to the point where you might believe your death is imminent during something like a routine interview, and your fight or flight response kicks in. Rather than concentrating on the problem at hand, your mind is focused solely on survival.
> You indeed need to practice retrieving information under the particular circumstances to build the confidence to not freeze up like that.
Is that part of the job description now?
What are these characteristics that:
1. Are present in the day-to-day work of a great many impactful software engineers that employers want to hire?
and
2. Do not discriminate against gender, gender identity, race, national origin, faith, sexual orientation, veteran status, age, and any and all other characteristics that employers are forbidden from discriminating against?
and
3. Are present and can be easily recognized in a leetcode-style interview keeping in mind that the number of similarities/amount of overlap between leetcode-style and day-to-day software engineering work is very close to zero if not zero?
True, though a lot of times the professional help will mostly consist of coaching you through how to "prepare more and eventually get it." The block is around taking the steps that help you improve. Yeah, medication is sometimes necessary, but exposure is a huge component of many different kinds of therapy.
Meanwhile on the job nobody is surprised or angry if you need to look up basics because they know you have five languages under your belt and are actively using three of them.
Yeah exactly this. "Figure stuff out without looking anything up or running test cases to see what they produce or going on a walk to think about it" is just not a useful skillset at all. I have zero, and I mean zero, times done actual work under those conditions.
Having said that, I am sympathetic to companies not knowing what to do that is better. There are real tradeoffs with all approaches.
I kind of think if I were to design the hiring system from scratch I would 1. Hire essentially anyone interested at the entry level for low paying 6 months apprenticeships, and 2. Hire more senior people based on their resume alone, with aggressive use of performance improvement plans for underperformance after 6 month or so probationary periods. I'm sure this idea sucks too.
I experienced this recently in a surprise 'shared screen' coding exercise the interviewers threw in at the last minute.
I couldn't even remember how to write a for loop in bash, something so familiar it would be like asking me to recite the alphabet. Utterly humiliating yet comical experience looking back.
At this point I'm convinced "candidate froze up" is the cause of most of the cases behind the "LOL 2/3 of our candidates can't even write a for loop" stories. I think it's really common.
Allow me to pile on here for perspective, in hopes there might be people who hire people on here who can take this into account...
A few years ago I was hiring for a non-coding role with a company that pops up here on HN periodically. The interview was entirely leetcode. I completely blew it because I was so flummoxed that this was how they were interviewing for the role. I tried asking some non-code related questions about the role and company and was shut down from even being able to ask - it was clear their expectation was that the interview process was a one-way street.
It wasn't the straw that broke the camel's back, but it was a chain of things that led me to finally conclude it was time to move on in my career. That is, jumping through these kinds of interviews might have been something I'd do at 20-something, but at 40-something I've got other options and am not willing to put up with it. The hiring process in the software industry is completely broken in how it assesses talent.
My crowning glory for the interview-stupids was relatively early in my career going in for a PHP interview, which was the language I was by far the most familiar with at the time and had written many thousands of lines in, and not being able to come up with the "->" syntax for method invocation & property access when I was up at the whiteboard. I used a dot-style instead, and realized only after I left that I'd totally fucked it up (writing some OO code on the whiteboard was just about the first thing they asked me to do, and the interview was really short after that...) I'm pretty sure I also mis-named some built in functions. I'm bad at retaining language-specific details and have since started reviewing a relevant language syntax minutes before an interview, which won't stick by the next day but usually does for a couple hours so I don't do anything too embarrassing. Not being able to put together two non-syntax-erroring lines in a language I wrote a few hundred useful lines of the day before, without a reference, is otherwise the norm for me. This has mattered zero times—except in interviews.
Do you want me to write fizzbuzz in proper syntax in some language I have on my resume and 'can do' but don't actually do every day without the help of an IDE? Forget it.
Can I write pseudo code that doesn't compile, is an amalgamation of various languages and probably understandable by anyone that can code even though there's probably no language w/ that syntax out there but it get the idea across perfectly? Sure!
foreach (number in numbersYouWantMeToFizzBuzz) {
if(number MOD 15 eq 0) print fizzbuzz
else if(number MOD 3 eq 0) print fizz
else if(number MOD 5 eq 0) print buzz
else print number
}
Don't have the {}? Who cares, you might be a python guy. Don't have the indentation? Meh you pass but my next question will be about formatting and what you think about applying a standard code style (and fail PRs automatically if it doesn't etc). You used % because your language uses that for MOD? Sure.
If it makes you feel any better, I can never remember BASH syntax. I have a gist where I keep all the common junk like for loops and array manipulation.
Never had that problem in other languages as I can generally remember after 3 or 4 repetitions but my brain just can't grasp BASH syntax.
The correct way to write more than 5 lines of bash is to delete the file and write it in python. You will thank yourself when you have to modify it later.
For some reason, I just can't remember things for life.
Despite being fairly experienced and having a rather solid grasp of Python/Go/JS/etc I still have to look up basic things like file modes (with bash syntax being especially notorious for being forgettable to me).
What I'm good at, however, is keeping references in my head, i.e. I know precisely what to Google to get the exact answer that I want. This way I compensate for my bad memory.
And for the record, I'm in my 20s. Sometimes I worry if it's going to take a toll on my career in the long run but so far it hasn't been much of a problem (apart from being a source of insecurities).
Your post reminds me of a joke punchline which was something along the lines of "an engineer doesn't actually have to remember very much, they only need to know how to efficiently find the information when required"
It's true for people working in technology due to the rapid pace of progress. As soon as we learn something it's out of date!
> Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do. Then your consciousness inevitably becomes obsessed with this thought and it's all you can think about. You start panicking
This happens to me all the time! You’ve described it so succinctly. How do you cope?
Some perspective from the interviewer side: just tell us straight up that you're panicking. While I can't guarantee that an elitist smug interviewer is going to always respond appropriately, I at least would make an effort to try to help you calm down, be it by removing trivial blockers (e.g. fixing some syntax blooper for you) or trying to paraphrase whatever you're trying to say but not finding the words for, or asking leading questions in the hope of bringing you back on track. A little dirty secret among interviewers is that we're supposed to be accountable for managing the direction and quality of the interview (i.e. one that devolves into a awkward staring contest is a failure on the interviewer's part for not interjecting appropriately)
Ultimately, it is in the company's best interest for an interviewer to look past things like nervousness-induced panic attacks, and I've heard on numerous occasions that good interview sessions involve the interviewer and candidate working together rather than adversarially.
Slow breathing exercises and grounding (e.g., look at the things around you and name what they are) work well for me.
Once it gets past a certain threshold it gets harder, so being mindful that one is coming on and routing it before it gets into a positive feedback loop is very important. Leave the situation you're in, e.g. tell others that something has come up and you have to go.
This topic of “is leetcode necessary?” and the more general topic of software engineering hiring practices appear regularly on this forum, but this time is the first time I am seeing someone mention panic disorders/panic attacks as part of the interview process. Other people might have mentioned it before here, but I do try to peruse the threads that relate to interviewing.
I am really grateful that you brought up this point as well sharing as your own experience 'ryandvm. My own experience when I fail to think of an answer to a leetcode question is extremely similar if not identical. I would add that my own experience is always a silent panic similar to how I experience going on a rollercoaster. Many people will scream out loud when they are going down a rollercoaster; I just clench the safety/restraining bar really, really tight and look onward while clenching my teeth. I am surprised that it took this long in my career to hear similar feelings expressed by someone else, but I am grateful that it did.
If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team? Stressful situations can occur in software engineering, including for example a moment where you realize production services are broken because of code you just deployed.
Interview pressure is nothing like an emergency. I'm cool as a cucumber in an emergency. Hell, I kind of love them. Interviews are another thing entirely.
[EDIT] What I'd liken an interview to isn't an emergency, but a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one. That's closer to what it is, than an emergency. That also makes it very unlike nearly all activity anyone engages in at work, emergency or routine, social or solo, except for certain high-pressure sales or top executive jobs, maybe.
I’m normally cool under pressure and able to solve technical problems quickly. But in a situation where what matters isn’t actually solving the problem but evaluating my performance and my brain goes into overdrive with perfectionism/meta thinking about what they are thinking about me to the point where I sometimes can’t even do basic math.
Exactly, I have been in such high pressure situations several times with directors and CIOs breathing down my neck, but surprisingly I am quite composed in such scenarios. Severity of the problem at hand is in fact liberating as it is easier to focus. But that is not the case with interviews, when there is a strong "me" factor in the thought process.
> a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one
Great quote. Those feeling pretty much summarize to perfection the current fad of interviewing pressure.
As for those who code without guns to our heads, I'd take the candidate who ships well-tested code over the candidate who ships emergency code. Prefer few large fires over frequent small ones and just roll back.
If I were that hiring manager I would have the wisdom to know that this provides no signal whatsoever of how successful those people would be on my team.
Edit to add: The kinds of pressure experienced on the job are not at all the same as those experiences during an interview. "Doing well under pressure" is not a generic skill. Someone who freezes up during an interview may be the coolest head in the company while restoring a database backup during an outage, and vice versa.
> If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team?
It's completely different, not even remotely comparable.
The pressure during a real-world outage is not a big deal. It's collaborative, we're all trying to solve this. And the work that needs to be done is actual real work. I'm extremely good at that, so I basically feel no pressure at all no matter how high the stakes are.
Interview pressure though? Whole different monster. It's confrontational and I'm expected to basically do improv acting on topics that have nothing to do with the actual job while someone nitpicks and eyerolls every irrelevant nonsense.
Your comment is not factually incorrect, but it takes a lot of logical leaps. Let's say: if all other things were equal, would you want to hire a candidate who has worked with just 1 programming language throughout her career or someone with experience on 5 different programming languages?
It's probably correct to answer "the person with 5", but does it automatically prove that "# of languages under the belt" is a great metric for evaluating engineering prospects?
We can come up with all kinds of justification for the current state of engineering interviews, but most everyone conducting the intervews know that our methods are extremely primitive and are thirsty for a better path forward.
I think I'd want the smarter candidate regardless in a job like software development that is overwhelmingly based on quiet focus time. It's easier to help them work through the rare emergency, than to help a less-skilled employee work through literally everything else.
But just blanking when suddenly put on the spot happens to everyone. Human memory retrieval is a complicated process, nothing like a computer. You can have vast expertise in there but not be able to retrieve it instantly, unless of course you've practiced interviewing that very subject a lot recently.
In the production issues I've been involved with, I was not forbidden use of Google, API docs, consultation with others, etc., and I did not have to work out anything on a whiteboard.
> Basically for some random reason, the thought pops into your head just how disastrous it would be if you failed at this thing you're being asked to do.
Like a driving test and the training with parents/adults beforehand.
Even with some judgmental/skittish passengers its the same.
We need a credential that counts as passing a technical interview, so we don't have to take these tests for every single job that we apply to.
If I pass a coding test, stay at a company for a year, then apply to other companies, I'm going to subjected to coding tests even though I just passed one only a year ago. It's like companies are afraid that programmers will spontaneously forget how to program.
A credential's test is not limited by the very time constrained format of interviews. This means it could ask more questions to reduce false positives. People would be willing to invest time because it saves them the hassle of interviews in the future. A centralized testing entity could work to reduce cheating instead of every company having to do that themselves. Plus, administering this test would be full time jobs for folks, so it would likely be a higher quality test than what most companies give.
> If I pass a coding test, stay at a company for a year, then apply to other companies, I'm going to subjected to coding tests even though I just passed one only a year ago.
Well it’s not like the company you’re applying to has access to the test results from the company you’re leaving
> It's like companies are afraid that programmers will spontaneously forget how to program.
To be fair, I think most leetcoders agree that you need to practice regularly to keep your skills up. So if the point is to see how good you are at thinking algorithmically for the job you’re applying for, it makes sense that they’d want to see recent test results.
Well, the test result is pass/fail, and if you can verify I worked at a previous company, then you know I passed. The legwork might be finding out what their interview is like.
Every skill degrades without usage, but if you can verify that I've recently used it successfully, I'm not sure why I'm being tested on it again.
> Are you proposing waiving technical interviews for people who worked in "reputable" companies?
Yes, of course. If you have a degree from a recognized schools and many years of experience at the job, why would you be hazed on undergrad trivia you've forgotten decades ago?
None of my high school friends who went into accounting, finance, medicine, law, etc have this problem. What is it with the dysfunctional hiring BS in software development?
A surgeon with many experience at a top hospital most certainly does not get grilled on organic chemistry trivia from their undergrad classes when chaning jobs.
I mean, if I ask each of the engineers at a company I'm about to join to do a live coding test, they'll just tell me to go away.
The reason I would ask this because I don't want to join a team that writes bad code.
They would tell me that each engineer did the same test and passed.
I would then say, "I don't believe you, I demand a live exercise so you can't cheat and help each other out". After all, their skills could have deteriorated since they joined!
People are only offended because companies don't believe our past demonstrations of competence.
You get to see their standards when you interview with them. You are free to decline their offer if you feel that the bar was too low, and maybe their engineers write bad code. On the other hand, they do not know the standards of the company you came from.
In 20+ years, I have rarely seen a technical interview actually be indicative of a team’s standards. I’ve seen good, bad, and much in between, but mostly I’ve found the “standards” communicated during the interview to be purely aspirational at best.
> We need a credential that counts as passing a technical interview
So we could call that a degree? And have institutions that specialise in testing for it? And because some of those institutions will be better at measuring this, we could rank them?
I thought most people complaining about the current approach didn't like this one either.
An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines. You have to go do a different credential to start putting together buildings and bridges.
Having a Medical Degree (Doctorate in Medicine), doesnt mean you are credentialed to be a practicing doctor either. Doctors btw dont get asked to "go diagnose this patient real quick" during their interviews.
Credentialism in tech is an interesting rabbit hole. We basically do have nurses vs doctors with degrees of speciality, but some places pay them all the same. Some places do pay the backend engineer differently from the front end guys.
Its well known that bare metal C engineers are not making as much as React devs in alot of cities, and most people seem to broadly agree the C engineer has a harder task than the React one.
So we would need to figure out whats the CNA/LPN/NP, doctor, general doctor, brain surgeon, and veterinarian of our fields. But it's not quite so simple right? We might think front end where you are grinding out simple React or PHP apps is easy, but if you are a front end dev on a billion plus dollar selling system or with very high stakes stuff going on you probably do want a "doctor level" dev right? You probably dont need the AI dev though (the brain surgeon) if we continue the analogy.
> An Engineering degree from even a prestigious University doesnt make you an Engineer in many disciplines.
A US-centric view. My (Swiss) engineering degree certifies me as a software engineer ("ing. info. dipl. EPF", whose use is legally restricted to actual graduates).
I think the suggestion is for something more like the Bar Exam.
At least in California, you don't have to go to law school to take this exam, and if you pass it you are just as qualified to practice law as someone who did go to law school. I doubt that happens very often but at least it's possible.
OTOH a Software Bar Exam would probably be much worse than the leetcode grind because it would inevitably become something you can only realistically pass right after finishing a very good CS degree, or equivalent study, in your 30's at the very latest. And it would become a de facto requirement for the better jobs, making the privilege bias even worse.
I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.
A qualitative hiring interview would be perfectly fine if the interviewers had no discrimination in their minds. The real solution is having minds without it. It's probably a goal hard to achieve with grown up people. Easier with newborns. So any solution starts from their parents, grandparents, etc and will stretch over many generations. Education, mingle with people from every origin and background, etc, pick your favorites.
How many generations? Limiting ourselves to the USA think how long it took for women to get a vote since the Constitution and for an Obama to become president since the end of slavery. We can hope that the trend is accelerating but who knows what's going to happen next. The state of the rest of the Western world is not so different.
This is the optimum. Now the good because there will be interviews to do this year. Any stop gap solution would do but don't invest too much into it because if you don't remove the real problem any fix will be worked around.
> I think that most people here are mistaking the finger for the moon. If discrimination is really the reason why we have this kind of interviews, the problem to solve is discrimination and not the hiring process that is attempting to fix it or to hide it.
Agree in that if discrimination is the problem, then thats the problem that needs fixed. But, if these companies really wanted to solve the problem of discrimination then they would be making efforts to do so besides leetcode.
I saw it mentioned earlier in this thread, people can subconsciously discriminate without necessarily realizing it from something as simple as seeing someone's name, their voice, appearance, etc. It's not that the hiring manager is consciously racist but they may have a picture in their head of what a "software engineer" looks or acts like, and if the candidate doesn't fit that mental model they are dismissed regardless of their skill.
In that case, why not anonymize the candidates as much as possible? Don't let the interviewee and interviewer see each other during the technical interview, don't even let those making hiring decisions see their name, distort the voice, etc. Make it as close as possible to "anonymous person A being asked technical questions from anonymous person B." Make the hiring decision and only then de-anonymize the candidate.
I recently had an interview for an ops role (sysadmin type) and was asked a series of PowerShell questions, normally no problem - but the interviewer wouldn't accept "I don't remember the exact cmdlet, but I could do Get-Command Get-xyz* to find it" as if they expected an encyclopedic knowledge of every powershell cmdlet ever made. On the actual job built-in help exists, google exists, KBs exist, etc. Why would I ever be expected to have all this information in memory when the resources to find the information I need is a keystroke away. Test for understanding theory and methodology, not specific commands/language function.
People still have to see people to work together unless we spend all our time in Matrix like cocoons. When they see each other and don't like what they see somebody gets fired or mobbed.
We can't expect companies to solve social problems. It's not what they are built for. They can hack around problems, create plausible deniability or anything else and that's all.
People solve social problems. I wasn't alive when they happened in the 50 / 60s but I saw recordings of people doing Civil Rights marches etc, not companies.
No. One of the reasons those leetcode interviews happen is because existing credentials, such as a bachelor's degree, don't work. Adding another one that some hirers will value highly and others will be skeptical of doesn't solve anything.
What we really need is for companies to stop trying so hard to find the absolute best most perfectest candidate that they screen out huge numbers who could have done the job but who missed some arbitrary keyword or coding test by a fraction.
IMO, I think we just need a way of easily firing people if they suck. It's very very difficult to termi ate without fear of retribution so the barriers to entry just keep getting taller.
If we could take a gamble on people and see if they sink or swim we could give a lot more opportunities.
It's not hard. At virtually every small company I worked for, not only is there no leetcode bullshit, firing wankers is as easy as giving them the termination slip. US has at will employment, 'you've been fired' is literally all you need to say, no explanation is required. You get hired after a conversation with a CEO, in my experience the hiring and firing process are both completed in under an hour.
I work at big companies. It's basically impossible. You have to transfer them to Milton's basement office and pray their inflated self-evaluations make them look for a new job.
>I think we just need a way of easily firing people if they suck.
It is very easy to fire someone, especially in the first 90 days. Most states are "at will," meaning you can fire anyone at any time for any reason (outside protected classes) and the employee can leave at any time.
Legally, it's easy. But getting the HR bureaucracy to go along with it is a long and unpleasant process. The last time I fired someone for doing no work at all and arguing over everything, it took about 8 months.
Unfortunately, my company is not unusual in this respect.
There are a lot of companies without HR. Due to my background I haven't been hired for for a company with an HR (other than contract work) for probably a decade. If you want to hire and fire people easily, look for small companies, usually less than 20 people. Beyond that the CEOs tend to get tired of dealing with human administrative tasks, so it gets offloaded to HR. CEOs have a lot more risk tolerance so naturally when HR gets involved they focus on saving their own asses (which usually means taking low-risk rather than highest profit) rather than the good of the company.
> We need a credential that counts as passing a technical interview
This idea already exists in many forms. Pick any language, platform, or technical concept and there's someone offering training and certification.
It also describes the whole recruiting industry. "What if there was one person who did a lot of interviews and then presented just the best people to employers?"
It's an extremely human incentive alignment problem. Any certification program, interview farm, or bootcamp that makes more money when they produce more candidates will make quantity the goal, not quality. If you can figure out that problem, maybe there's a niche. Otherwise, it puts us right where we already are.
The trainings and certifications won't let you bypass technical interviews though. There's still inherent distrust of them. We need a credential good enough that companies can trust.
Most of the recruiters I deal with are only doing screens and maybe soft interviews -- I may be on the lower rungs of the ladder here though.
For the last point, I'll offer Offensive Security as an example because I have one of their certs. OS wants people in its programs as we're a source of income, obviously, but they don't get revenue from people passing. In fact, they get more revenue if you don't pass because they charge per attempt. They offer training for organizations too.
They also act as a verification service for their certifications:
The idea for a programming credential would be the same: an organization that offers training, doesn't make money on pass rates, and also is a trusted point of verification.
Some companies have offered to do technical interviews, then pass you to employers. This is a start, but it isn't industry wide.
Maybe run the testing and evaluation side of things at cost. The certifiers instead get profit from companies that subscribe to their certification verification program. There's a small fee for the employer to verify someone's certification is genuine. Part of the employer's contract with the certifier would be that anyone the employer hires who has been verified to be certified, when they've been employed at the company for a year, they owe the certifier a bonus. There's a second bonus at five years and that's the end of the payments. The certifier is incentivized to only certify workers who have genuine skills as those are the ones most likely to hit the one and five year milestones. Talent acquisition is expensive, as is employee turnover, so employers will not have an incentive to layoff employees right before their employment anniversary in an attempt to avoid the fee they owe the certifier. They'll find that the anniversary fee is a small price to pay for having been matched up with an employee with the actual skills the employer needs.
I took a brief look at a CS GRE test prep book from a Google search, and it probably doesn't cover the same things leetcode does, nor does it really test code writing ability (because it's multiple choice):
If the true purpose of algorithm tests was to be non-discriminatory, the interview and interviewee should not be able to see each other, their voices should be masked to hide nationality/accent, and resumes should not be viewed when solving the problems. I assure you I can still discriminate against a candidate both consciously and subconsciously during a live algorithm question now.
I guess one upside of these types of interviews is I've been able to disqualify candidates just because I don't like them and saying they didn't do well on the algorithm question as justification is a easy way to reject them without much explanation.
And what about every other field that doesn't use leetcode style interviews? Does a biotech company make their interviewees do lab work live? What makes software engineering so special that we need a different interview process?
I don't think that much thought has been put into it IMO. It's cargo culting the google interview process, and no standout success since google has a very different interview process to cargo cult copy.
Google had this process because they are very academia inspired and want to hire the best academics, with a college campus but better work experience, because they had very high back end scale requirements, where algorithms do matter. They also had a shit ton of applicants and favored the false negative over the false positive, which they explicitly and publicly state. You might be able to argue that scale doesn't matter as much at google anymore, but google has no reason to change its process since it first established it, and back then they really had those hard scaling problems to scale up.
The reason why the software profession tends to have extensive interviews is because we don't trust credentialing or even prior experience. [0] We don't want to hire the unskilled bozo who can talk and have brand name credentials but when you actually put them to work find they are not that good at all. So we actually test their skill as directly as possible with various forms of work sample testing with as long as an interview process the market will tolerate, which has stabilized to 5 - 7 hours, or an entire working day.
The beauty of this is that you don't need to get into a med school equivalent with it's crazy requirements, spend 10 years-ish of training and go into 6 figures of debt, get a residency / hazing ritual in a few limit slots in the USA and can come from almost any poor background or country even and eventually make more than most surgeons. In that light, needing to spend 3 months to hard core leetcode doesn't seem so bad.
> favored the false negative over the false positive, which they explicitly and publicly state
And willing to take false positives -- good at grinding for interviews, bad at actual work -- and just carry that dead weight forever in order to get the true positives who keep the money machine whirring along.
I've come to realize this is hard for many to swallow, but as much as it feels unfair -- just like only hiring from Stanford and MIT -- it was an enlightened business decision for Google. The cost of the dead weight is a rounding error on some distant Sheet, and the opportunity cost of the false negatives can't be measured anyway.
When they say they favor the false negative, that doesn't mean that false positive wont happen, is they would rather tradeoff a with a process that produces more false negatives if it produces less false positives because they have a firehose of applicants to chose from.
I think they realize their process isn't perfect, and worse of all, all processes are imperfect and this is the tradeoff set they've chosen. Google also tracks how successful people are after the interview process, so there is a feedback loop inside it. I think it's partly why they dropped the degree requirement from applicants, because their internal data showed no correlation with internal google success.
I think leetcode is bad, and I've tried to get interview processes to change to go full work sample at my big tech with relevant coding exercises, but it's hard to do! And in some sub-specialites where you are implementing graph algorithms and more, a subset of algorithms is in many ways a relevant interview question.
I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.
Before leetcode we had microsoft defining the industry interview process with bullshit lateral thinking puzzle questions, and now nobody knows about their existence, nobody complains about them on HN and you never, ever run into them. I think in 10-15 years, leetcode will be the same and we will all complain about impossible work sample coding exercises and take homes.
>I think slowly the industry is moving away from no-leetcode, but it's going to take a generation or two of startups to really succeed at that, and most vital of all, it has to become a FB / Google level company that defines the industry for the next decade. The current millenial and gen z wave suffering under the leetcode regime and think it's bad need to become the next directors of companies and push for no leetcode in their interview processes. This is just starting to happen which why you see some companies like slack doing no-leetcode in their interview process.
in other countries LC is not that common
I've never been challenged with algo questions - just purely day2day stuff, but those were software houses interviews mostly.
I have yet to meet someone who can talk the talk but can't walk the walk. But I am technical, so I think you need a technical person to evaluate that. The risk is when non-technical folks evaluate the technical and they can be fooled.
Leet code is the equivalent of math word problems. What they show is problem solving ability with algorithms and code. That's a different skill set. Almost like an IQ test.
It's very rare that people intend to be racist. Rather, they have intuition of what a "good programmer" is in their head, which is subjective, and thus more likely to be discriminatory. If you give them an leetcode question and a rubric to grade their performance, it's hard to deviate from that rubric to much unless if you're intending to discriminate.
>Does a biotech company make their interviewees do lab work live?
Not biotech, but according to my cousin, pharmaceutical research interviews are even more arbitrary. He had chat with 5 employees who asked questions about their own rather esoteric specialties. Most of the questions were completely unrelated to the work that he ended up doing, and my cousin thought that the interviewers themselves were unlikely to be able to answer each other's questions. Unlike leetcode, this isn't something you can predictably study. It just so happened that the labs my cousin had worked in happened to specialize in those same niches. There are so many qualified postdocs that want to move to industry that interviewers can afford to be picky.
This is probably very dated, but when I worked in biotech the interview process was just about 100% trying to find a "culture fit" (to be fair, in an industry about a thousand times more diverse than software) and politics. If the hiring manager brought someone in then you assumed it was on them to have screened for competence, and you wanted to figure out which candidate you'd like to work with, and/or figure out which candidate was favored by which person in power so you could vote advantageously.
It is common for up to mid-level jobs in finance and consulting to require doing on-the-fly modelling and analysis in Excel. I am pretty sure things like structural, mechanical, or chemical engineering also have substantial technical components to their interviews. While it is not done directly by the employer, board certification for doctors entails 8 hour long tests. Similarly, tradesmen like plumbers and electricians require in-depth written and practical tests for licensure. You can definitely dispute the practicality of these for the job vs. leetcode, but I really don't think that the rest of the world is getting jobs with a resume and a firm handshake.
> What makes software engineering so special that we need a different interview process?
The combination of absurd profitability (of which the tiny slice allocated to employees still seems like a lot) and a complete lack of any actual objective measure of quality.
Because there's no way to really test whether someone is good at programming other than hiring them and seeing how it goes, and because there is an effectively limitless amount of money to spend trying to organize a "solution" to this problem, and because learning enough about each candidate to make a properly educated guess doesn't "scale" enough for fast-growth companies, senior management has plenty of room and lots of incentive to look like they've got it figured out.
For some, this is following their creative whims; for most, it's "do what FAANG does because it must be working, look at all the money they make."
Anyway that's my opinion on it. If I ever have the power to change hiring at any large scale, I'll probably follow my own creative whims and make it even worse.
I have conducted a fair number of interviews and never been surprised at their on the job skills. I really don’t see much of a difference between interviewing people for coding positions and management etc.
Leetcode style tests meanwhile are simply a waste of time. I might as well ask someone if they have seen that problem before and know the trick.
Here's an actual study with real data. All women failed the leetcode challenge when grilled (probably by a man). They all passed when allowed to do it in a low stress environment.
Interviews are, by definition, a way to discriminate candidates based on some criteria (using the dictionary meaning of word here). There are certain classes that are illegal to discriminate against (e.g. religion, ethnicity), but things like education are totally fair game. Airlines, for example, use physical fitness as a discrimination criteria under the rationale that a flight attendant must be able to function in the rare event of an emergency.
Just because a criteria doesn't match one's notion of "fairness" doesn't mean it's inherently a bad criteria. If Google wants to only hire people that are good at cracking leetcode and that ultimately leads them to have their current reputation of being out of touch, that's kinda on them.
I think the problem here is that any criteria you use to choose one person over another is discriminatory -- that's the dictionary definition of discrimination: the choice between multiple competing options.
The problem isn't discrimination, it's unfair discrimination -- that is, discrimination on the basis of something that should have no bearing on a decision to employ someone.
Any criteria you choose will rule out people who aren't able to optimize for those criteria for whatever reason. I believe that's OK, as long as you are aware of the tradeoffs and try as much as possible, in good faith, to minimize unfair criteria while maintaining those criteria that help you hire people who have the best ability (or potential ability) to do the job.
Giving each applicant a tailored test also opens yourself to allegations of discrimination.
As for leet code vs an actually relevant test - I think this is probably laziness on the interviewer's part. Coming up with a good test (and keeping it up to date) is hard, and leet code questions are "good enough" to filter out the people who don't know what they are doing. Remember, most companies are fine with a high false negative rate if it keeps false positives low.
Is discrimination even illegal? I thought unless it was a protected class, discrimination is ok. Unless you're giving all black people a shittier test or something I feel like it's a long and expensive road ahead of someone pursuing legal action, with probably not much to gain and no attorney particularly interested unless it is some class action against a big company.
> I thought unless it was a protected class, discrimination is ok.
That is also my understanding, but everyone except young white males are in a protected class. Granted, young white males are pretty common in tech, but you would still be wise to design your HR practices in such a way as to avoid lawsuits.
Agreed it would be wise to consider lawsuits when hiring. I do think though that's only one part of the equation. What you want to really optimize for is maximizing profit. Maximized profit may mean paying out lawsuits is cheaper than losing good candidates or implementing a poor or ineffective hiring process. There's also the risk of implementing a hiring process for which the expense of minimizing lawsuits is greater than the potential lawsuits themselves.
> It's just as easy to argue that leetcode-style interviews are because companies are afraid of being discriminatory in hiring
From the hiring side, this is 100% correct. Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired, without any type of technical interview. That results in people hiring other people who are as similar to their own backgrounds as possible (everyone likes to think their own background and learning style is optimal).
We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
> or give take home work (because it's discriminatory against people with time constraints)
IMO, this complaint is baseless. A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
> Giving everyone the same coding interview is one of the most effective ways to remove interviewer bias.
I'm sympathetic to the hiring side argument. But, I don't think the parent comment is insinuating that no technical question or test be asked of the applicant. They're not insisting on trust, they're insisting on showing their own intelligence. They're saying that the test or technical question should be directly applicable to the job at hand, for the company at hand. You can just as easily ask every single person who applies the same specific questions for the role at hand in your company. You don't need to rely on generic leetcode questions if they don't specifically apply to the job at hand.
In other words, hiring needs to actually be specific and targeted rather than adopting the "cast a wide net and catch whatever we can" strategy that many places seem to employ.
9/10 it feels like the insistence on leetcode from hiring comes as an excuse for rather weak recruiting standards and practices.
Leetcode or "just trust me" feels like a false dichotomy.
Biotech interviews, for example, are usually conversational: what have you worked on before[0], how would you tackle this new problem, or troubleshoot a particular problem. There's this persistent meme that charlatans can BS their way though such an interview, but I really don't see how someone could learn enough to parrot their way through 4-5 x 45 minute meetings, often with fairly probing questions. It felt quite a bit like a thesis defense, in fact.
It's true that these aren't "repeatable": each applicant won't have exactly the same experience. This is "unbiased", in a sense[1], but has enormous variance: you're not only testing the applicant's aptitude, but also whether they've encountered this particular problem before. OTOH, tailoring the interview to each applicant' strengths might inject a little bias in exchange for a massive reduction in variance.
[0] It does help that candidates for these jobs had masters/PhDs, and therefore had at least one project they could discuss publicly.
[1] But not really...There's a subjective element to "code quality", fluency, whether the applicant wrote "enough" tests, etc.
My guess (I have no experience in the biotech industry) is that this is largely because you can't run an hour-long experiment with the candidate to test their competence. They must rely on a conversational technique. I don't know how much we can compare software with other industries.
The software industry is unique (or so we think) in that we can directly test a candidate to judge their competency in an hour, either by white-boarding or going over a take-home problem (or similar).
I think you could dream up some one-hour tasks if you really wanted to. The issue is that they'd be so obviously unrelated to overall job performance that the process would be self-evidently silly.
I'd argue that software is similar: projects don't falter because it takes someone five extra minutes to run a gel (or implement a red-black tree); they fall apart because people don't think about whether they ought to be doing that at all.
The most effective hiring process I've been through is one where there was basically no interview, I was given contract work to perform during which I was compensated for necessary company tasks with no real expectation of enduring relationship. After a few days of performing tasks to the satisfaction of the company, I was offered a permanent position.
Not only did this process eliminate the BS, it allowed me to perform a task in a relatively low-pressure but high yield setting while simultaneously not exploiting me (I got paid) and allowed the employer to see how I would actually behave as an employee. This is also the longest and most successful position I've held, partially because there is no lingering bitterness and hatefulness I've harbored at those expecting me to solve bullshit problems for free, like some kind of performing monkey.
> We know LeetCode style tests aren’t perfect, but they’re repeatable and the study material is free and widely available.
One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question. I don’t want to dismiss the value of someone being able to study a skill and learn it, but I see a lot of people fixated on rehearsing leetcode answers like they were magical incantations you recite to get jobs, there’s not always a lot of real learning happening. That’s not reflective of the kind of candidates I’d want to hire or the peers I’d want to work with.
> A lot of companies give the option of LeetCode style interviews or take-homes and almost everybody chooses the take-home.
If true I’d like to see more of this. No hiring process is good for everyone and I think flexibility can be a better way to make a process fair, but I haven’t seen much of it personally. I don’t think I’ve personally gotten a leetcode problem at an interview in years- takehome problems have been the more common screening tool, but I don’t think I’ve ever been offered a choice in the matter.
> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I’m not sure this is entirely on the mark. On problem with takehome a is asymmetry. Most take home assignments I’ve gotten have come toward the end of an interview process, and there fine, but when I talk to more Junior folks it seems like they are often given hours long takehome problems before they ever talk to a human. That seems disrespectful of peoples time- it’s a lot to ask from someone who doesn’t even know if they are a fit or want your job yet.
In any case the hours long takehome is usually in addition to an bourse long set of interviews- not in lieu of them. Another common problem pre-Covid was that a lot of people just weren’t set up to work from home so it was harder to get the space and time to work on a project at home. I expect that’s probably changed a lot these days though.
> One of the things that gets me here on the hiring side is that the ease of “grinding leetcode” as a strategy seems to defeat the entire purpose of it as an interview question.
I think that's irrelevant for FAANG and friends. They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant. The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
Now, companies paying half or less what FAANG does and trying to do anything remotely similar, are simply making a mistake. People with a tolerance for and ability to pass those kinds of interviews are going to apply to the much-higher-paying options, not to your company.
> They pay so high that they can afford to make their interviews so miserable and time-intensive to prepare for that tons of people never even try, purely as a first-pass filter. They don't care that you can prep for it, they just want it to be (exactly the right amount of) scary and unpleasant.
This is something I completely agree with. I'm not so sure about the motivation though.
> The resulting, self-selected group probably is, in fact, far better on average than the set of all software developers, including those who never apply to those sorts of jobs (but might if the interviews were less awful). Furthermore I think that's why some results show that they could randomly select candidates and do about as well as the interview process does—sure, maybe, but they could not do that if the set of people applying wasn't already heavily biased to have a fairly high average skill level (& IQ, that's absolutely part of what they're filtering for).
This is where I disagree, and my disagreement comes in two parts. First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure? I don't have hard data, but I'd guess no in both cases. I've certainly known plenty of early career people who get obsessed with leetcode grinding, and I've never known them to be any better on average than the people who don't fall into that trap. What they are better at is letting themselves be convinced they need to work long hours and burn themselves out for an opportunity. The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
> First, is programming skill what this is actually measuring, and second, is programming skill what this is intended to measure?
Yeah, no, and, no. I agree.
I don't think it's measuring programming skill. I think there's a strong enough correlation between that skill and being willing and able to study for & attempt their interviews that simply conducting them the way they do yields a set of candidates who would practically all be acceptable hires—but they can't drop the unpleasant and/or useless parts and make them easier, or that would stop being true. There are definitely lots of people who'd be good, or even great, that it excludes, but I don't think they care, probably regarding the cost of finding those folks as too high to be worth it. As it is, it barely even matters how good a job they do of weeding out candidates who show up. Most of them are probably good hires (for what FAANG is looking for, which is some combination of IQ and "how bad you want it", as far as I can tell).
> The cynic in me says that's what these companies are actually selecting for, although it's likely at least some people involved in the decision making aren't doing it consciously.
Heh, yeah, I agree that's likely part of it.
I think there's also a hazing component. Hazing is effective at creating strong in-group sentiment and bonding, in a hurry.
Overall, I think measuring programming ability has almost nothing to do with why they do what they do. I also don't think that necessarily means it's ineffective at achieving their goals. I think complaints about FAANG-type hiring, when directed at companies that pay in the top-tier, are misguided for that reason. I also hate them, and don't think they're good at measuring actual programming ability, but I think there's likely a non-crazy (though a smidge sociopathic or cruel, maybe) point of view from which they are the right thing for those companies to do.
It sounds like we’re mostly in agreement. I’m not sure they are actually the right choice, because I tend to think that companies that are trying to operate at such a large scale would be better off having a broader set of type of people working in engineering, and they necessarily limit themselves too much by insisting on their interviewing approach, but I’ll admit that I’m bringing a lot of my own bias about what a good company looks like into that view of the world.
> The idea that someone can allocate several hours during their busy day for a live interview but somehow can’t find several hours during the week for a take-home doesn’t even make logical sense.
I personally like take-home problems. It's hard for an employer to time-box them without resorting to basically leetcode though. I know that, as a student, I definitely spent many hours on them.
> A lot of HN commenters advocate for a “just trust me” hiring process where they want the interviewer to just read their resume and have a quick chat to decide if the person should be hired
That's how your manager is going to be hired, as well as all of his bosses on up.
SWE manager here, at multiple well known companies, and this isn't how it's worked at any of them. Some of them I've had to do leetcode interviews while at others, it was important to know aubergine who could vouch for your work. Could just be me but I've never experienced the "I just have a good feeling about this guy" supply t if interview.
"He goes golfing with Jerry" isn't going to eliminate bias, but you can absolutely get jobs in management on that basis. I don't think any of my managers could do a leetcode hard off hand, I may have worked at the wrong companies.
I assume your CIO also took a LC interview as well. I believe parent's point is that this front line hazing commanding competency is moot when orgs are hierarchical in nature and you needent step far up from a leaf node in an org chart to find someone hired on "just trust me, here's where I worked and what I did."
At some point a technical interview rightfully doesn't make sense for a role (at least by itself), some transition up the chain typically needs someone who trusts a technically competent person below them and uses their advice. These transition layers really require someone with business acumen and technical acumen which are often unicorns, not in these positions and if they are, are not in a position to command change upwards. You need to really understand business direction, financials, market pressure and so on while also understanding all the technical challenges. You also need people who don't override your assessments frequently.
What usually happens though, from my experience, is you have an interface in the hierarchy where someone above understands a touch of tech but is primarily business and human management focused and a person below them knows a little business but is primarily technical. The bias will typically ignore, override, or pressure the technical challenges based on business focus in this structure. That bias comes from someone who didn't take LC and doesn't understand the technology or problems often at all.
There's this weird mindset in the software industry that by hazing one another and pushing for only the most skilled engineers at leaf nodes of an org, we can command change upwards or at least make our lives better by filtering out incompetent teammates that make our lives more difficult. Meanwhile, none of this matters to me in the big picture if someone is technically incompetent up the chain yet is pushing technical decisions either directly or indirectly that makes life miserable for very technically competent staff. You can have the most competent staff in the world with incompetent leadership. In a best case they're hands off and have a nice gig where their department makes them look good while they do nothing. In a worst case, they get actively involved in areas they shouldn't.
One may argue this only happens in bad orgs, and that could be correct. In that case, the bad orgs vastly outnumber the good orgs. I don't think this is the case though. Technology is typically to some degree considered a cost center for any business, even technology focused companies (its a cost center until certain efforts prove their value). It's a means to an end to keep afloat and make money so business interests will always override technical interests and this is very often embedded in the very power structure of a given org. Someone above you didn't LC, someone just trusted them during their interview, and now they tell you what to do. Maybe they're competent and didn't need to, maybe they're not.
I have a good friend who was a world class (quantum) chemist well recognized in his field and a technologist by heart in an S&P 100 scale org. He held the role essentially akin to a Fellow or Senior Fellow at a place like Google in a Fortune 100 chemical industry leader (the next step up would be something like VP research IIRC). He was frequently overriden by VPs that had no inkling of the science or technology needed to accomplish the baseline innovation business that made them money. So no matter how competent he and his staff may have been, someone who didn't care or was incompetent around the issues commanded decisions that effected him and every department he lead. This is in an org where someone doing real daily scientific and technical groundwork was able to interact at executive levels. Some of this leadership probably couldn't identify lead on a periodic table if their life depended on it (and they might not need to, assuming they listen to people who can), yet to get to the role just below them, you needed to be a leader in your discipline.
Irrelevant - a CIO's job isn't to be a hands-on coder, it's to set a strategy and manage an organization. Companies do a good but if due diligence on that, which is why it's really hard to break into the executive ranks - you have to find an opportunity that can grow into leading a large team because no one will hire you to do so if you haven't before.
Purely by chance, the last place I worked that had a CIO title, my LOB CIO probably would have had a good chance at passing a Leetcode interview, despite managing 10,000+ people.
This strikes me as one of those linguistic squabbles - along with changing the definition of literally to include figuratively - where we just need to accept that language evolves, and usages that may be historically correct aren’t necessarily justifiable in a modern context.
I also only use literally literally. I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her. You've got 1400 years of English language momentum to overcome if you want to change the meanings of established words.
> I refuse to tell my daughter that "One small step for a man, one giant leap for mankind" effectively equates to "this one is for the bros!" or that "all men are created equal" doesn't apply to her.
No reasonable person is suggesting that we need to eschew historical context and nuance to redefine statements like these. At the same time, we should acknowledge that language isn’t immutable - as 1400 years of English language momentum can attest - and there’s nothing inherently wrong about its generational evolution.
> and there’s nothing inherently wrong about its generational evolution
If you make literally mean figuratively as well, it loses all meaning. In what context is that word ever useful? It describes literally everything. Making the language less expressive and more difficult to use is wrong.
In the same sense, is the idea that I now have to look when a particular piece was written to understand how to interpret the pronouns? How does that make the language better?
I'm all for improving the language. Slang, new words, new idioms, have at it. I just don't see how either of these changes improve the language.
> In the same sense, is the idea that I now have to look when a particular piece was written to understand how to interpret the pronouns? How does that make the language better?
We already interpret language through the lens of its era all the time.
For example, when's the last time you heard someone use the word "gay" to mean "happy" or "awful" to mean "awe-inspiring?" They have very different colloquial definitions today, but when I hear the Flintstones theme song I know what "have a gay old time" means, and when I go to church I know that the hymn "God of awful majesty" isn't sacrilegious.
Including the definition of literally to include figuratively reflects how it is used by many, and dictionaries should do that. But it's possible (and my hope is) that it eventually goes out of fashion as a filler word for twitter-facing teens trying to sound smart, and effectively goes back to meaning what it meant before, since its literal meaning is very useful and specific, and will stay relevant beyond historical use. The new "meaning" is really to be meaningless, which is not what I'd consider an advantageous mutation in the evolution analogy.
Thank you. I noticed this a lot on HN, but I don't know how to react. There is a common presumption that co-workers and managers will be men. It bothers me. I work in Asia where there are lots of talented women engineers. Each time I read one of those sentences, I do a double take!
I'm pretty sure most people over ~30 in the US were taught that was the correct form. Common usage has changed only very recently. At any rate, as long as using the feminine is fine, so's using the masculine. Some writers even use both, switching between them. Me, I much prefer the singular-they, because I don't think keeping masculine the standard is tenable or desirable, and I find writing that uses the feminine harder to read (because there's a vast body of existing writing that defaults to masculine and it's by far the bulk of all material I've read in my life, so if I see a feminine pronoun it throws me off for a second as my brain reflexively starts to try to figure out who exactly we're talking about—this is getting better as the practice is wider-spread, but c'mon, let's just use the singular-they) and because it doesn't tend to generate discussion about pronoun choice.
The issue with take homes is that they are at the beginning of the process where you might have hundreds of candidates. I won't invest several hours in that. Whereas on-sites are the last stage in the process, so it's better than 50-50 that I'll get an offer out of it. So in that case I'm happy to take the time.
Ace Greenberg from Bear Stearns (former US investment bank) used to say the trouble with hiring friends and family: "You get 100% of the dummies." Sure, you get a few good ones, but you also get the lousy ones.
In the context of the parent comment which described how leetcode-style interviews are discriminatory, you have just nicely described nicely why the leetcode-style interviews are because companies are afraid of APPEARING discriminatory in hiring, and provided other methods of plausibly-deniable discrimination.
If they want to be really undiscriminatory, the interviewer and interviewee need to not be able to see each other, and even real names (which can indicate gender and ethnicity) must be hidden.
When orchestras started doing auditions with candidates anonymous and behind screens, they ended up hiring a LOT more women and minorities - even when the selection committees had previously thought they were trying to be nondiscriminatory.
Deeply embedded biases are really hard to root out, even for ourselves.
Wait isn't it only illegal to consider Race/religion/sexual orientation? Have these other criteria become officially illegal or just a possible lawsuit? I can't see how any company looking to build a good team wouldn't consider culture fit. One bad hire could tank a team so I'd imagine they are very cautious?
It's illegal to use proxy metrics that impact a protected class more than others. This is to prevent companies from discriminating by hiding behind tests whose main purpose isn't to match on skills needed for the job but to filter out members of protected classes. An employer can prohibit the wearing of a turban if it is a legitimate safety hazard. They can't prohibit it if the purpose is to ensure no Sikhs get hired. What's the purpose of leetcode? Does it map directly to a job's primary task or is it a way of filtering out certain protected classes such as those of an older age?
Age Discrimination: <<The Age Discrimination in Employment Act (ADEA) forbids age discrimination against people who are age 40 or older. It does not protect workers under the age of 40, although some states have laws that protect younger workers from age discrimination.>>
What's legal varies by location, but even if it's not illegal to discriminate against the other criteria in the GP's list, a company may consider those factors and try to avoid that discrimination anyway. After all, you want the best candidate, regardless of what their home life is like.
Like anytime you're evaluating someone's compentency, find out what they view as a good example of their work and judge on that. Don't stick to any standardized hiring process, instead get to a burden of proof.
Yes it’s a substitution for practices that are illegal for the same reason we use the substitute. No need to be defensive about achieving intended results.
Slotted (flat) screw heads at least enable the user to use a 'non-tool' to remove the screw in the case they do not have the necessary tool on hand.
Take for example my front license plate, the flat head screws enabled a random while I was at work to remove the plate from the car, without any specialized screwdriver.
So in some instances flat heads may prove to be useful. Philips however has often led to the screws I need out getting stripped. Torx all the way.
