Beginning in the 1960s, Clair Cameron Patterson was very vocal against the widespread use of leaded gasolines. He was ignored and mocked for over 20 years, but kept going because he knew it was damaging, and fought to end its use. He didn't just "not like it", he was compelled to improve the world.
Whether you agree with him or not, Stephen believes crypto is damaging to society. As such, he is driven to help root it out.
You see; I am also confused by this. The author chooses to work for free, and yet complains about his pay relative to the amount of time he must spend doing cognitively taxing work.
In my 10 years as a professional software engineer I have seen this same thing happen time and time again. My colleagues devalue themselves constantly by working for free.
If you earn $80k a year as an engineer, you rate is roughly $38.46 per hour if you work 2080 hours in the year. Let's say you opt to work an extra 30 minutes a day (very often the case for many devs who work into their lunch break); that equates to an extra 130 hours of work per year for free. So what you're actually doing is earning $80k a year for 2210 hours, or $36.19 per hour. That's roughly ~6% less pay for your time for working an extra 30min a day. Now imagine what happens when you work those extra 30mins + a few weekends here and there. The total percentage of your salary drops significantly as a result.
To me, it's not about the code on a whiteboard vs a computer and correctness.
It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them?
A whiteboard to me is a much simpler and accessible medium through which to explore a problem vs setting up an environment and having to type code and dealing with all the minutiae that comes with actual development.
Of course, it isn't the ultimate method of evaluating a candidate but it's certainly valuable.
If the goal is to test the thought process why not give interviee a self-directed project then ask them to present a 10 minute talk about it? You get some code written to verify the engineer can build something, plus you get confirmation that they can organize their thoughts and effectively communicate them to another engineer.
Isn't that a more realistic scenario? How often do you give an (employed) engineer a task then ask them to immediately explain what they'll do to implement it?
Simple, I want them to work on the same topic as other engineers I've interviewed, so I can benchmark them against each other, and ensure the topic is close to what we work on, and not just what the candidate happens to know a lot about.
It is more realistic, but you can't really expect someone to be novel, and if they're not being novel, you should expect someone else to solve the problem. So this method has problems, and it kind of demands payment for results.
I'm confused by what you mean by self-directed. Would you give the person a specific problem to solve? Or would they be coming up with both the problem and the solution?
I think it's important to measure what's actually relevant to the job. If the job entails large periods of coding on the whiteboard, then yes, it's a perfect metric.
If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that.
Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.
When I do whiteboard interviews I want a little bit of code because I'm stunned by the number of people who can't write a loop. But mostly I want to see the design process. I ask for a simplified version of a real feature that has an algorithmic core. This lets us code something but lets us discuss all sorts of edge cases and real world complexities that would come up in a true deployment.
Lots of interviewers suck. That isn't a property of whiteboard interviews.
>I'm stunned by the number of people who can't write a loop
I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard.
Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another).
He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z.
Little by little, the code became more complex because he wanted iteration, etc.
He would say "I just want to know that you're able to code."
Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs.
If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.
The proof is: here we are talking about it.