[creamytaco]

Your post ought to be ample proof that subjective opinions (like the one you display here) are not solid grounds for hiring decisions.

When looking at this person's Github page, I -unlike you- see a vast number of trivial projects that can best be described as regurgitations of other people's work. Even worse, if you actually look at his first pinned project (https://github.com/kevinburke/nacl), you'll see that it is nothing but a wrapper with trivial changes/updates... an anti-project.

In the end, I see code that provides the illusion of competence but, when actually inspected, is actually telling me not to hire this person. The fact that pretty much anyone can declare oneself "a software engineer" today and easily present a veneer of competence together with powerful financial incentives, makes it absolutely necessary for any serious engineering team to have objective measures in place in order to evaluate candidates.

There are so many terrible engineers out there (and some even slip through the cracks and land at places like FAANG) that doing anything less is irresponsible.

[vanusa]

I never said you should just hire someone on the basis of their repo.

But rather, if you're looking for a basic smoke test which can answer the question "Can this person actually code? Do I want to spend more time engaging them?" -- there are better ways to do that than expecting them to cram on a list of algorithms to recite over the phone. Like looking at an actual work sample.

The fact that you looked at this work sample -- and came to your own conclusion about whether they would be worth engaging -- validates this very simple and basic point.

Which is your call of course. He may not meet your bar, but it would be absurd to say this guy can't code, and hasn't been around the block in terms of general CS concepts.

That said -- my own subjective opinion is that you're being exquisitely savage in your assessment of his NaCl implementation. Yeah, it's wrapper -- like it says in the Readme, and like a lot of working code out there. It's a pretty established way of solving a problem, in fact -- in some cases a very efficient and elegant way. It's not the same thing as writing 20k of primitives from scratch, of course. But that's not what he's presenting it as. He's not saying it's a "tour de force". He's saying "I think this shows we can talk about other things besides FizzBuzz".

And then other things you're like saying... like "an anti-project"? Wow.

[creamytaco]

Engineering is not about whether someone "can code", but whether someone can _engineer solutions to problems_. Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?

This is also what a lot of those engineering interviews are trying to ascertain, in a quantitative manner. I couldn't care less about someone's degrees or ivy league schools or Github projects (in isolation). These are all secondary -if that- considerations, problem solving ability being primary.

[vanusa]

Has this person demonstrated that through the projects he chooses to put on display (and advertise as signal for his ability) on Github?

Using the example you disparaged (his NaCl implementation), I would say:

"On first appearances, clearly yes. The problem was to adapt the a set of standard Go functions to a foreign interface - something one does quite a lot in an engineering environment. Also, the fact that he's aware of projects like NaCl and seeks to learn from the likes of Bernstein and Lange is a positive signal."

If I wanted to, perhaps I could drill down into the code and/or the NaCl spec itself. I don't know Go, so for all I know, maybe his code is actually horseshit. But all I'm saying is - from first appearances, definitely a positive signal. Infinitely more informative that FizzBuzzing (which would insult both his intelligence and mine).

This is also what a lot of those engineering interviews are trying to ascertain.

I've already made it clear that a glance at a repo does not obviate the need for an actual interview.

[kevinburke]

So I wrote that because a client had a bunch of existing nacl messages that were signed using Python, but the existing Go library uses a different protocol to sign messages than the standard Python library. The existing Go library also didn't support all of the API's supported by nacl, I figured if I was running into this, then other people would too. Clearly based on the number of stars it seems like a lot of people _are_ finding it useful.

I guess in your eyes I should have also done the cryptography, however, I am not a cryptographer or a mathematician and one of the first things that you learn when you start doing work with cryptography is that you shouldn't roll your own crypto.

I decided to make that library prominent because in my consulting practice I saw a lot of clients using cryptographic primitives that were clunky and/or had a lot more overhead, for things like cookies or public key authentication or just sharing messages. nacl is difficult to use incorrectly, and is fast and efficient in terms of overhead. I wanted to promote use of nacl more than the work that I was doing for it in particular.

For that client (a smart lock company), I rewrote the backend, that someone else wrote in C for a specification that did not match the needs of the business. The C software was extremely difficult to read and maintain - socket writes in a callback in one part of the code and socket reads in a completely different part of the code, shelling out to curl, simple Mongo queries that would take 50 lines to set up. As a result the engineering team could hardly make any progress deploying new features. I ended up rewriting the whole backend in Go, a few thousand lines of understanding what the C code was doing, and porting it, to the point where the team could actually release patches and new features on a regular cadence, and figure out what on earth was going on with the Mongo queries and shell-to-curl.

That's not public though, if you're looking for public work, you could look at Logrole (github.com/kevinburke/logrole), a HTML client for your Twilio call, SMS, phone number, and recording data. Of course, you could say "that's just a regurgitation of whoever did the API client", which is true-ish, but I also wrote the API client (github.com/kevinburke/twilio-go). Of course, you could say "that's just a regurgitation of the Twilio API," but I also helped build and maintain the Twilio API, as well as the documentation and information architecture (https://www.youtube.com/watch?v=sQP_hUNCrcE), and the client libraries (https://www.youtube.com/watch?v=C_UJHqR_2Mo).

Most recently I was hired as the first engineer at Meter (meter.com) where I built out the entire backend API, the deployment infrastructure, the CI/CD infrastructure, a pipeline for the in-the-field servers to update themselves, and a method for access points to retrieve configuration from the backend. All in all this was probably about 30-50,000 lines of code over two years. I think the API has had one customer facing error in two years and no downtime.

It is true that anyone can call themselves "a software engineer" but not everyone can get contracts for a sole member consultancy and, crucially, get their contract renewed multiple times at every single client. If I was selling snake oil and not delivering anything, that would not have happened.