Wow. That's a hell of a loop.

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.

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?

Super late responding, but I enjoyed your comment and code.

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

Well, I tend to spend a lot of my spare time noodling on what I think of as fundamental CS problems (what's the optimum radix for a min-heap? 3, I think, not 2), and I've spent a fair amount of time programming in languages like C where implementing mergesort from scratch is actually a practical thing to do. And I have a prejudice in favor of knowledge with a significant shelf life, like how mergesort works, rather than, say, how to work around the bugs in the latest version of React, which is also practically necessary for getting stuff done. So I might have a bias in favor of that kind of thing.

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.

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

Would a better interview test be to ask the candidate to review code rather than write it themselves? That is, give them a code sample, describe what it aims to do, and ask:

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.

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.

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

> This person is so convinced that they are a good developer that they refuse to take direction or ask questions

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.

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

> I typically focus on reviewing code with bugs and refactoring bad code instead of forcing them to whiteboard

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

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

At least you have a constant source of code for interviewees to fix.

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

I think a bigger problem is that they probably weren't lying or fabricating their resume. They probably weren't trying to trick you in some way, they probably just have actually programmed like this for the last 10 years! In a lot of work environments especially in the midwest, it isn't surprising to encounter people like this that don't know basic best practices.

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.

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.

I didn't mean it to be insulting or to imply that there are not talented people in the Midwest. What I mean is that if you look to places like Louisville, KY for just one example, or Dayton, OH and look at the type of pay that is being offered there, it is vastly below the coasts. Even adjusted for cost of living and other expenses, many cities across the midwest pay below what is a reasonable market value, and naturally they only get people who will accept those below-market rates.

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.

i'm not sure why location has anything to do with code quality. imo, it doesn't.

It doesn't, but it does.

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.

This pushing of best practices you speak of is clustering especially in the geographic area where the norm is frequent job-hopping (before you fully reap what your practices sow), and where many also celebrate "move fast, and break things" during each employment stopover?

Yes, almost all of these companies are still doing better than the IT shops I remember from the 90's.

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

If you heard about all of the bad code at Twitter pre-IPO, large companies don’t care about code quality either.

Startups are a bit different in that it doesn’t make sense to pay down most debt until a profit stream is found.

Or until they convince someone to acquire them or convince the public markets to give them money and remain unprofitable.

It's true that many devs aren't trained to write maintainable code, but there needs to be some responsibility on the part of the individual dev too. If there's no training, they need to be made aware of resources like Code Complete and Clean Code, so they can take some initiative and work through those books.

Some people have 10 years of experience, others have 1 year of experience 10 times.

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.

> political reasons and difficulty hiring a replacement, we can't fire this person

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

Every body writes something like this. Every body. Just because some devs don't write this in a single block of code, and scatter them across program logic doesn't make them any better.

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.

Since they are knowledgeable about your domain, maybe there is a position at your company that they would be able to fill better?

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

ok Im stumped :) Would be interested to read some clarification on this.

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.

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

Noooope, looking at it again it does nothing..guessing some off by one error with whatever this thing was intended to do by the author

I do the same for a “senior” developer with 20 years more experience than me and a bafflingly appalling understanding of how to write basic code.

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.

Is this person doing (valuable) work that would even require hiring a replacement? If not, fire them. If so, lobby to secure a backfill and then fire them.

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

>There just isn't a supply of good developers for companies that aren't FAANGs or unicorns.

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

No, that's why I said "before anyone says we're not paying enough...". There are team members making $2xxK/year here, and we're not in a coastal city. The problem we have is that almost every person that comes in here bombs out in the first five minutes of the interview.

If that's a competitive salary for your area (you would know better than me, but that range in the middle of the country certainly seems competitive), then have a look at your recruiting sourcing funnel.

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.

You're correct. The problem is that the positions we have open are for front end developers, and for a variety of reasons (mostly that the scale of complexity on the front end has increased so rapidly that the industry still has a lot of people in it that were writing mostly HTML and CSS a few years back) the supply of competent developers is far lower than the demand, and anyone worth their salt is already happily employed. Highly skilled front end developers can basically write their own check these days, and if you manage to find one in the brief amount of time they're in-between jobs it's pure luck.

... so you're not paying enough to entice them.

Which is what was said three posts up.

Thanks. Unfortunately we can't afford to pay front end developers $300k/year. And what we are paying is more than competitive. It's not an issue of pay, it's an issue of availability and not having the resources to stalk and poach developers from other companies. We also have a generous internal referral bonus, and various recruiters sourcing candidates. Is there something else I'm missing?

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.

If you have budget for two poor front end devs, IMO you’re way better off paying 1.5x and getting one good one, if comp is the sticking point for landing a good front-end dev.

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

> Is there something else I'm missing?

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.

Seems like Paul can’t catch a break here. He is simultaneously not paying enough and paying too much...

If there is both a pool of qualified candidates that don't think the pay is high enough and thus don't apply and a pool of candidates that think the pay is so high there must be some catch and don't apply, they could both be true. You have to decide which pool to target.

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.

Have you considered hiring remote workers so that you are not limited to those living in, or willing to move to Austin, Texas?

Maybe hire people with the a good teamwork attitude + ability to learn, and training them up to the required standard?

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

If you're paying $2xxK/year and allow remote just post your job link here. I, and all my social circles, are fairly successful devs in a coastal city and would jump on any offer that high as long as we didn't have to move to the midwest

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

Wow, $250k/year is quite high for Austin, Texas. It's shocking to realize that you can't find decent programmers even at that pay grade.

> There just isn't a supply of good developers for companies that aren't FAANGs or unicorns.

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

Could you not hire someone smart who doesn't already know react/redux and teach it to them? Or give them a couple of weeks to do some tutorials?

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.

This is usually not a consideration and has not really been there for decades. What many forget is that people who are speciallists in the area thay are recruiting for are not necessarily the best candidates for the actually position.

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.

This is what we've resigned ourselves to, but it's very expensive. We're building crud apps, not doing cutting edge research, so I assumed we would be able to find someone that is already up to speed on the language and frameworks. You also have to factor in the cost of senior developer time spent coaching, the lost productivity, and the code quality suffering in the meantime.

You might be shooting yourself in the foot by having not picking an ecosystem that better supports your business case. No one I know who's good at React+Redux would pick a CRUD app as the domain they'd like to exercise those skills in.

The app in question is used by retail employees at hundreds of locations to manage inventory. It runs on a tablet, has to work offline, and has a very dynamic UI that has to keep thousands of complex relational entities in local state, and perform aggregate functions on them in real time. It's still a CRUD app, but it's very much the use case for a SPA.

> We're building crud apps

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

Was just thinking that too. Many folks like to complain about the quality of "the help," but don't look in the mirror.

How quickly do they answer that to get that so wrong? I freeze like crazy with interview questions. Even you just putting the question there, my brain froze and I couldn’t remember the word “action” for a couple of seconds.

They usually answer confidently right away. It's one thing if you're nervous in interviews, it's another if someone asks you a novice-level question about your area of expertise and you give an answer that is objectively wrong.

Judging by your posts in this thread, have you considered the problem might be that you (and many other companies) hire people based on their ability to answer theoretical questions (which also happens to be while under a lot of pressure), rather than their ability to code? I'd like to think there are plenty of candidates that have open source projects that showcase their coding skills, or that have made impressive side-projects.

It's not really a theoretical question though. It's a very concrete example of the most common operation you would need to perform in a front end developer role. And none of the applicants we've seen have side projects or code on github. If you know of a method to ascertain someone's ability to code in a professional environment in a one hour interview, I'm all ears!

Honestly you don't seem to be a well put together environment and it feels like you expect to hire experts in some random framework instead of good software engineers. I'm not surprised you're only getting code monkeys who have used your framework in passing or have done basic pixel dev applying that don't meet your bar.

I'm getting tired of replying to troll-ish posts, but:

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

Even so, you shouldn't underestimate people's ability to have a meltdown during the pressure of an interview.. I won't comment on the React question, since I've never used it and don't know what a 'reducer' is.. but even the truly bizarre for-loop you posted is likely to cause confusion to some people during the interview. If I saw it while I felt the pressure of an interview, then I'd possibly feel confused and would need a couple of minutes to understand what was happening. This would no doubt reflect poorly on me, which is unfortunate because when I don't feel the pressure of the interview then I can instantly understand (and laugh at) the code.

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.

This question is really tricky, though: depending on your frontend stack, the answer could be in an event handler prop (e.g. onClick). In mapDispatchToProps, in a thunk, in a saga, etc.

Correct. Any one of those answers would be acceptable :) (except mapDispatchToProps, that will fire the API request every time an action is dispatched anywhere in your app). Also, the context of the question is very specifically "within redux", and all I'm looking for is an understanding that redux is synchronous by default and asynchronous logic has to be performed in a middleware. If your answer is "put it in literally the only place you aren't allowed to put it", you lose some credibility. Also, so many people in this thread are getting hung up on the fact that we're trying to find people that understand a very common framework that we use, and that the candidates claim to have professional experience with. I wouldn't expect a junior to understand the details of redux, but we need senior people that don't require a year of hand-holding to be productive. If I am hiring a plumber to fix my toilet, and they say they have three years of experience fixing toilets, and they don't know how a toilet works... am I at fault for having unrealistic expectations?

Plumbers with 3 years of experience fixing toilets are usually still in their Apprenticeship programs. Around year 4 or 5 they'll graduate to Journeyman at which point they're authorized to work without the supervision of a more senior plumber. You hired a plumber to fix your toilet, but you have a waterless composting toilet and your plumber's knowledge is still at the level of "water and poo goes down the pipes".

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.

I mean in the functions in the object returned by mapDispatchToProps, something like `onClick: v => fetchJson(‘/foo’).then(w => dispatch(fooAction(w))`

Thunk, saga (as far as I know), etc have you put the code in an action [creator].

No, usually with sagas, your action creator stays synchronous and you yield your actions from a generator function that contains all the asynchronous bits.

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

Javascript sucks.

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.

This is just false: there are a bunch of sharp edges in JavaScript, but once you know them, the language itself is one of the more pleasant languages to use: this can be a bit of a problem, since the languages itself doesn’t force a particular structure on your code like Java or Haskell do, but on the other hand, JavaScript is an amazing language for experimenting with new programming paradigms and application architectures.

What structure do you believe Haskell forces on your code?

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.

Haskell doesn't force anything, but it does make some pretty strong suggestions. Haskell suggests immutable data, pure functions, and algebraic thinking. You can make your data mutable, do everything in the `IO` or `State` monad, etc., because Haskell doesn't force structure on your code -- but the suggestion is still there, whispering in the back of your mind.

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

This is what I was thinking: if I just want to sit down and design myself an object system, Haskell’s type system gets in the way of the necessary parts. (Unless you want to limit the interaction between your object system and haskell’s types in annoying ways). I’ve implemented CLOS-style mutimethods as a handful of functions basically translated from the Common Lisp in the art of the meta-object protocol. And the multimethods work transparently with any ja type.

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.

Thanks for the clarification!

Forgive me because I have used a similar idom when dealing with io.

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

Am I doing something stupid here?

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

I think the try/catch block is confusing commenters; it's irrelevant to the control flow in this case. You could consider it equivalent to:

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

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

what was wrong with this code? I don't deal with exceptions a lot so not familiar with the idioms here. Is it because the catch is not doing anything at i<3? And then at i==3 it just breaks from the for? So rendering the whole thing useless ?

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

So, the developer is overconfident. Have you tried coaching this person into understanding this? I feel that is part of good management.

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.

I... never thought to use a continue inside a catch block. Points for creativity at least....

I am kind of new to all coding. Can you explain what is wrong with that code?

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

Ah, I see that now with the while loop restrictions. Thank you.

For loop syntax is unnecessarily complex when you first encounter it. A simple if then control flow is much easier to understand and is how it’s done in assembly anyway. Unfortunately he used both. Maybe an opportunity to teach him about goto and labels...

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.

I wasn’t disagreeing. Just adding that their code shows they don’t understand goto and labels either.

But code like that pass your unit tests, integration test, CI, and LINT?

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.

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

I answer to brother below.

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.

I don't agree. I think there is no reason to get over pithy about code style. Question one is "does it work," but question two is "can others read and maintain it." By adding in extra logic and lines that do absolutely nothing, the next reader of the code has to slow down and think, "ok, person A did this for a reason, what is their reason..." and disassemble the bad code only to realize that they just waited their time doing so. Readable and maintainable need to be considered for any code that will be maintained or read by others.

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

The introduction of such tools serve not to prevent bad code to land, but to force people and code into a process.

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.

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

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.

Entrepreneurial engineer here...

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.

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.

> top tier talent at...

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.

They may be looking to get out, but you are essentially asking them to leave their current job so they can spend a month (or whatever) on a paid interview at your company. You are not only giving up your previous job, you are essentially giving up your ability to interview elsewhere as well. If this doesn't work out, either because you don't like me, or I don't like you, your business, the tech stack, whatever, I am now in a really shitty position, I am giving up what little leverage an employee has in the labor market- the ability to look for a job and say no without worrying about paying his bills.

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.

Not sure what the other guy implied, but that’s not what I had in mind. Rather a side project type of thing. Little risk for anyone. No one has to quit.

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

There's no perfect way to hire, don't let it be the enemy of 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.

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.

> huge risk

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

No, some folk do side projects all the time. Mostly very young folks without families or substantial hobbies.

We make time for things that are important. If not to you no problem, but not the impossible burden you make it sound.

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?

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.

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