Thanks for that, gonna look into The Expanse. Looks like it might be right up my alley.

Really enjoyed Peter F. Hamilton; read 'em all already and waiting for whatever's next.
Having said that, for sci-fi, my go-to author is Ian M. Banks. If you don't know his stuff, start with The Player of Games or The Algebraist. Either has a high likelihood of getting you hooked.

It's going to be a series on Syfy this year, hopefully they do a good job on it.

Just about every popular open source framework, language, and system we use today is extraordinarily complex and hardly done by one person, and very few were done without corporate backing, and very few gained traction without corporate backing.

Building an OOS project with the intention of writing a tutorial book is an awful strategy, IMO.

All true except the last one. I looked up some of the authors of the books I have and no surprise all of them have written at least one book on an open source project they contributed heavily towards.

Confirmation bias much?

Well, I could look to see what their favorite video game is but since that isn't related in the least to my original assertion I didn't see the point in posting that information?

I think it's interesting how wildly interview experiences can vary. At the company I started at late last year, my interview involved some whiteboard stuff (which I found very unnatural, my usual method of working through problems is stabbing at random code that doesn't solve it until my brain works through why it doesn't work and what would have to change in order for it to work) with a problem involving in-place data transformation. I figured out a good algorithm to solve it but in terms of writing out code to get the job done, was getting stuck in the mud on a few random details. In the course of solving that problem in an actual job environment it would hardly matter, but when you have only 30-60 minutes to solve something it could be a major impediment. Luckily, the guy interviewing me could tell that I understood the big picture and captured that as the important takeaway. In the months since then though it's funny to sometimes hear other engineers tell nightmare stories about people utterly failing at the problem in other interviews and wondering how close I was to being in that room with someone who might have been more concerned with the fact that I didn't ultimately come up with working code, even if I did grasp what the solution was.

The entire interview process though (which involved talking with a few different developers and solving a few different problems) was mostly focused on general programming problems. A lot of stuff at this company is new to me - everything's on Macs (which I had never used before), our source control is git (always used Perforce before), and I've had to get familiar with a lot of Unix type stuff. A couple months in, my manager (I use "manager" loosely, he's a programmer and the managing is mostly just in name/for organizational purposes) was talking about a guy he was interviewing to join our team, and apparently he asked him a ton of questions about Unix stuff, build processes and tools, and nitty-gritty kind of details. This guy, who I believe is pretty happy with my work so far since I joined, would have killed me had I interviewed with him!

Anyway, it's opened my eyes a little to how inexact the science is of finding qualified developers. It's very easy for me to see the potential ways in which my interview could have gone differently and I may have not even been hired for a job I'm doing very well at.

Yea there is a lot of luck involved with getting hired. Not sure how to solve that? Perhaps there needs to be a more standardized process.

Doesn't somebody have data yet on what types of interviews/hiring practices work best? I thought I recalled learning in college that IQ was actually a high predictor of performance (read a little bit just now and studies often support this but there's noise due to other factors that influence IQ, including "motivation" in the actual test-taking process) with normal "fit" type interviews being extremely bad. Facebook profile checks actually seem to be a really good predictor.

I would think there's some data on what works best for programmers as well...white board vs. perhaps coding on an actual machine, what types of problems to give (if any), types of questions to ask, value raw speed or efficiency or clarity of code or perseverance or ability to explain, etc. This shouldn't be rocket science.

It seems like a no-brainer that any large or mid-sized company, assuming they do not already have this "solved", should experiment and keep track of results. Hire some people who seem like they don't "fit" for example if they perform well on other metrics. Maybe the diversity will strengthen the company.

Hmmm... in that case, I wouldn't even exist.
Or maybe that would count in my favor?

It is a lot of work to build a framework, language, system, and failure is far more likely than success.

It is a lot of work to write a book, which most people can't do successfully.

Very few books sell well, even top-notch books on popular X have no guarantee of success.

The market for tech books is very small, so even if you end up with a best-seller, you aren't earning much, and probably doing worse than McDonalds wage if you combine the effort of making X then writing about X. We're talking about Django, not sex with vampires.

Fear not! I'm sure that, in 5 years time, employers will be able to search our shadow profiles.

(don't use facebook either).

Alright doctor, we see you've performed surgery on a large number of patients before, and they all give ringing endorsements, but before we hire you, we're going to test out your surgeon skills by making you play a game of Operation, just to see how your mind processes things.

You'd need a lot of hires to make a meaningful sample size and the cost of hiring someone that's not a fit is pretty high.

I can't imagine the cost of a study like this ever being worth it for a company.

Holy **** back to back 1/2 hour phone screens for my job leaves me with a splitting headache I never get from coding. Guess I found something else I'm bad at.

I'm with you. I find doing interviews exhausting.

I don't have a Facebook profile either.

Capers Jones is looked upon by many as a guru on metrics for various aspects of software development. He may have done some research on this topic, not sure.

While we're on the subject. My perception is that there is a fair amount of "blowback" regarding coding on a whiteboard in interviews. It isn't actually necessary if you want to have some candidate solve a programming problem in person. I view it as laziness. Since what is successful in finding a viable candidate is open to debate, I understand that an organization might believe they need to screen a candidate in such a way. It just isn't necessary to do so on a whiteboard. You can read various books on the interviewing and there are several that advocate practice using a whiteboard before the interview. So hypothetically with two candidates of similar ability, if one uses the whiteboard a lot more effectively than another candidate, then the person using the whiteboard effectively is the favorite. So basically the hiring decision is based a lot on how effectively someone uses a whiteboard. Earth to hiring team, that is ridiculous.

I can think of a lot of ways to probe for programming knowledge that doesn't involve a whiteboard. My impression is that this whiteboard method often seems to be relic from academic experiences. You had tests and homework assignments solving programming problems to evaluate a student's knowledge of a subject so just extend that idea to the interview process. Since a whiteboard is readily available just use it to observe.

You must be pretty young if your parents met via Facebook profile checks.

I'm on a conference call with 30 people who can't even pronounce their own names clear enough to be understood by an English speaker. This will go well. "Ok Mushmar, Vshnil, Ahoulring, Snrghlbargh..."

What are the configuration changes you anticipate needing before putting this into production?

"Yes"

I'm really good with Indian-english accents but some people I work with are really bad at it. Usually the Indian folks have the self-awareness to use abbreviations in cases such as that.

We have established that repurposed machines will be shown in purple. The repurpose color is purple. Moving on...

I interviewed 2 people for my position today and my god is it depressing. If you can't do the job, why bother applying? If you can't describe the essential parts of an HTML form, why bother pretending? If you don't know what the CSS box model is, or what a float/clear is, why apply for a job that requires strong CSS? If you can't coherently put together a jQuery event handler ("Use jQuery to turn an element blue on click" "um um um click().css('blue')?"), what makes you think you can do a senior front end developer position? GMAFB.

What's really sad is these 2 got through phone screens. I really need to rethink this whole process but christ is it painful. Oh well new job on Monday they probably won't want me to interview people... for a good month or so.

Yeah, it is strange huh? People have the resume, can answer basic questions, then totally bomb the interview. I can chalk part of it up to nerves, but I wonder if the person is just blowing it because they aren't interested or if they really thought they could lie to get in.

With us, you have to take a typing test and an Excel test, and its like "yeah, I can do macros, VBA, and know equations." They always fail the most basic things. "I type 40wpm" roughly translates to "I'm a hunt-and-pecker that types 15wpm with 70% accuracy."

I know and have known hunt and peckers who are great engineers.

One great quote "I type less, but more powerfully"

When your job demands a lot of typing and minimal thinking time, hunting and pecking isn't really an option.