I got asked LeetCode questions for a dev-ops systems engineering job today

At one of my previous gigs, we managed to hire someone who couldn't write more than basic control structures. I have absolutely no clue how it happened as I wasn't involved with the interviewing process at the time. The people who were involved blamed the recruiting firm for not doing adequate technical screening, but that doesn't explain how this person passed the on-site interview they performed... At any rate, we let them go after 3 days.

I have no way to prove to veracity of my story, so feel free to add it to the "urban myth" pile. But it was extremely bizarre to experience.

Agreed. The best way to interview is to simply have a joint discussion about their past projects (from resume). There is no value in whiteboard puzzles. It is easy to gauge who is competent and who didn't do or didn't understand the work they claim on the resume.

In over 25 years of interviewing candidates, this approach has never failed me. I've never asked for whiteboard coding. Whiteboarding architectural concepts, sure.

The only caveat is the interviewer needs to have substantial experience in the same field to spot the wheat from the chaff in a casual conversation. If the interviewer is very junior, I can see how this might not work. Solution: don't have your most junior people run the interviews.

I've interviewed hundreds of candidates over more than 20 years. I've lost count of the number of times that a candidate has talked-the-talk so well that I'm thinking "This guy/girl is amazing. They're a shoe-in. Better do a little coding just to make sure"... and then they literally couldn't even get close to solving something like fizz-buzz.

I agree asking highly specialized, deep CS-algorithm type problems is usually a terrible indicator. I typically start with a very rudimentary question that could go off in various directions and to various depths as time/progress allows. I let candidates choose the programming language, and to use either whiteboard, pen & paper, or laptop with choice of IDE.

I've seen candidates who claim to have years of "senior" experience struggle to get the basic syntax of their "language of choice" right - to the point where a competent hobbyist who spent a weekend doing a couple tutorials would wipe the floor with them.

There's just something about coding that makes it impossible to truly evaluate a candidate (for a developer role) unless you see them actually code.

Acing an algorithm type interview has little to do with answering questions like can you translate business problems into working systems? Do you know whether you should be writing this code at all or use a third party solution? Do you know how not to gold plate a solution and ship software? Can you solve a performance issue with a process that may not involve code but involve another part of the stack?

In my experience, I've seen close to 50% of the people that can talk their way through an interview and put up a good game wind up being absolutely useless at actually writing code once you hire them and set them to work. There is a huge disconnect between being able to understand the big-picture hand-wavey ideas of how software fits together and being able to turn that into nuts-and-bolts working code.

Something as simple as having somebody write a little web application that takes a request, calls an external service, parses the response, and returns a transformed response, filters out the bozos wonderfully.

An alternative hypothesis I have is that some organizations inadvertently skew their pool somehow, and they really do get a lot of these, but other places don't.

An analogy that every male acctually can relate to is peeing under pressure from the que behind you.

> "porn stars"

That's.... a much more accurate term than the "rock star" that gets tossed around.

By the same logic you might say that we shouldn't interview at all because it selects for people that are good at being interviewed. Obviously this is true but I think it would be pretty crazy to not interview people.

Frankly I think most people suck at being interviewed initially, but you can definitely improve with practice. The same as public speaking and interviewing candidates.

This is something I've found as well.

We give an invite for a phone screen. It's just a chat so both candidate and interviewer can make sure that the job on offer and experience of the candidate match up. It's also a nice time for candidates to get a decent idea of what our company does so they can bow out if it's not really what they're looking for, which is good for everyone.

Then we send a tech test (take home). It's a simple challenge, with a lot of freedom. We give a guide time of ~90 minutes, but also let the candidates know that they can do more or less if they want. We ask the candidates to submit a written response as well, so they can explain if they're happy/unhappy with the test and their submission. Didn't have time to refactor as you wanted? Didn't write as many tests as you would usually do? That's fine, just let us know generally what you'd have done so we can take it into account when looking at it.

Then it's onto the face-to-face interviews etc.

The tech test segment is really enlightening. A lot of the time we can figure out a lot about the candidates ability to create software systems and communication skills just from the test. Most of the time, we spend a non-inconsequential amount of time looking at the test submissions. If a candidate was good enough to write it, we should take the time to really see what they did and review it. Sometimes we get really poor tests back, even from candidates we were enthusiastic about. Other times we get pleasantly surprised, with candidates who phone screened poorly smashing the test and giving a wonderful submission. I think it's immensely important to see what a candidate does with actually writing code. I also think it's important to make sure we see that prior to inviting them in, as they need to take time off of work, get to our offices and prepare for it. And even when we really want to progress with a candidate, the tech test gives us something to talk about to get to know the candidate better, and hopefully have a conversation that allows them to ask us questions as well.

We don’t know what expectations were set in the interview for the solution space, but anyone with (Unix) ops experience should have the thought “grep can do that” pop into their head. And people with a formal CS education should be able to come up with the dynamic programming solution.

So, whichever side of dev-ops you lean to, there’s a reasonable answer that should be within your field of expertise. And given Palantir’s line of business (the company involved), I wouldn’t be surprised if dissecting a byte string with limited information about it’s structure comes up from time to time in their actual work.

It's a great point we hear often, so I incorporated it into our last round of hiring. Some still couldn't do it with an IDE, their language of choice and access to Google.

(sorting an array, with any algorithm you want)

You jest, but the for loop example is now in our pre-screening questions!

I think both the ability to write, and (read+understand+effectively explain and give an opinion on existing code) are important, and the latter is severely under-appreciated in interviews

Many years ago, I was given a piece of code and asked to explain what the code did. I got the job because I starting asking questions about what the code was expected to do and what sort of evnironment the code was running in. Even though it was only three or four lines, without first understanding the contextual questions, the code itself could have been doing a variety of tasks. Since I did become the maintainer of the code base, it did turn out that there were quite a few non-obvious effects occuring in that piece of code.

There are plenty of programmers who would have jumped right in and explained what the code was doing (surface appearance) and missed the simple fact that there was nowhere enough information present to actually know what that code was actually doing.

So even with you two questions, which are a start, getting them to indicate they understand the context/environmental problems can be a more challenging process.

The crux of the problem is that we've interviewed dozens of applicants and none of them have been able to pass the sniff test. We are setting the bar pretty low, but the average skill level of the people we've had access to is shocking. There just isn't a supply of good developers for companies that aren't FAANGs or unicorns. And before anyone says we aren't paying enough, or we are being unfair, the reason these interviewees are not passing is because they can't answer basic questions about the languages and frameworks they've been using for years. Things that you would know if you spent five minutes reading the first few pages of the official documentation. It's baffling. If I could even get a talented junior that I thought was capable of leveling up to a senior position in a few years I would be ecstatic.

Edit: for example, when interviewing for a react/redux position, one of the first questions I ask is "if you need to make a network request in an app using redux, where do you put it?" at least 3/4 interviewees answer "in the reducer". From page 3 of the "Basic Tutorial" in the redux documentation:

  Things you should never do inside a reducer:

  Mutate its arguments;
  Perform side effects like API calls and routing transitions;
  Call non-pure functions, e.g. Date.now() or Math.random().

That's not what they bargained for when they hired a senior person. Basic coding questions would have filtered him.

We've had several sit-downs. The problem with a low-skilled senior developer is you'll never convince them that they are writing junior-level code. It would shatter their world view.

As someone from the Midwest I can assure you that we don't have a larger percentage of crappy coders than the coasts and tech hubs do. We spend just as much time fixing the code from your terrible developers as you do from ours.

It's really a lack of training provided by companies and that most 4 year degrees don't actually prepare people to write good maintainable code so new developers have to luck into finding a mentor that can teach them these things.

A difficulty with this kind of question is that the how-to-beat-the-coding-interview books and sites, which many students and professionals read, already prep them for how to answer.

People get step-by-step strategy for this kind of question, what the interviewer is looking for, and what notes to hit. And sometimes prep them for the exact question, so that they can have a prefab answer ready.

Then we might be selecting for more like what used to be MBA students, or at least people who know how to play along, and say the right corporate going-through-the-motions things.

Some organizations will want to select for test-prep specifically, as a good predictor for the kind of employee they want, but I like to think there's other organizations that decidedly don't want that.

I don’t think this is a great approach. You’re selecting for good talkers. There are many great engineers and coworkers who don’t do well on these types of verbal psychological games.

Folks are given all sorts of interview advice about leading to claim things like “my greatest weakness is that I work too hard”.

One way to test for humility is have them do a programming challenge that isn't too difficult (it's not about whether they remember the algorithm for merge sorts), but has a few common pitfalls and arbitrary choices, and see how they react when you ask questions about their choices or make suggestions to them. Can they explain a choice? Can they follow a suggestion (or correctly and politely argue that it's unnecessary)?

`if i<3: continue; if i==3: break;` is what a for loop does. You don't have to manually control it.

This seems good on the surface, but I can't imagine top tier talent at a FANG or equivalent ever leaving their job to do this.

I feel this filter will only leave behind those who are currently contractors that are interested in maybe going full time, and the unemployed/employed who are desperate enough to go along with such a scheme. Foregoing the typical crappy interview process is one thing, but working, even for money, without any certainty as the end outcome would certainly turn me off.

To be honest, this setup seems like something that would be hatched by a scummy company to constantly string you along with a carrot that will never come. I am not implying that you are that type, but there are enough horror stories out there that I would avoid ever getting myself put into that position.

Just to provide an alternate perspective here, this seems to tilt the incentives towards people that are not working already. I wonder how many folks have time to take a week or more off from their current job to participate in this exercise. I understand this is paid but its still a huge risk that candidates would be taking.

This is subtle age discrimination. At some age, lets say 28, there’s a cliff drop-off of people who’d be willing or able to do contract work.

“Man”-up, and fire fte early if needed.

Step 5 sounds awesome and I totally understand the desire to do it, but it will screen out a lot of top-tier candidates. A really good candidate is probably already employed. They probably don’t want to quit without another job lined up and they probably don’t want to work double hours for a week. If they’re job hunting then they likely have other offers you have to compete with, and are they going to chose the “maybe we’ll hire you if we like your work” over “sign here and you start in two weeks”?

Desperate people won’t be put off by this. If they’re desperate then they’ll have time to do your contract and the money will be attractive. They can keep job hunting in the meantime so there’s no downside.

That’s not to say this can’t produce someone good. I got my first full time programming job like this and I like to think I’m not completely useless.

And alas, I don’t have any answers for how to do it better....

You will never get most good talent to go contract to hire. This market is far to competitive to have to put up with that kind of risk.

> 6) If satisfied, repeat step 5 until ready to hire; else repeat step 4.

How do you mean "ready to hire"? You're interviewing and giving audition gigs before there's an actual job opening?

>5) Pay them to develop a feature on contract

It will be very rare to find a good candidate willing to quit a well-paying job to go on contract for you.

Indeed, came to say that is a much better alternative.

When you first encounter it sure. After you've been writing code for more than a few months I would expect you to have mastered it. If you don't understand the fundamental behavior of a for loop after ten years of professional experience, something is very wrong.

How are tests supposed to help when someone writes atrocious code that works? The posted pseudocode probably gets the job done.

Can you show me a linter or a unit test that would reject that code?

Sorry, I think there's a couple of confusing things there. I mentioned a try block that always throws, but that was a different bit of code. In the example I posted of the for-loop the try/catch is unrelated to the previous, so we can assume it doesn't throw every time. The only WTF is why are we counting `i` and using `continue` and `break` to control a for loop.

The part in the except: does exactly what the for loop already does, it's completely superfluous. It also has nothing to do with handling the thrown exception.

Yeah it's pretty weird. Was trying to think of something that would need this exact behavior, assuming it's legit...maybe parsing some piece of text where you expect a fourth part only if the third was parsed successfully and you don't care about the outcome of the previous two ¯\_(ツ)_/¯

Scenarios like this scare the bejubus outta me, it's like a business logic landmine waiting for a refactor tractor to drive over

That's all true, but it's not really relevant to what I was saying. We don't do whiteboard interviews; that was some code I found during a code review. My original comment was in response to the assertion "my resume speaks for itself", and was simply meant to serve as a counter example. A lot of people seem to have interpreted it as "interviews should involve complex whiteboard programming" and/or "you should always use redux for your back office CRUD apps".

The original story here wasn't about code written in an interview, but code written on the job by someone who wouldn't have been hired if they'd had to write code in the interview.

But, 45 minutes for mergesort? I mean, it's not fizzbuzz, but this took me seven minutes, and it passed the test on the first run (well, not counting the test runs that verified the test was invoking an empty function and correctly reporting that None wasn't the correctly sorted list). Does it have some kind of subtle bug I'm missing?

    def mergesort(items):
        return (items if len(items) < 2 else
                list(merge(mergesort(items[:len(items)//2]),
                           mergesort(items[len(items)//2:]))))

    def merge(sa, sb):
        ia = ib = 0
        while ia < len(sa) or ib < len(sb):
            if ib == len(sb) or ia < len(sa) and sa[ia] <= sb[ib]:
                yield sa[ia]
                ia += 1
            else:
                yield sb[ib]
                ib += 1

    def ok(a, b):
        assert a == b, (a, b)

    ok(mergesort([3, 5, 3, 1, 10, 11, 12, 0, 1]),
                 [0, 1, 1, 3, 3, 5, 10, 11, 12])

If I were doing it on a whiteboard I'd probably want to use something like http://canonical.org/~kragen/sw/dev3/paperalgo rather than Python, but I can't imagine it would take 45 minutes. Do you mean in assembly language or something? In minimal space (none of the logarithmic number of copies required by this version)?

I agree that these are not very basic coding skills, but they are kind of basic coding skills, I think? Like, it's covered in the first part of an undergraduate CS curriculum, isn't it?

Nothing. Probably the original developer was trying to do the same thing. There is always a context to what some one is doing.

Well the continue isn't doing any work for you since the else clause prevents the raise from being called.

The catch block merely does exactly what the loop would do at the end end anyway; it's no different than:

  catch:
     pass

(That is, if the pseudocode isn't making a Rubyish distinction between exception handling and control flow [rescue vs. catch] it's just an extremely verbose way of silently swallowing exceptions, and if it is making a Rubyish distinction it's an extremely verbose way of doing nothing and the whole try/catch construct is unnecessary.)

> Industrial psychology has consistently found that IQ is a better predictor of job performance than experience.

If hiring managers are aware of this, then it might be a good idea to apply to Mensa. If you're able to get in, maybe putting "Mensa" down on your resume isn't that bad of a thing. (I've always felt it would make one come off as a douche, but maybe that's not so true.)

You cited a publication called "Intelligence Is the Best Predictor of Job Performance", but funnily enough there's also one called "Intelligence Is Not the Best Predictor of Job Performance", which one year later claims that the former one is flawed.

There's also this: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4557354/, which says "Supporters of IQ testing have been quick to point to correlations between IQ and job performance as evidence of test validity. A closer look at the data and results, however, suggests a rather murkier picture."

> The skill acquired by a low IQ in five years is often surpassed by a high IQ person with a few months of experience.

This looks wrong to me, most things take more than a few months to learn.

I'm probably a stronger believer in this than most, which is why it was easy for me to follow the evidence for our narrow case where it led. But you only need a weaker form of this to explain the experience I had recruiting at that company.

All it takes to be a good engineer at the lower levels is a sufficiently high IQ/creative problem-solving ability. Put someone like that under the mentorship of someone who's learned good engineering habits and (barring severe behavioral problems), you'll have a pretty great junior engineer in a few months.

Otoh,Experience and other habits and knowledge do become more relevant at higher levels, only because the responsibilities of the job shift and grow, such that you can do a lot more damage in the "learn by exploration" period of becoming good at something by just being really intelligent and learning on the job.

I currently work with a bunch of physics and math and CS PhDs, people who are likely as intelligent as I am or more, but I'm a lot more equipped for our job because I'm applying that intelligence in the context of understanding how engineering systems work, at both a technical and personal level. There are tons of engineering habits that are second nature to me that never occur to them; if they shadowed me closely and I dedicated time to explaining the reason I do every little thing I do, then they'd pick up those habits in the same way junior engineers do.

That is to say, as one would expect, the relative supremacy of IQ over other skills like conscientiousness (or yes, experience) diminishes at the higher levels. Everyone I work with would be considered "really smart" by any reasonable measure, but it's not purely the smartest who are the most effective anymore, the way it was when we were entry level.

> It would be absurd to ask a Aeronautical Engineer to do something like derive the Navier-Stokes Equation on a whiteboard

A thorough interview in physical engineering disciplines will often expect you to demonstrate/validate something about your technical skill in-person, unless you are being interviewed because people already have validated knowledge about your capabilities (e.g., hiring a known individual from a competitor that is well-respected among peers).

To your point, a physical engineering interview might be more about "spot checks" than "assume the person is lying so ask them to complete a bevy of undergraduate final exam questions". In the software world, maybe that would be akin to starting with FizzBuzz and finding other ways to get solid proof the person can implement, not just talk. To me, if you have open source work that can be read by an interviewer, I would find it disrespectful for that interviewer to act as though the work doesn't exist and they should verify from scratch you can actually write working code.

It's comparatively a lot harder to just have a conversation with a software person and be certain they have the technical competence they claim vs. other technical realms. I tend to think it is the nature of the subject, as well as the salaries drawing in more charlatans than in physical engineering realms.

> In fact one might say that the Aeronautics industry is in far better shape than the Software industry, a failure in one of their systems results in people dying but I can go to any major tech companies websites and experience a bug on any given day.

This probably has more to do with Aeronautics actually practicing engineering as compared to today's software development practices. Also software development as a field is far less mature than traditional engineering disciplines. That's not meant to be pejorative - it's just where humanity is.

> EE, Civil, Mechanical, Aeronautical etc. and in not a single one of them do they do this monkey dance.

EEs definitely go through basic, advanced, and domain-specific circuit design questions in their interviews. And compared to LEETCODE they are much more difficult to prepare for too.

There is a reason why SWE is a fallback option for many other engineering disciplines -- resources like leetcode and low barrier of entry to learning make it much more accessible.

Sure, if they actually have any. You’d need a way to verify the code was actually written by them. You’d also need to be careful you’re not overly biasing towards “people who [have time to / are allowed to] publish on GitHub”. Plenty of good developers don’t/can’t use GitHub.

This lays out the actual problem with programming "education" these days. Most people are not doing "computer science", they're doing a subject called "software engineering" when there's no actual engineering discipline involved. Programmers have "title inflation".

We would be much better off if the craft of programming was treated like other trades, requiring training and formal apprenticeships, with the necessary mentoring and signoff.

Programming is to CS as plumbing is to fluid dynamics. Knowing how to write a bubble sort is an irrelevant skill.

Knowing how to use the standard library in the environment is much more relevant.

It's not as important as you would expect for a couple of reasons:

1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets.

2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job.

So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.

I wasn't there, so I can't know how the interview went, but are you sure the motivation was "just to prove how smart he was" ?

If I'm already 100% sure I'll recommend a hire, it's not rare for me to go off-script and dig into random stuff in the candidate's experience, first of all because I find it interesting or fun to talk about, and second because having deep knowledge about anything is positive signal, regardless of whether it's useful for the job.

I have definitely been in this scenario and asked people who had relevant background to work out low-level performance details of their code. I hope they didn't think I was "drilling" them.

Fair enough; phrase it "What would my day-to-day work look like?" "What percentage of time coding/designing/testing/meetings?" The current interview process could be better but right now these coding questions are just a proxy for ability/aptitude.

I just want you to have the best shot at this job. Be as critical about the process as you want after you get it.

There's literally no way to not ask that snarkily. Don't do it.

Also, it reeks of "justice driven opinion having" which is scary beyond reason for an employer, e.g. "They didn't ask for this feature the right way so I'm not going to deliver it/deliver it in a way that makes them unhappy."

I doubt it. Leetcode questions tend to be deliberately technically challenging, and focused on algorithms.

I don't ask technically challenging questions. I'm more focused on comprehension in a technical discussion, and a basic comprehension of concepts that are critical for the product that I work on.

Why would I search for software engineering interviews if I'm applying to be an IT systems engineer?

Cargo-culting is literally not knowing what you're doing.

If you’re cargo culting do you really know what you’re doing though? I’d think the two situations are mutually exclusive. Or were cargo cults actually effective at getting supplies dropped from the sky?

It's probably per-team, someone on here mentioned that's how Google works at least.

Someone I know did an AWS interview round during business school, and they do this thing called "bar raising" (IIRC) that involves one of the interviewers literally doing something unpleasant to see how you react (e.g. picking their teeth in the camera, cutting you off when you speak). Very odd.

I think you are talking about something different. The parent poster was referring to a Devops position. Were you looking at a software engineer position?

Generally people don't just want to know that they got a qualified candidate, they want to know that they got the best candidate available. And so having a more sensitive differentiator than 'passes basic qualifications' is important to most people.

If you are filling one position, it doesn’t matter if 20 people technically qualify, you hire one.

Imagine a single resturant forced to hire 200 chefs because each of them managed to live up to the minimum qualifying criteria for the position...

Because you want the job.

If you don't put in the work, someone else will.

These are high paying positions. You can't just expect to lazily stroll in.

Because you are applying for a job where the interview requires you to answer that sort of questions. Maybe you don't want that job so much, and that's okay. Personally, I would refuse to do take-home projects, and that's also okay.

Why did you do it 20 years ago?

I worked at a place with a demanding interview process for about 3 years and the people I worked with were excellent. Nobody is making you do anything you don't want to do. So drop the attitude and the childish entitlement.

I don't understand why you feel it's necessary to share your personal justifications (rationalizations), other than you're trying to normalize your own mediocrity. Which, by definition, already is normal.

Who cares. It might as well be experimental theatre for all I care. If I want the job, I'll put in the effort. It's that simple.

California is an at-will work state, which means that either the employee or the company may terminate employment at any time, with or without cause or prior notice.

The whole point is to make your team heterogeneous*, so in terms of skills you need to staff for all your needs.

"We'll use python on GCP with PostgreSQL as a backing database"

Well, then you need an expert in GCP, Python and postgresql. This can be as many people as it takes to have those skills covered.

As for responsibility, well, that goes for where your skill is. If you're the resident postgresql expert then you're expected to be responsible for supporting people with it.

It's likely you'll need to worry about patching the OS and stuff like that, but I don't think you need a dedicated person to be responsible. The point of DevOps is mostly to bring down the silo'ing, not to eliminate a particular role.

But it certainly appears employers are salivating over the idea of hiring less specialists, or simply rebranding sysadmin to "devops".

Based on the role you expect them to do in the team?

Hire the software engineers with an appropriate interview process covering development practices and coding.

Hire the system administrators with similarly appropriate interviews.

Hire the database administrator with their own appropriate interview.

Is this that hard?

How do you know whether the ones that were filtered out were egotistical?

As another commenter mentioned, you're probably doing more damage than you realize. A lot of more experienced people are going to recognize this as toxic behavior and word will get out that your company isn't healthy. You may not even notice, but this kind of thing will keep the best people out of your pipeline if you continue to do it.

> Since I've started using it (admittedly my sample size is small) I've found some very effective programmers,

This is not the only way to find very effective programmers. You should level up your own ability to discovery this in someone in a non antagonistic and more straightforward manner.

I've done well over 200+ interviews myself, and been on hiring committees where I have had chances to review other interviews. This kind of behavior usually trashes the following ones and aets the candidate up for failure.

That is the goal of an interview! You ended with more information that you had before.

I was told something similar by my high school history teacher Mr. Kolhaise, but I think it was phrased in a more helpful manner and it's always stuck with me.

He said "Don't just tell me what you don't know, tell me what you do know" or in other words, don't just say "I don't know" but say something like "I don't know, but based on what I do know this is what I think the answer would be and this is how I would figure it out".

It really helps that everyone forgets what people say before the "but" and you can help get across the idea that while you may not know everything you know how to figure things out.

Saying "I don't know" like this in an interview scenario is nearly impossible for most candidates and only serves to humiliate rather than prove their abilities.

If you want to see them ask questions, give a half explanation of the problem at hand instead and guide them to ask more detailed technical questions.

Be an ally, not an adversary, and you will find talent better than if you push.

Maybe you could give the critical replies to your comment some consideration. There seem to be many interviewers who abuse their temporary power over candidates by freestyling a psychological excercise, and brag about it in threads like this.

In a way forcing the other party to give up with an "I don't know" is humiliating, and graciously allowing this answer doesn't make things better. You'd put yourself above the other person.

Imagine you'd interview someone you truly respect, a luminary of Open Source walks in. How would you go about the interview then?

I think a great interviewer can make the interview an enlightening and wholesome experience for both parties - while easily identifying the exact qualifications and the fit of the candidate.

In the process you are pushing the candidate to the breaking point and eliminating any confidence they may have had in their abilities. They will end up demoralized and most likely fail the following interviews if they're the nervous sort. If they're smart, they'll bid you goodbye and you end up with a black eye reputation.

Except that some interviewers say that when they hear "I don't know" it's a sign that the interviewee gives up easily and extrapolates that they will give up easily when they encounter problems while working. The point is that as an interviewee you're supposed to "know" an unfair amount of knowledge and have incredible spontaneous algorithmic skills to boot (the interviewer picks 1 question and has the answer while the interviewee anticipates and is expected to competently answer the set of all possible questions). What ends up happening is everyone crams for interviews by rote memorizing common system design and coding questions. From the interviewee's side it's a "damned if you do, damned if you don't" scenario when OP asks his trick question. This is similar to hazing where initiates are unsure of the correct way to conduct themselves because they are being judged by some vague, perhaps intentionally withheld ideal, standard, or cultural archetype. I'd imagine disenfranchised groups would disproportionately 'fail' this question, as they are already insecure of their belonging in tech culture

The deal is when you’re interviewing me we’re _not_ co-workers. You hold all of the cards and decide my fate.

A big part of interviewing candidates well is breaking down that dynamic. There are many ways of doing it - I get up on the whiteboard first and write out my problem, and stay there until they’ve explained themselves and I need to get back to my notes so I don’t forget stuff. I phrase questions like “I need help implementing this function...” or “how are we going to solve this edge case”.

I don’t think either side of a tech interview is easy. The problem is only one side is evaluated.

its a trick question, period. The question is formulated with the expectation that it cant be answered, even if there is a small chance to answer it right.

its not a bad signal. to be honest its the smartest thing to do (like guessing on the GRE), especially since most people ask questions they expect the right answer too.

the only bad signal I see is in you. I would wager to say, in most situations in life, don't play tricks, just ask the question you really want answered.

Sure I have - and like I said - it's easy to read this behavior from simply having a normal (but let's just say slightly inquisitive) conversation with someone. In fact even in recent memory I can think of multiple occasions where this behavior has emerged, simply when trying to get to the bottom of routine technical matter.

Then hire for software engineering. Don't lie to candidates that it's a systems admin or devops role.

It's pathetic employers keep demanding more skill and free work for the same pay.

a lot of SW out there are just plumbing code. Rarely you see dynamic programming/recursion algo. Most use standard library as the implementation is solid and kinks have been ironed out.

And the interview victims wasting there time. And the employees that don't get new coworkers becouse riddles.

I think it's instructive to consider who the employer is too. Leetcode works well for Google. They pay top notch compensation and have a long line of people who want to work there. They can put horrible hoops up and enough people would still want to jump through them.

Most companies have cargo-culted the programming interview, even when they don't have the same amount of demand from candidates.

I feel this perspective gets lost a bit. Big companies don't roll through 1000 applications with 50 open spots and try to hire the best 50 candidates. They want to find maybe people in the top quartile of that, while spending the minimal amount of time on costs to find the adequate fits, and the cost of a false positive is way higher than the cost of a false negative.

Is the process great? Absolutely not, and I'm sure that these places miss out on qualified candidates because of the process and hire some people who gamed the process. Things like degrees and LeetCode tests and other screening methods are just ways to reduce cost and risk to get that "good enough" threshold.

This is (kind of) fine if you’re a well known company with thousands of applicants, but my experience so far has been that finding qualified candidates in the first place has always been the hard bit. I can’t imagine throwing arbitrary hurdles in the way of getting good people into interviews and talking to them!

I get where you are coming from and agree with the sentiment, but disagree on the specifics.

> Every company use different technology and different way to do things

To a small extent, but mostly untrue. If you are an expert UI programmer, you should be able to move between disparate UI technologies relatively easily.

> With a standardize test

People aren't upset with the standardized test part. They are upset it (frequently) tests things that are not relevant. Hard things at that. There are an extensive number of practical, language / framework agnostic questions you can ask about UI or back-end programming that will easily tease out quality candidates. Instead they ask you merge sort. Hence people complain.

Amen! Since I've been involved in hiring and recruitment, I stopped seeing interviews as a validation of invalidation of my worth and rather more as a discussion where we are both trying to see if what we have to offer matches what the other needs. Based on this, most of the interviews are not interviews anymore, but open discussions.

You're not. You have no guarantees. Is staying in a volatile role where you're not sure what your job will be next week better? You are in control of your own destiny. Don't let someone else be.

No. They're a professional and standards organization. They are very much supported by large industry.

The teamsters are a trade union.