At the time of this writing, I am working with someone who has 10+ years of experience, including former positions as a lead developer. I was involved in the interview process and made the recommendation to hire, as they were able to answer a lot of domain-specific questions very well and had a good knowledge of the ecosystem. Fast-forward three months, and I am spending hours per day sending changes back on code reviews for features that would have taken me 30 minutes to implement. Every review has at least one conditional that always evaluates to true. Yesterday I found a try/catch block that always throws inside of the try block. The crown jewel was the following for-loop (psuedocode):

    for i=0; i<=3; i++:
      try:
        doSomething();
      catch:
        if i<3:
          continue;
        else if i==3:
          break;

That said, this does seem like another reiteration of the "senior engineer couldn't write fizz buzz" story, though this particular example is amusing.

I can write fizz buzz. Hell, I've interviewed enough that I can print all permutations of a string (or all permutations of a set and/or subsets of that set). I used to be able to implement merge sort in 45 minutes at the whiteboard, but I can't now, and I never want to be able to do this at 45 minutes at the whiteboard again. I could certainly detect a cycle in a linked list, and I could do DFS and BFS on a binary tree. I might be able to reason through how to find the last common ancestor of two nodes, or find all matching subtrees in a binary tree if I could hack around for a while, but at the whiteboard, in 45 min? Nah. So, no-hire.

It's time to stop pretending these tests are about weeding out people who lack very basic coding skills. Tech interviews are one of the reasons I'm not enthusiastic about recommending a career as a software developer.

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])

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?

Unfortunately... yes to both your questions. Yes, it is certainly covered in basic undergraduate "Data Structures and Algorithms."

And yes, I would have trouble writing what you just wrote in 45 minutes at a whiteboard, unless I studied up in advance. I know the algorithm in the back of my mind, and I'd be able to hack away at it. I don't mean in assembly, or in minimal space, I just mean a reasonably efficient implementation of quick sort in a high level language like python ruby or java. Again, I could do this with a bit of study, though I'm no longer inclined to do that study. I can't think of a reason, other than interview exams, for me to front load "into to data structures" into short term memory for a midterm exam one. more. time.

Maybe it does say something about my skill and mind set as a developer, that it would take much longer for me to do this than it would for you. I'm ok with that, as long as we're clear on what "basic" coding means.

I maintain that it is an immensely different thing to say you're weeding out people who don't have basic coding skills when the test is "fizzbuzz" vs "implement merge sort".

I certainly agree that mergesort is a lot harder than fizzbuzz, more than an order of magnitude. Fizzbuzz is well under a minute.

I'm pleased that you enjoyed my comment and code! I was reluctant to make it because I feared you might interpret it as an attack.

1) Does this code accomplish the goal? 2) How would you improve this code to make it more readable? More efficient?

Personally, I think I'd rather work with people that know how to review code and provide feedback/commentary, since that usually means they can write good code themselves. It should lead to a better team dynamic.

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.

While I agree a coding exercise is valuable - this is the actual problem. The way I test for that humility is by asking "tell me about a time you personally did a poor job." I then follow up by asking for a time they identified a failure of a colleague. I look to see if they're empathetical, open to being wrong, and declaring they're always trying to improve.

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.

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

This is a completely different (and actually relevant) thing compared to leetcode/hackerrank riddles.

The standards for what a company wants from their programmers can vary wildly depending on the location. This speaks to a broader problem of not having consistency across the industry and various locales.

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.

When I said 'the midwest' in my original post I didn't mean places like Chicago, St.Louis, or Indianapolis that pay industry standards adjusted for cost-of-living. It isn't out of the realm of possibility though for someone to get 10+ years experience in a place like Lexington and have them still not know basic things EVEN after having been trained.

Again this is just my anecdotal experience, I don't mean to insult anyone from these places. This is about brain-drain and salaries, not about anything intrinsic about a place or their people.

We all know small businesses don't care about code quality. Ditto that best practices take a long time to trickle down from ivory towers to business, academia, to bootcamps.

Companies pushing the status quo tend to cluster. Poster probably shouldn't have picked on the midwest, it could be anywhere outside "cutting-edge" software centers.

The "Joel Test" was a thing, for a reason.

This is a very hard thing to really make a part of your thinking process, in particular because nobody wants to come to terms with the fact that they might be in the latter group.

Believe that's the root problem, right there. Gun-to-head coding problems aren't the solution.

I've had developers balk at other developer's code for writing a series of like 100 if-else's until I show them, they do it themselves only that they scatter it. You could say this thing about nearly every OO programmer out there.

Everybody writes code that mutates state in a way that produces the kind of code you mentioned as an example.

It's only that some developers think they can never write bad code, while thinking other's almost always do.

This is one reason why some shops hire only OCaml, or Haskell or Clojure devs because bad devs tend to use those languages less. So you buy into a great community by default.

Edit: I apologize - I wrote that comment before reading the rest of the discussion, after which I had more context.

the try always throws an exception, and if i<3 resumes the code. But on the last iteration through it breaks so will not execute code after the exception is thrown. The first 3 times it will execute code after the exception is thrown. Does continue return to the beginning of the for loop or resume execution where the exception was thrown?

If continue returns to the beginning of the for loop then I could see that the code is pointless. But if continue resumes execution inside of dosomething the line after the exception was thrown, then it could actually be useful.

Is your issue that the code does actually work, but conceptually it is horrendous to implement the branching in that way, or is it that the code doesnt work at all, or is that it actually does nothing?

When I see things like this I integrate them into our interview process.

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

Bless you sir, you are keeping the code legible and clean for everyone else on your team and doing a great service for your company — even if they don’t appreciate it.

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().

...at the salary you are offering.

I see many people hiring adjusting for cost of living but not adjusting for the place being less desirable to live. Also, given the reputation of FAANG and similar, working for them is viewed as something of a future investment. That is a benefit your company likely cannot offer. So even if everything else was on par with a FAANG in terms of pay, benefits, and working conditions, ideally you would have to pay a slight bit more to make up for the difference. Granted, the market is never that rationally acting in any individual case.

Having seen numerous IT managers having trouble hiring, the most common shared issue is too little pay.

If you're only sourcing the same 75% of active job seekers who are bombing most of their other interviews [thus leaving them available to come in and bomb yours as well], start advertising your positions elsewhere or trying to recruit passive job seekers/encourage employees to scour their own networks.

If you don't change something, you're likely going to keep getting more of the same.

Which is what was said three posts up.

Edit: I don't think you are understanding what I'm saying. We are offering higher than average pay for a job with average requirements, and we haven't been able to find average candidates. And I'm well aware of average, upper, and lower bounds to salaries here.

“We can’t afford that!” “But you can waste money on two crappy devs?!”

(If you only have budget for one, the cash flow doesn’t work, of course.)

Yes, probably. Why do you need a supply of new front end developers? Is your workplace exceedingly lethal?

Have you considered that paying $2XX/year is a signal? It attracts a certain type of candidate and you can't extrapolate the talent level of the entire market just based on your experience with those that would try to land a $2XX/year job. Where I live, trading firms can pay that much and more, with potential bonuses that would make your eyes pop out of your head. Yet many extremely talented people I know would never submit a resume: "No thanks I like having a life." Many people I know that used to work in that environment think of it as an insurance policy: "at least I know that if I ever need money I can go back."

> We are offering higher than average pay for a job with average requirements

A lot of people will pass you by and assume that something is really wrong at your company to need to offer so much money for an average job.

At least one of those two pools exists, because if not it means there are no qualified developers looking for a job, in which case perhaps the issue is with the definition of qualified.

Also, there is the possibility they are getting great applicants that are filtered out before it reaches the individual currently here. It may be possible HR or some automated system is filtering them in such a fashion that good candidates are lost. Maybe HR is demanding 7 years experience in a 3 year old technology.

What we can reasonably assume is that the hiring manager is not finding qualified talent and qualified talent does exist. The idea that qualified candidates are only applying to FAANG or unicorns seems far less likely than something about the position is the reason they aren't getting anyone qualified.

Sounds like it'd be more effective than spinning wheels without traction. :/

Edit: I mean this as in I know several people including myself who apply for 2xxk/year and remote. Post or dm me and I'll see what people I could send your way

> interviewing for a react/redux position one of the first questions I ask is [very vendor-specific technology question]

FAANGs don't hire people for "react/redux positions", they trust smart, conscientious people to learn it when needed. Maybe that's your problem.

Maybe the good people aren't already "react/redux programmers".

I knew almost zero about web dev (I had been a decent C++/Java/Scala backend programmer) when I was hired to work in a web dev role -- I spent the first two weeks doing RoR tutorials on the internet and was just as productive as anyone else a couple of months after that.

Sometimes (many times) if you can get someone who is more of a generalist and is capable of diving in to gain the necessary skills is far more valuable. They are quite often the first to be discarded from the interview process.

Many of the psoitions I have participated in required handling new tasks that were not within the broad scope of what the position was expected to handle. Yet, having the attitude of "let us see what is needed", meant that I was bale to be functionally more effective in that position, including being the "go to" person for those who needed problems to be solved that their normal IT groups would not handle.

I have found too many "code guru's" to not be capable of thinking outside of the box whaen it is necessary. You don't have to be a "brilliant coder" but more of a person who can develop an understanding of the "problem space" of those having the problems that require solutions.

Perhaps you shouldn't be using complicated faddish framework then?

> Honestly you don't seem to be a well put together environment

That is a pretty bold and unfriendly statement to make based on very little information.

> you expect to hire experts in some random framework

We're hiring front-end developers to work on a react and redux application, which is kind of a de-facto standard for single page applications these days. We have an app with a highly dynamic UI that requires immediate user feedback and must work offline. I don't think we're misapplying the technology.

> I'm not surprised you're only getting code monkeys who have used your framework in passing

Again, we're interviewing people with several years of professional experience using react and redux listed on their resumes. We're also not tailoring the interview process to only react and redux specific questions, but if someone claims to have been paid to write react apps for three years, I'm going to ask them some questions about writing react apps.

I believe you'd have much better results if you ascertained the applicants technical ability before the interview, and instead spent the interview getting to know the person, to see if (s)he had a positive and friendly personality. If none of your applicants have side-projects or code on GitHub then perhaps you're searching the wrong places, and/or failing to properly promote the position (especially if some of your developers are earning 2xxK). I'm sure if you posted the position in HN's 'Who's Hiring' and included a 100+k salary, then you'd get flooded by talented developers that have open source code/impressive side-projects. And if somebody with an impressive resume doesn't have that, then you can just request a small take-home assignment that's related to the work you do. If you'd like to avoid getting flooded with resumes', then you could also just reach out to the developers you find interesting on GitHub.. considering your salary range then I imagine you'd have a very high interest rate.

Your hiring woes will get easier to handle once you start treating the Competent Sr React+Redux Developer role as rare. React is certainly popular tech, but solid knowledge of the ecosystem is still far from common. All the places I've done react at had ~10 frontend capable devs, but only 1 or 2 people who really knew what was going on.

It’s a beautiful system that brings a lot of the benefits of a Free-monad style effect system.

I work with lots of really, really good developers who struggle a bit with JS. Most of it is because they come from a totally different background, and the other part is Javascript in general just makes things difficult.

My experience with Haskell is that it's the most expressive and flexible environment for exploring different ways of structuring code that I've ever used. I've seen everything from extremely-imperative code carefully managing memory allocations and munging bits, to very abstract high-level libraries that declare abstract computations that can be interpreted or executed in a variety of ways.

I'm very confused and surprised to see someone assert that Haskell forces a particular structure on your code.

(This is what I love about Haskell, BTW, so please don't read this as a criticism.)

This isn’t a criticism of Haskell: there are plenty of benefits to forcing declarative IO and limiting the language (roughly) to features that don’t break type-inference, but those advantages of Haskell make it much less enjoyable to experiment with programming paradigms in.

I do something like:

  for i=0; i<3; i++:
    try:
      doSomeIoWork()
    catch:
      if i<3:
        # maybe some network/disk issues retry?
        sleep SOME_TIME * i;
        continue;
      else:
        # tried too many times now quit
        raise

  for i=0; i<3; i++:
    doSomething();
    if i<3:
      continue;
    else:
      break;

  catch:
     pass

If it does, you may consider to improve the quality of your tests.

If you don't have all of those it is your fault since you are cowboy coding instead of doing engineering and at this point he is playing along.

Anyhow, if it get the job done, just carry on.

The importance of a random snippet of code of a random company is so small that is pointless to discuss about it.

Just don't let him do any design work and be quick to throw away bad code and refactor.

You got all your tests and procedure in place so it should not be that hard.

We are really overestimating the importance and difficulties of our work.

If somebody code is routinely denied to land on code base because of some of the issues catch by automatic tools, it is reasonable to assume that the quality of the code and the thought given to the code will improve.

Is this person routinely writing code so bad that passes all the automatic tests?

By the way, such code ends up having a quite high cyclomatic complexity.

Yes, a linter or a test cannot know if you are writing silly, unnecessary code, or re-implementing functionality that already exists elsewhere, or making multiple changes downstream when you could make it once upstream. Only a human can see those things, which is why we have code reviews. And for posterity, yes we are using CI, pre-commit linters, unit tests, integration tests, end-to-end tests, and have formal branching, merging, review process, and coding standards. There are no cowboys here, and nothing that you are suggesting will prevent someone from writing low quality code that requires an excessive amount of time to protect the codebase from.

If I ever hire an engineer for my business -- I hope it'd be someone I've already worked with and know -- but if it had to be someone random, I'd pursue this method:

1) Solicit Resumes

2) Pick N candidates

3) Phone screen to make sure they aren't complete assholes

4) Stack rank & pop top candidate

5) Pay them to develop a feature on contract

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

I think it'd be important from the start to let candidates know they might need to do a week or more of work (for pay) before getting a final hire. Some people would be put off by this, sure.

But I suspect the people put-off would be people desperately seeking full-time employment. I think it might attract a lot of talented people that don't want to go through a 4-week long ceremony of an interview process that takes up days of time with no pay, though.

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.

Must be looking to get out for some reason. Doing a small side-project shouldn't be a big impediment.

> I would avoid ever getting myself put into that position.

Extreme risk-averse behavior can cause problems on the other side. Easy enough to give a small-project a try and cut out early when red-flags are actually encountered.

Just the cost of doing business, IMHO.

If you are doing well at a company, I am not sure how you make this seem like a good value proposition, especially in this tech job market. Another way to put it, with a personal spin- I don't work at an actual FANG, but a company that arguably pays better, and their would have to be a very large upside at the other end of this process to make it worth going through. Things would have to be very bad for me to give me up my deep in the six figure job to spend a month interviewing at some place unless it had some legendary track record.

This is all theoretical though and not really worth arguing over. I'd like to see OP try this out and report back the results, good or bad. I could be wrong, but I would be willing to wager that you get a lot more resumes just out of a bootcamp as opposed to people with proven track records currently at prestigious companies.

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....

For example, I like this one and I'm gainfully employed. Much rather work on a real side project than useless, unpaid coding challenges any day. For me, the first has a 98% chance of success, while the second has a 2% chance.

Folks do side projects all the time. How often do they describe it as a "huge risk?"

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

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

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

Some of them couldn't even get nested for loops to work correctly.

If you're hiring someone to write code for you, you need to have them write code in the interview. There's no substitute for it.

Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem.

Thing is, I still had a good 3-4 years of professional experience with stellar reviews, some hackathon wins, on top of having coded throughout my entire life prior. But when I was up on that whiteboard, I pretty much froze for that entire segment. Whiteboards are just a different skill and if you don't regularly code on them at work, you better buy one and practice at home because using an editor does _not_ translate to coding on a whiteboard.

I'm glad you mention this: "Obviously, you can improve the experience - let them bring their own laptop and code on it, no problem", because I did better in interviews that followed which allowed for coding in my usual working environment. Heck, I even passed a technical screen before this company brought me on-site where I live-coded some elevator problem they asked me to implement. After bombing the whiteboard, I wouldn't blame them if they thought I had paid someone else to solve the tech screen.

Similar to how not everyone is able to perform well while having sex-on-demand in front of a camera -- these same people are more than likely able to have sex when not under pressure and observation, and probably are quite adequate while doing it.

My personal experience in software development spans decades, I'm quite competent and I have definitely "choked" at the whiteboard, just like you're describing -- for the same reasons I don't do well speaking in public, I'm not comfortable doing it, and I'm just not cut-out for it... I don't think it's a good measure of actual problem solving and/or software development competency.

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.

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

It's as if you asked an auto repair mechanic about designing involute tooth profiles on fishbone pattern gears in a transmission. Sure, if they could do that, then yes they'll be a great technician, but it has nothing to do with brake jobs and oil changes.

EDIT: Per the responses in the reddit thread, the question was: "So basically it was a variation of the exact change problem (I realized afterwards). You had to validate a string of size n. 1 chunk of 8 characters could have 1 format, 1 chunk of 16 characters another, and 1 chunk of 24 characters another. You essentially had to determine if the string was valid. So in other words, find a combination of these sizes in which the string could be validated. I had 30 minutes."

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.

Who the heck writes code on a whiteboard for production anyways?

Also there's no point in bringing someone in for an interview before they've shown any coding experience. It's a colossal waste of time for everyone, including the candidate

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.

When I am at a whiteboard I am drawing very crude architectural diagrams.

(sorting an array, with any algorithm you want)

Accepting things like bubble sort also makes the exercise doubly pointless.

And if you are unable to sort an array it's a strong signal that command in all other areas of CS is lacking. Does C++ has a standard library for RSTP? Do you think a person who can't sort an array after 5 years of school would be able to fix a bug in a switch' spanning tree implementation?

In your case, at the end you've only figured out that your candidate knows how to sort an array, which even high-school students can do. You can confidently say that your candidate has a level somewhere between student and Donald Knuth, a pretty useless piece of information.

Is there any connection between sorting arrays and spanning trees? If I'm not mistaken, the latter involves graphs.

So I'm not quite sure what is your beef with it exactly. Do you think I should have used a more complicated task? Like, Dijkstras' on a graph? Are you sure that you wouldn't find that objectionable too, given that sorting an array is apparently asking too much?

a) is too easy

b) doesn't have enough meat to differentiate between junior / regular / senior

c) covers very little if anything at all from what a SWE does on their day to day. OTOH I guess/hope you had more things, not just this.

This was the only coding test but we also either talked through opensource code candidates brought in or discussed some parts of one our real project here.

But, you are hiring for a software developer, who should be able to translate business problems that you face everyday into a working system. Don’t you have any real world scenarios that you could use to test on?

Does C++ has a standard library for RSTP?

Maybe not, but I know that there are very few new problems under the sun that most people face and someone has solved the problem before. I also know how to use Google.

https://stackoverflow.com/questions/1460010/best-c-rtp-rtsp-...

(before you go on googling again, the algorithm operates over the switch port forwarding fabric, you can't really use a library)

https://github.com/shemminger/RSTP

Both approaches however would be beyond the skills of a programmer who can't sort an array. And really it's not a high bar, I don't understand this obsession with anti-intellecualism. Everyone likes plumbing analogies, well I wouldn't trust a plumber who doesn't know that water generally tends to flow downwards - it's this level of CS knowledge we are talking about here.

Now if someone did a BogoSort, I would hire them just for their ingenuity and sense of humor.

I like the people I work with to have a good sense of humor.

On the other hand, would you accept a bubble sort as a solution? Or the most degenerate case- a bogosort ;) ?

The problem is that this doesn't scale with talent and/or experience: I certainly wouldn't be better at coding interviews than I was out of college. People who aren't great at hiring take an approach that's valid at the low level and extrapolate it well beyond the bounds where it makes sense.

On the other hand, this only works if the pedigree is recognizable and reliable. I can be pretty confident that I don't need to test basic coding literacy of someone who was an engineer at Google for four years, but I've interviewed people with ten years experience and great references who were clearly dumb as a brick during the interview. In one case, we hired the guy over my objection and spent the next year fighting the fires he'd set whenever he touched anything (the founder eventually found some relatively unimportant, isolated niche for him to keep busy in).

It's a really hard problem, and most complaints I've come across are generalizing from their skewed view of what the candidate pool is like (usually assuming that most candidates are roughly as talented as they are, when the reality is that many candidate pools consist of some of the dumbest people you're likely to ever encounter)

[1] ie, practically everyone

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

The reason being is that intelligence is defined as the ability to acquire knowledge and skills. Intelligent people literally learn faster than others. The skill acquired by a low IQ in five years is often surpassed by a high IQ person with a few months of experience.

[1]https://www.jstor.org/stable/20182140?seq=1#page_scan_tab_co...

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.

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.

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.)

That doesn't mean I am necessarily on board with the fashionable view that IQ is meaningless, but I think to the extent there are people whose IQ is disconnected from their abilities/achievements, it's going to be the ones who are preoccupied with it. So I would think belonging to a high-IQ society would send the wrong message.

I think people genuinely experience this but are unwilling to consider that their pool is not the random sample they expected. Something subtle is filtering out (nearly) all the non-dumb people.

Have you ever seen a personal ad with a long list of characteristics that are unwanted?

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 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.

It makes zero sense that someone can have a deep technical discussion but they're not able to write fizz buzz (which by the way is a crap exercise). Sure, if one is asking general questions about agile, TDD, SOLID and other fluff, anyone can answer those.

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.

Yeah it happens, but not as often as you think.

The complex questions, if I can get answers are awesome. They are also the ones that are hard to objectively describe. Based on the number of blogs read, candidate charisma, my own work pressures - there is a big chance a senior enough person can wave their hands through those. Hence the tilt towards the surety of coding.

Also TBF, in my 1000s of interviews, we have always had a couple of rounds (Bar raisers / System Design / Architecture ... whatever) which try to get the fuzzy input. We get a sense, but that's not in depth as you might imagine. OTOH we have a clear cut answer in the problem solving world that gets us a bit more closer to the hire/nohire decision.

For instance, currently my title is “senior software engineer”. But I am the “Directly Responsible Individual” for a project that one of our clients is paying for. It will be added to our core product.

This means that I’m expected to interact with the client and BA to come up with the SOW, work with the product manager/UX person to design the interface, do some of the web work, write the backend using one of our approved languages (C#, Javascript, Python) , design the database schema, do all of the CI/CD setup and to know the AWS fiddly bits and know which services are appropriate for the asynchronous processing requirements.

I’m no special snowflake, this is life in small companies since my first job 20 years ago.

I don’t interview candidates for algorithms. I interview them to know whether they can hit the ground running on as much of our (industry standard) technology stack as possible, will they make good architectural decisions, can they ship a feature across the finish line, how fast they pick up new frameworks and will they embarrass us with customers and senior management.

LeetCode ability does us no good. I want to know whether you can translate real world business requirements into a working system - including knowing which questions to ask when customers/product managers come to you with “XY Problems”.

So yes - we have to do all those things. I am directly responsible for ALL of data analytics infrastructure in snapchat. Pretty much most senior engineers have a similar scope.

We might be talking over one another though: I am not saying any of that is useless: I am saying they're hard to measure. We still do it though. We also do the coding round as something that gives a more definitive datapoint.

It’s really not that hard to ask a few technical questions based on what they purport to know, the soft skill behavioral questions, some design questions, and ask them about previous projects. The hands on part is the part where they fix the code to make the unit tests pass.

I wasn’t asked a single technical coding question for my current job. I was given real world questions about issues they are having with process and how I would go about (re)architecting some processes.

Now that I think about, my job before that when I was interviewing for the dev lead position I was only asked about process, system design, and a lot of high level theory - both jobs were hands on coding positions. Both of the managers were highly technical with current programming experience.

But, I’m not completely disagreeing with you, if you are solving hard problems(tm) at scale you need people who understand algorithms and you may not be able to use off the shelf solutions - I would say Snapchat qualifies for “at scale”.

But, for you typical yet another software as a service CRUD app or your typical dark matter corporate developer - and those positions are a lot more numerous than HN seems to realize - the complications aren’t in the complexity of the code, it’s in translating the business needs to code and shipping software that the company needs.

As strange as it sounds, the “coding” side of software engineering has gotten a lot simpler 20 years into my career than it was when I started (C, C++, and a little x86 assembly). The “engineering” side has gotten a lot more complex and requires me to know a lot more technology.

I don’t think it’s because I am better “coder” now either. When I got my first job, I had already been a hobbyist for a decade doing assembly.

I have been able to weed out candidates by asking them to do an isOdd() function as part of a pair programming exercise. It was still the Bozo filter before I gave them harder problems. Similar in complexity. But even that, I’ve done with an IDE with a skeletal class and failing corresponding unit tests.

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.

It takes much longer than people assume to get a dysfunctional team member off the payroll. In most shops, new hires spend months in a (reasonable!) reduced-expectation state of on-boarding and ramping up, during which their performance can't readily be measured. It then takes several engineering cycles to figure out that they're not working out on a particular project, after which the normal response is often to try moving them to another project. You can be more than 6 months in with an employee before there's a confident assessment in engineering management that someone isn't working out. In many shops, at that point the next step is to begin the process of "managing them out" (often with multiple stages of PIPs), which includes a fig-leaf premise that performance can be fixed and the team member retained.

And that's if things are carefully managed. Lots of teams, even good teams, aren't carefully managed, and it can take more than a year to detect and propagate the signal that someone isn't working out.

The net result is that people can accumulate impressive-looking resumes without ever effectively delivering for any team, and because resumes get more impressive over time, the roles people get offered improve as well, compounding the effect.

I'm an evangelist for evidence-based hiring techniques and a fierce critic of standard interviewing practices, which I agree are dehumanizing and unreliable. But we started our hiring practice[1] not because we wanted to include more people, though that was a happy result of it, but rather because we'd been burned repeatedly by good resumes and strong interviewing skills.

At this point in my career, for a technical/IC role (really, any role), I'd be alarmed if I wasn't given practical tests to verify I can actually back up my talk. Their absence would make me suspicious (though perhaps not dispositively so) about the technical ability of the team I was considering joining.

[1]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

Agreed, and let me offer an anecdotal, real-world example. Before I was in this racket, I used to be a land surveyor. Because it's both technical and licensed (and btw, I'm not going to make an argument for licensure, just mentioning it as a qualifier), you had to take a written test and pass a rigorous interview before you were accepted as an apprentice land surveyor. The test involved trigonometry, plane geometry, algebra, property law, and basic statistics. The sit down involved attempts to surface red flags all the way down to testing if the candidate was afraid of dogs.

And after passing that, then you were hired on as an apprentice which meant that all your work had to be reviewed and signed off on by a licensed PLS while you learned on the job and could eventually take the PLS exam yourself.

Too often in software engineering, a candidate can jump through the hoops and get hired but even if their role is junior, they're essentially on their own except for code reviews. There's very little mentoring, because senior people are neck deep in work and nobody's got time for that. The company has to be committed to mentoring and carve out space and money for it in order for it to happen.

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.

I do like coding a lot, but these home tests can never excite me. I have a family. I can't do it after office. In office I want to work honestly on my job. So frustrating!!

I agree with you in principle for a programming job, but from the post, this was a dev ops job, and the candidate was asked a dynamic programming question. There was no link to the JD, but I suspect it had little by the way requiring a CS degree.

Older developers come in two forms. Those who aggressive learn, have matured beyond “just developers” and those who are set in their ways. I’m 45.

There will always be unknown unknowns. We are just trying to cover the known variations and if he has any unknown knowns[1].

1 -https://academic.oup.com/jxb/article/60/3/712/453685

You're right that there are plenty of developers that have no experience with GitHub, but I'm sure there are far more who would struggle with simple theoretical questions and programming quizzes during the interview, because it's difficult to think clearly when you're feeling a lot of pressure.

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.

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.

This to me is one of the worst things about the Tech industry. You could be a senior engineer at Google and to move to a new company you will have to do the same algorithm interviews that New Grads are doing. It's a bad look for the industry. Like oh I see on your resume that you have worked for Facebook, Google and Amazon, well we better put you though an algorithm interview because you could have just been a false positive at all 3 companies. It massively devalues SWEs in an industry that we already know colludes to depress wages.

>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.

Not disagreeing but my point was that they have a far better performance record despite not doing the bizarre interviews that the Tech industry favors.

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.