I disagree with this post. I’m also a professional and my time is valuable too. However, two of the three suggestions they made are taking significant time away from me and my team for evaluating a candidate that potentially can’t even write code to solve a simple task. Part of an interview process is to filter out people before it gets to that point, so we’re not wasting employees time.

I think coding challenges are optimised for candidates who are looking for a job. I’ve been in that boat once, and when you’re actually looking for a job your “valuable time” is of course bet spent trying to get said job (by doing coding challenge or whatever else).

Most of the time, though, I’m being recruited. I’m not going to do a coding challenge for a recruiter.

I disagree with this post. I’m also a professional and my time is valuable too.

I have the same problem with it as a hiring manager– how do I screen out socially capable but inept developers– and I share the author’s opinion when I’m the candidate– this tells me nothing about why I want to work for you. Each side wants the other to make an unequal commitment so it amounts to a single round game with that candidate. As a candidate with a choice of games, I don’t want to play this one and it signals disregard for/trivialization of the candidate’s investment and work history. For the hiring side, this plays out multiple times and there is investment in posting, screening, reviewing, etc. so regardless of this round my total investment is higher but not visible.

So what have I personally done? When I’m the candidate, I refuse to do the coding challenge and say, like the author, check my repos and talk to my references (unless the problem catches my interest, then I might). I have that luxury. When I’m the employer? Up front I explain how it works and what timeline they can expect as part of a 15-minute phone screen for basic info with someone technical. Then I arrange a round of 45-60 minute calls: a technical call with someone on the team and a social/technical call where I try to get them to talk with me about their work in detail and many of the non-code aspects of their job, habits, tools, designs, etc. They’ll probably have a call with my manager or another peer. Then, if I’m satisfied but not sure, I bring them in or have a video chat and they do a quick coding test. This wastes less of their time, makes my commitment visible, and seems to work but it is not a scalable process.

I have a portfolio and some github projects. This is where most of my hiring emails come from. So when a company doesn’t spend the time to check that out, and they want me to implement some trivial thing that doesn’t generate value for them, I don’t have time for them either.

I’ve had companies pay me to be a consultant for a week before giving me an offer, which was a nice way to learn about who they are. On the other hand, sometimes companies give me job offers now before I know anything about them, and I have to pump the brakes and talk to more of them before I feel comfortable going into something long-term.

They aren’t the only candidate we would interview and in my opinion, it is better to have a consistent process. If every candidate had a similar level of public presence to evaluate then maybe that would be different.

So, again IMHO, at that point you’re basically throwing out someone with passion and talent due to bureaucracy. If I come to you with decades of experience/conference talks/published papers/lots of open source software to review/whatever…and you ask me to spend 30 minutes doing trivial work, you’re basically implying that I’m lying to you and/or that your company cares more about process than people.

Some of the best engineers I know have zero public presence. Some of them are extremely humble and don’t like public flashiness. Some of them have families and maintain a strong work-life balance with non-tech stuff. Never assume those with a strong public presence are giving the world the whole picture. You still want to drill into the parts of their personality that they don’t highlight.

Why does having a public portfolio make someone an obviously better candidate? What makes a candidate obviously better? Arbitrary social metrics? Ability to speak quickly about technical topics? Ability to talk bullshit without it sounding like bullshit?

How do you know a candidate is obviously better without having them go through the same process and pipeline?

How do you know a candidate is obviously better without having them go through the same process and pipeline?

If the code in their GitHub account is as good or better than what would be tested by my coding test, why subject them to that? Ask harder questions, ask questions about the things that the coding test wouldn’t cover (including “soft” things that would judge a good fit), etc.

Why does having a public portfolio make someone an obviously better candidate?

Which surgeon would you rather have? The one nobody’s ever heard of, or the one who has published articles on the relevant surgical procedures, who goes to conferences to learn more about surgery, who obviously is passionate enough about medicine that they would study it even if they weren’t getting paid?

There are, unfortunately, a lot of liars out there. I won’t say that industry hiring practices are anywhere near ideal, but as an interviewer it was astonishing how many people with great optics were incapable of coding. Someone would speak with great passion about all their projects and yada yada, and id be fairly convinced they could do the job, then I’d ask the most basic question imaginable. Splat.

I guess it helps if you choose to believe the test isn’t meant for you, but for all the other pretenders.

Even more surprising to me is that people who can’t actually code are somehow able to sustain careers as developers. It started making a lot of sense to me why good developers are in such high demand after I had the opportunity to do some interviewing and found that a frustratingly large amount of applicants can’t actually code, even if they look great on paper and are currently employed as developers.

I think it’s incredibly risky to hire a developer without seeing code that they have written, be it from open source contributions or a coding test if necessary.

Onsite nerves can kick in. It sure as hell did for me. I hate white boarding and I lockup. Totally brain freeze. That said, if it’s a basic one like writing a loop…well, they somehow lied their way into the onsite. Thing is, a take home coding challenge can weed out those people pretty fast. If they do that and come in and fall flat on their face before the whiteboard I don’t totally discount them. Anyway, there’s no perfect solution. There is always the potential to hire someone that is great at coding interviews and then sucks at real world problems.

This is exactly my company’s experience. Half of the candidates would just bomb out on the C++ test even though they have studied it at high school/college/university and worked with it at their job for 5-10 years. How?!? Because they were either doing Java, not C++, or they were actually managing a team that did C++ and never had to touch it themselves (Well since leaving school at least).

I think the moral here is “you don’t need to do coding tests if they have a good portfolio”, but I have also seen similar posts on this very site complaining about companies that judge you based on your portfolio because not everyone does side projects or work they can share.

Maybe we need to consider that there are multiple classes of applicants that need different interview styles; in particular, the divide here seems to be between “day job” programmers who have no publicly visible work and “enthusiast” programmers who do. It would probably make sense to use a different process for each. (Although I would worry a bit about people who hire software ghost writers. If you think that’s far fetched, you haven’t done interviews.)

It’s more complicated than that, even, because I have a portfolio, but it’s almost completely orthogonal to all my professional experience (the biggest single element of the former being a 3D engine in Rust, and the latter being backend/data processing software mostly in Java). I’m sure it still helps, but it probably shouldn’t—my ability to microoptimize linear algebra and my ability to wrangle large frameworks and macrooptimize data flow don’t really have much to do with each other.

Ultimately, I think it’s the hiring manager’s job to tailor the process to the candidate. If they have a relevant portfolio, great, look at that. If they have an irrelevant portfolio, that can probably at least tell you whether they’re completely incompetent. If they’ve currently got a job, they’re less likely to put up with an extensive coding test. Etc. There probably are no hard-and-fast rules.

It really depends. For somebody who isn’t currently working a full-time job and has plenty of spare time but not a lot of experience, a take-home project is a great opportunity to showcase their skills in more depth than a mere phone screen ever will. Moreover, a properly designed take-home can actually be fun even for somebody who does have a full-time job writing software.

If you use a take-home to screen people then it is a very good idea to follow it up with a 30 min discussion about the trade-offs made in the code and potential extensions to it, which will be extremely difficult to answer for somebody who did not actually write the code themselves.

While this is a good read, I do think that the author is misinterpreting Uncle Bob. The original Tools are not the Answer post specifically says that he supports using these tools:

I think that good software tools make it easier to write good software. However, tools are not the answer to the “Apocalypse”.

His point, as I understand it, is that more tools cannot solve a lack of discipline because it takes discipline to actually use those tools. And right now most developers don’t even use the simplest tools available to help ensure correctness. If a developer isn’t disciplined enough to write a unit test, why do we think the same developer will be disciplined enough formally prove the correctness of their program?

I stood before a sea of programmers a few days ago. I asked them the question I always ask: “How many of you write unit tests on a regular basis?” Not one in twenty raised their hands.

Uncle Bob blames this problem on a lack of discipline. I think that’s partially correct, but also ignores that developers are embedded into dysfunctional contexts that often punish discipline or reward fast completion more than correctness.

I agreed with him on that point. Discipline is the most important factor. It doesn’t matter what it’s motivation (eg money, principles). The best returns come from a mentality that constantly tries to improve the process of writing solid code or the code itself. Such a mentality naturally seeks out methods such as unit testing, code review, or even formal methods. Without that mentality, they’ll half-ass their QA or just leave it off altogether. This is what we see a lot in both proprietary and FOSS software.

It’s slow. While the speed of a shell script rarely matters, trying to use the shell like a programming language will waste system resources.

When speed matters, python is not going to be helpful.

We can often omit crucial features of a script. Checking the status of programs using $? can be accidentally left off, leading to inconsistent behavior.

Just like all other languages.

The shell language’s only data structure is the string. There are ways of decomposing strings into words. The expr program can convert strings to numbers to do arithmetic. The date program allows some date manipulations, but the rules can be obscure.

Not even wrong.

array=(a b c)
((x+=y))

obscure : the second appearance of the word in the sentences I quoted here. Let’s do s/obscure/unknown to the author/.

Unit testing isn’t easy. There are some packages like Bats that can help with unit testing. A language like Python has a much more robust unit testing capability.

shell scripts are, for the most part readable by humans. Even before I could write a shell script without cribbing off an existing one, I could understand what they were doing 90+% of the time.

But I would also say that if your job is ops-heavy, you should probably know how to read and write bash. Not because you’ll be writing all your scripts in shell, but because you’re working in a field where a large number of small utilities that you can basically just grab and use are written in shell already.

I wholeheartedly agree with the author that for larger tools should be written in a higher level language almost all the time, but an ops-person should be mostly fluent with shell syntax, and the shell is more easily read than java, c#, and other languages people use every day.

The Java/Microsoft mainstream is gaining new traction. Aesthetics also got diluted. Careful engineering is getting diluted. Social networks ubiquity and the easy path of quick cloud deployment is making people less and less patient. Crafting requires patience. People crave Likes, a new generation of vanity metrics arose.

I feel like I’ve confused Ruby’s grammar before, but I don’t have any examples at hand.

OTOH, people like, and can usually navigate ambiguous grammars, so as much as I agree with you from a parsing standpoint (there are places where the error state is manually reset…yeah), I don’t know if it is something the user feels the complexity of, despite my expectations that it would.

We would all save a lot of time if we acknowledged the science and then focused on showing why that science doesn’t make a clear argument for a particular policy direction.

I think it’s worth noting that the sexists will be arguing in bad faith no matter what. I feel like saying “we should be 100% rigorous” is noble, but I also think it’s dramatically underestimating the depth of the problem, perhaps malignantly.

Moreover, it would be nice if we could come out and unequivocally say that women are capable of programming, analytical thinking, and that anyone who doesn’t believe this is completely wrong.

I don’t care much for the reasons given in the article. To me, it’s the fact that I can run it over SSH, and of course the modal editing (note the fact that Emacs has a VI mode, but not the other way around :^) ).

I don’t either. But I only use vim over SSH. For me, the refactoring powers of modern IDEs are worth far more than the editing capabilities of vim. And I don’t have to have a finicky and fragile setup. Not to mention how much time it takes. I used to be a very big vim user with a huge init.vim (ok Neovim user, but whatever) but I found myself significant more productive in a jet brains IDE.

It helps that Ideavim (the official vim-keys plugin for Jet Brains’ IDEs) is really quite good (though I’m not a vim power user). I can’t see myself going back to vim for regular coding - I like my IDE features too much, and I actually think people who eschew good IDEs are needlessly hindering their own productivity, or perhaps haven’t really been exposed to the power of (for example) a great debugger.

I think it varies widely by language. I’m a big Vim fan, but If I’m writing C#, no chance you’re pulling me away from Visual Studio. VsVim is not quite as good as real Vim, but you’ll never beat the IntelliSense auto-completion, realtime syntax and type checking, a real Go To Definition, build and unit test support, TFS source control support, etc.

On the other hand, if I’m writing Ruby or Python, I’d rather use real Vim and do anything I can’t do in it on the command line. Most of that other stuff is either not possible or not needed with the more dynamic languages.

Haven’t done as much Java personally. I think it’s more usable on the command line than C#, but doing it in IDEA or something instead is such a huge boost for all the same reasons.

Love haskell, but hate it’s use of a million symbols for operators.. sometimes it can be averted by using word based operators, but thats not assured. I guess Idris is somewhat saner thanks to namespaces, but I think I would ultimately find something like a lispy haskell with namespaces to be more ideal.