How I ended up conducting successful tech interviews with just 1 question
nicolasbize.com
nicolasbize.com
I think it's totally unreasonable to expect that everyone spend every minute of their lives coding or to have some kind of deep, personal connection to the code they write.
This thinking is ridiculous, and doesn't really appear in any other industry. Do you care whether your accountant's idea of an enjoyable Friday night is sitting at home making more spreadsheets? Would you demand that your eye doctor go home and craft her own lenses in her garage for fun? Competency doesn't require fanaticism, and no employer should expect that their employees devote their entire lives to their occupation.
If I want to code for 8 or 10 hours a day, go home and enjoy myself in the little free time I do have, then wake up and do it again, I don't see why that makes me an inferior employee.
This just seems like more misguided, unjustified cultural absolutism that is so prevalent in the industry.
EDIT: For those saying that the article doesn't necessitate spending massive time outside of work writing code, the author clearly conflates the two. "i have always been convinced that those who love code do not restrict their coding activities to their work. they take home that love and continue to create for fun as a hobby." Personally, I think passion could be a valuable heuristic in hiring, but the author seemed to imply that passion is only measured by your willingness to work outside of your day job. At the very least, that seems to be his expectation of good candidates, and his hiring process clearly disadvantages people who can't or won't code 24/7.
Also, the question doesn't imply in any way that it has to be an off-work project. Its only point is to see if a person actually cared for any code they wrote in the past or if they treated coding just as means to an end.
The good part of the article stands, though. In a good programmer, there will be a spark, and he has the right idea about the interview question.
A perfectly valid way to respond to it would be to refer to something you did at work. "Oh boy, that's difficult because the code I've had to deal with has been legacy stuff that... well let me see, there was this big ball of mud where it took us a week to track down an intermittent bug, the debugger was useless... but after that, I figured out a way to put in logging code so we could at least see what was going on and we'd have a better chance next time..."
You're not looking for spare time programming or some particular answer. You're looking for a non-rote answer. You're looking for the spark.
If Nicolas Bize would accept that sort of thing, I think it's a good test. If not, yeah, it's problematic.
Edit: I've just asked him about it in comments under the original post.
No it doesn't.
I'm a guy who has the "two jobs" by your description. More precisely, it's a job and a hobby. However, my "best/coolest project/work" has always been something I have done for an employer. I can't imagine coming close to that "level" of work by just playing around at home.
If you can't answer the question in the post with a project that you've done at work, and you don't program as a hobby, you simply do not qualify for what OP is looking for.
The 9-6 stuff is rushed and designed by others.
“Oh! A few months ago I created a basic budget tool based on graph theory—so I can create 'branches' like in git, but for my personal budget, and then forecast how certain changes affect my budget overall. It really helped my wife and I visualize how certain decisions play into our plans over the next couple of years. Would you like to see how I implemented the recursive SQL lookups in ActiveRecord?”
I hacked out a basic MVP for the above in 4 hours one Sunday afternoon. I don't hack on side projects every Sunday, or even frequently: a lot of weekends I want to explore the city, sleep in, and work on projects around the house. But I love programming, and I love how software can affect our every day lives, and sometimes little itches like the above come up and I scratch them. And this one story would be more than enough to pass the author's test with flying colors, and is /nowhere near/ holding down two jobs.
What was the household budget in originally - a RDBMS? Mint or quicken ?
Not meaning to be aggressive - just wanting more context - and yes, please let me see code :-)
Actually, it does appear in other industries. Many of my friends who are designers do various sorts of art in their free-time, whether that's drawing or even the same type of photoshop stuff they do at work. One of the best CNC machinists that I know has come into the shop on weekends to experiment with making ornate snowflake ornaments, folding knives, and motorcycle attachments on the mills... His job consists of machining parts for cable laying machines, but he enjoys the challenge of figuring out how to manufacture complex parts so much that he does it in his free time.
I don't know any accountants or optometrists very well, but I wouldn't be surprised if the passionate ones spent time outside of work learning about the latest advancements in their respective fields.
> Competency doesn't require fanaticism, and no employer should expect that their employees devote their entire lives to their occupation.
True, _competency_ doesn't require fanaticism, but if you want to _excel_ at something (and don't want to end up hating your life in the process) you had better really enjoy it because you're going to have to put in several thousand hours of learning. Spending all that time exploring your particular field of study won't be a problem if it's something you love, and you're more likely to continue exploring it and keeping yourself up-to-date if you're interested in it. Thus, passion makes a pretty good predictor for success among high-achieving employees.
This is along the lines of what I was thinking.
If I'm looking for someone who is really passionate about what they do, they're probably going to be associated with it outside of their nine to five. This could be reading books, magazines, talking to people, participating in discussion boards, or trying to figure out problems.
That doesn't mean every employee is like that, or that you have to be like that to be a worthwhile employee, but it's not crazy to think that someone in almost every field will be actively involved in something related to their profession in their day to day, outside of work.
Even with accountants, you might not be doing someones books all the time, but you might have an active interest in financial news, forums, current scams, common mistakes, loopholes you could use, etc. etc. (I don't know anything about accounting; don't judge me :))
My grandmother was a corporate tax specialist for AT&T, she certainly seemed to enjoy doing her personal income taxes (and those of some of my uncles and aunts). This was way before Turbotax, Taxcut, and the variety of programs that have made it less unpleasant.
What is different about some other professions is that there are ways to develop that passion during apprenticeships or entry-level jobs while learning from those with greater experience. Mastery is far easier to acquire with a teacher on hand who can give timely, guided feedback and correction.
Very true. The only problem with that is that when judging between two job candidates, the one who is devoting their entire lives to their occupations is going to be a more desirable hire.
>At the very least, that seems to be his expectation of good candidates, and his hiring process clearly disadvantages people who can't or won't code 24/7.
Just as the field of competitive Olympians disadvantages people who can't or won't train 24/7
Also, there are only so many gold medalists every four years. In the IT industry, there's no theoretical upper bound, so it's not nearly as dire, you don't really "run out of slots" as fast.
If their company only hires once a year or so, that's still running out of slots quickly. The author works for an individual company, not "the IT industry".
Not true. The more productive and effective candidate is the more desirable hire.
Schedule and prioritize your work to align with business goals Interact with non-technical users and domain experts and understand their problems and techniques Work productively with and integrate your work with the work from related fields, like DBAs, designers, artists, etc Work with a team of developers productively, including making your ideas heard without being intolerant or offensive
That's stuff you don't tend to get from doing side projects. Maybe if you turned a side project into a real business, or were a senior contributor on a large, long-lived open-source project, or something like that.
Come to think of it, I was more sympathetic to the article's idea at first, but writing this makes me reconsider whether just having passion for something that you have built is enough to base hiring decisions on.
Well that is exactly the point.
The idea of some amazing "code monkey" detached from real life requirements, constraints and development timelines is a fiction and does not represent reality. The best developers have a deep understanding of the tools and the applications and it is that devotion that I am referencing.
There are in fact people that think in terms of building new things through code ALL THE TIME - and then implement them. Those people are going to have an advantage in the hiring process.
No, not at all.
You're assuming that "will you please tell me about the best project that you’ve ever created?" has the words "Outside your previous jobs" - which it clearly doesn't.
If you've made or contributed to something great at a previous job - talk about that!
As soon as I read that question I paused and thought about how I would answer it - of the 10 possibles I came up with, about 5 are "personal projects" and about 5 are "from previous paid jobs" - the thing about the paid jobs ones is that I get to talk about all the awesome people I got to work with, all the stuff they taught me, all the conflicts I had with that Project manager (!!), all the trade-offs we had to make so the project actually shipped, some of me reservations about so much technical debt being created, etc. etc.
There is absolutely nothing wrong with answering this question about something you were involved in at a previous job. The point is to find people that are passionate.
I'm incredibly proud of some independent projects, but they're definitely informed by my days working on million-dollar projects, some of which were pretty awesome.
And what if you were the guy that found a bug in a Mars rover? Sure, maintenance programming, but you still did something worth talking about.
And even maintenance programmers with a bit of initiative can do something interesting. "Well, I had to dynamically change the name of 20,000 functions in a project so I wrote a tool to do it automatically and went home early while the tool did the work". That's the quality the interviewer is looking for.
I want to work with people who have passion for what they do. You don't have to keep doing it when you get home at the end of the day, but if all you're doing this for is a paycheck and you aren't really passionate about what you're doing, I find it impacts the quality of the output and the speed with which you absorb new information.
This is not unrealistic in other professions as well, maybe just not as easily recognizable. I have friends who are Ad execs and love advertising as an art, they'll often discuss ideas they've had, things they've been thinking, etc. etc. which is outside the scope of their work. It may be the client they'd like to bring in and the ideas they have to improve that client's business, etc. etc. What about doctors who vicariously keep up on all the latest knowledge in their field and are actively collaborating with other doctors on discoveries and research (my sister does this as a veteranarian, and is also randomly helping people in the park on a Saturday morning who have questions about their pets, as well as doing a spot on the local news about caring for your pets). This is unpaid/hobby work, but it isn't as concrete as what we do, and therefore, people don't consider it.
We aren't the only group that is passionate about what we do, and we aren't the only one's who work on our craft outside of work hours.
I think a better way to take what the author is saying is that he is looking for people who look at software development as a craft, and people who are so passionate about it that they are constantly engaged in their craft even outside of work hours. They love what they do so much that they just can't stop.
At the same time, I think it is important for employers to recognize when and if they need somebody who meets this criteria.
I am reluctantly creating a side project at the moment, as I want to get into freelancing, and all my previous work is in house. Even without kids I find it difficult to find enough hours to put into it (trying to use a free hour here and there leads to almost zero productivity, I need a minimum of three at a time).
I've met several very brilliant programmers in my day that liked to work long, super-focused days on the problems they were presented with at work and then would go home and do anything but look at a computer. I'd be hesitant to suggest they had any lack of love for their chosen profession.
I don't think it's a bad thing if you don't aspire to "greatness" though. There's plenty of jobs where a decent, reliable programmer is perfectly fine. 49% of us are below average, after all.
The comparisons you've made are with non-creative fields. For those I know that work in other creative industries (graphic design, photography, music, theatre, copywriting), they almost always spend a good deal of their free time exploring their passion. If you love doing something, you probably won't be satisfied if the only time you get to do it is under the strict direction of another.
In any case, if there are enough candidates to select from, and you have no better way of determining which are the better candidates, why not choose the ones that code for fun in their free time over the ones that don't? Those candidates almost certainly have a passion for programming while the others it will be harder to tell. Plus those candidates will be constantly learning new skills that I as the employer will benefit from.
My own problem with the question is that I wouldn't know what to answer - I have too many things to choose from. Many are too far in the past to remember lots of details about.
I think the article author has a good point - in some cases. For a programmer working in a strict waterfall project, who's "just coding his allocated items of a per-determined feature list", passion might not be important (and may even be contra-indicated, they'll likely leave when they work it out). But if you need creativity from your coders, some level of passion in _something_ is important. I suspect if an interview candidate lighted up telling the story of their quadcopter or bamboo bicycle or burningman project or anything where they can demonstrate solving problems within a set of constraints - even if it didn't involve a single line of code - it would have been looked upon more favorably than somebody who can't demonstrate passion about _anything_.
The interview ended up being one of my best interview experiences though I turned down the job.
1) Hire all good candidates as well as a fairly large percentage of bad candidates.
2) Reject all bad candidates, and hire a fraction of the good candidates.
Which route a company takes generally depends on what the company needs. In this case it sounds like his company needed to minimize bad candidate hires more than find all good candidates.
So yes, what you said is correct. This approach will filter out a large number of great candidates without extra time, but assuming the company is finding enough candidates to hire, this isn't a problem they need to address.
I believe this is the same reason why many startups can get away with trial work periods and other interview tactics that large companies cannot. The number of candidates willing to do this is significantly smaller, but it is seemingly large enough for the startup using the tactic.
I suspect that until the industry finds a significantly better way to filter good/bad candidates that this will not change. So if you are looking for a startup idea - this is a great area to get into =D
All good programmers I know have at some point spent significant amount of their free time programming on their own, that's why they've become good programmers. They might have kids now or too much work, but I would be amazed to meet a good programmer that has only ever programmed at work.
Despite that the fact that I have kids and a job that does take its time, I do program as a hobby. It mostly kicks in when things are slow at work or when work is less about coding and more about something else as if I had a weekly or monthly coding quota that I need to fill in. But I do have the urge to write programs independent of my work -- if I'm lucky I can abuse my work to fulfill that urge.
All I want from a programming job is to get paid money to spend a lot of time with a computer writing software, and spending time with other humans strictly as needed to advance the computer project. I don't want to sit around a campfire (or water cooler) and trade stories, and I don't have a memory for things like "best bug" and other events people tell stories about. Unless at that event's particular moment I think "Maybe this bug (or whatever) would be good to use as an example for a future interview." and I make a reminder to add it to a file of such life events I review before interviews. It's one of a bunch of little things I have to do that some others don't, which sucks, but considering the whole messed up wasteland that is programmer interviews where pretty much everyone has to do a bunch of BS prep work unrelated to the actual job just to stand a chance, I don't think it's worth complaining much about. Hence the throwaway -- time to move on to other things.
What it won't get you is breadth of experience, operational background, full-stack thinking, or people who can look at somebody else's work and say "here are the ways in which that is going to blow up in your face, two years from now". (Anybody care to add to this list?)
If all you ever do is bootstrap new projects from nothing then maybe that's the sort of people you want to hire, but it's probably not enough to build a sustainable product.
I think the point of the question is to find people who are passionate about their profession (in this case programming).
Yes, a person with all of those things can answer this question. So can a person who doesn't, which is the point. Answering this question correctly cannot identify people with these highly desirable and uncommon skill sets, so the expected result of using it as your only interview test is to hire the most common subset of people that can pass it.
On further reflection, I have another objection to this interview approach. I would never work for this company because it fails my personal red-flag test of the hiring process: "Do I want to work with the worst imaginable person who could pass this interview?"
While it's true that if you simply look at the question as having a "correct" or "incorrect" answer then you'd be right. But this question most certainly can help identify someone who has those traits if those are what you're looking for. It is true, that there is a subjective quality to this question and it's a requirement that the interviewer be a skilled judge (where a simple technical quiz can be graded with a rubric).
And if an interviewee can not manage to cover those strengths in a length, open-ended discussion about their best work, it seems unlikely that any other specific questions would be any better.
My main concern with a question like this is that by focusing on the best things a candidate has done, it's harder to get an idea of how they might deal with less optimal situations.
On further reflection, I have another objection to this interview approach. I would never work for this company because it fails my personal red-flag test of the hiring process: "Do I want to work with the worst imaginable person who could pass this interview?"
This is another fallacy, as interviews with the vast majority of companies don't do "pass/fail," they sort a list and take the best fit.
...Or their initial screening heuristics are unusually bad and have to interview tons of candidates. Or maybe their recruiting process is really good at generating a high volume of sub-par applicants. Rejecting a lot of candidates after subjecting them (and current employees) to grueling interviews doesn't mean they're making good hiring decisions.
After we were done, the same page took less than a second - but the thing that would "light me up" was the process of finding the performance bottlenecks and gradually arriving at a better understanding of exactly why bizarre flaws existed in the way the old application configured the ORM (lack of experience by the original developers and most likely external consultants that told them that using an ORM was professional but not teaching them enough on how to work with it)
What it won't get you is breadth of experience, operational background, full-stack thinking, or
people who can look at somebody else's work and say "here are the ways in which that
is going to blow up in your face, two years from now". (Anybody care to add to this list?)
Arguably, passion for the work leads one to make more of the years of experience - ensuring it's "10 years of experience" vs " 1 year 10 times".
It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing?
I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project.
Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.
I don't think it's a particularly good open ended question for more experienced developers and an interview is not a camp fire circle... It could be part of an investigation in some past project, e.g. what problems did you have and how did you solve them...
I've started an initial push at Continuum to open source our interview questions... and this is the first question :-)
The question he arrived at is: “... will you please tell me about the best project that you’ve ever created?”
Then watch for enthusiasm and pay attention to the details. The goal seems to be to identify someone who really enjoyed and takes pride in a program they've written.
- created the most value for your employer even if it was a soul-sucking nightmare / merely maintenance project with no challenges.
- you learnt the most from it / overcame challenges you didn't know you could / came up with moonshot solutions to issues no one even realized were there.
Honestly, I doubt "most proud" versus "best" makes a difference at all. Candidates generally explain their answers to these open ended questions. If they (for some reason) don't recognize the implicit, "And why?" part of the question, you just follow up with it.
The conversation will never be just, "Foobaz, next question." One way or the other, it will be, "Foobaz because..." It saved the company $2M/year. Or users really loved it. Or it improved the engineering process and made releases faster and lower risk. Or it was a really tough problem that required a lot of creative thinking. Or it taught me a lot about 3D game programming.
The US has the most liberal/right wing/psychotic labour laws in the Western world, and as such the best approach is to hire anyone not an idiot and fire them once on the job experience teaches you if it's a good fit.
This results in massive turnover, and little incentive to improve the interview process
I'm not sure where I am going with this but I am amazed that the local labour laws are not mentioned on this three (afaik)
Hiring people is resource consuming and is always a large investment for a company. Unless you are hiring low-skill workers who can easily be replaced, a high-tech worker will require time before she's productive on the job. Those weeks/months, cost money and figuring out that someone is not working out after 3 months of investing in her could cost a lot more to the company than just the cost of re-hiring someone else.
It's always a better strategy to be diligent early and avoid wasting company resources just to shorten the hiring process.
That being said, being able to easily part ways with an employee is important for a company since the cost of taking a risk is much lower. In France, employers are very reluctant to take risks as they can get stuck with people who are either bad or don't fit in.
There is a middle ground between a system where you can fire people for any reason, whether related to their work or not, and a system where you can't even fire people who don't work out.
How long does it take to become obvious someone is not a good fit? A couple of hours? No, if humans could not fake it for a couple of hours no one would ever go on a date again.
A couple of days - maybe. My own pet theory is when I hit a new contract is to commit a bug fix by the end of the day and push to production by the end of the week.
But no one sane is willing to give a week to an interview, and few a whole day.
I think in the end we judge people by their public output - in other words GitHub reall is going to be our CV
And to the people saying that this necessitates projects outside of work - I don't see why it does. You can talk about school projects, projects from previous jobs, etc.
On the other hand, I wonder if it really produces results that are any better. At least, with a quiz, you can give it to current employees who work great, and discover the quiz turns out to be worthless. (As the author described.)
But with a open-ended question inviting open-ended answers, how can you tell if it's really working? Of the many coworkers I've had before, I can think of one who certainly would have aced the question -- a programmer through and through -- but who was fired after a few months due to poor work ethic and sloppiness. Because while he had enthusiasm for programming, he had no time for "standards" or "teams" or "business needs" -- things like commenting code, communicating well with others, following through on commitments, etc.
So I wonder if the author is going to discover, after a few more months, that there are a few more questions than just this 1 question that also matter just as much...
Before the interview, they told me they went through my Github and looked at my projects, and actually called me for an interview partly because of that. My Github served me as a portfolio. Artists have to hand in example of their work, and I believe programmers should do as well.
That should be enough to see most of those who don't comment enough, don't follow rules and standards, etc. It still comes back to the issue of having time to work on personal projects and having it displayed somewhere, but the same could be said for Artists.
[1] http://www.asktheheadhunter.com/articles.htm
[2] http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=...
[1] http://www.asktheheadhunter.com/habestinterviewquestion.htm
My current employer has candidates do a brief presentation about a project they are proud of. It's useful but imperfect (some people just aren't good at speaking to a group, which is okay for this job; some people aren't legally permitted to go into a lot of detail about their earlier projects).
The basics are: ask the candidate to describe a project they worked on (that they enjoyed, listed on their resume, or anything). Ask follow-up questions until you find out: the Goal of the project; their Role on the team; what Actions they personally took to reach the goal; whether the project Succeeded or not; and Speculation on what they would do differently in hindsight.
Repeat until they run out of projects to talk about, or you run out of time.
Show me some code from a project of yours and I will ask you to add a feature, fix a bug, or maintain it. The project can be something really simple. It is hard to learn new technologies without creating some kind of simple project.
This is a second interview, the first interview is by Skype to figure out the logistical/cultural fit, go over resume, and then spend some time talking through a technical issue.
This worked very well for my first hire. The downside of this approach, and a big reason it is not done is it requires an hour of preparation time for the interviewer to understand the candidate's code, run it, look for bugs, and figure out what to ask about. I think it is a much less arrogant way to conduct interviews though and a much more rewarding process for the candidate: they get to delve further into something they already have interest in.
Edit: ah, the almost mandatory third question: why do you want to leave the job you're currently having?
Did the author collect data once he perfected his technique. Is there data?
In my experience, the best tests have many questions, including "experimental" ones, because you want to be able to test your hypothesis against various data points.
I'm also not saying that everything needs do be quantified. Open ended questions are very useful. But why not at least collect the data and tally it to the best of your ability.
If you had asked me about it while I was working on it, and I didn't sugar coat, I bet you would have said no hire.
Secondly, it has just taken me 10 minutes to remember the details in enough depth to have a proper conversation about it. Again that would probably be "best work behind him...", or "doesn't seem to know the details....insincere" etc.
This question is easy to game and disadvantages people who aren't prepared for it.
You should have stuck with programming on the white board. That's the right way to find good programmers.
Am I missing something? What prevents people from other fields from having "personal projects" to be excited with?
I'm not saying you should stop capitalizing, mind you -- there's value in standardized orthography. But it's a good idea to set your horizon beyond it. I've noticed that I've become much more flexible and less dogmatic about things like this since looking at a bunch of other languages and writing systems and recognizing written communication as spectrum.
But the latin alphabet is apparently the most common alphabet. I don't really see your argument here.
As for modern Latin (Latin originally didn't have letter case, either; widespread use of letter case is a fairly recent development), most common doesn't mean best - how the "market share" of languages and writing systems evolves is a more complex topic (Nicholas Ostler's Empires of the Word: A Language History of the World is a good book). That means looking at and comparing with other examples is often useful.
It's a little like the reason you want to learn more than one programming language - it trains your ability to think about problems on a more abstract level than a single toolbox allows, and gives you insight into the strengths and weaknesses of each of your tools and how to apply them best. Even if you wind up only programming in a single language anyway. It also tends to make you less dogmatic and more willing to go back to first princples. Or willing to entertain notions like "just because this man isn't capitalizing his letters it doesn't necessarily mean he has nothing to tell me".
2nd-order cybernetics is about observing the observer, which includes observing the limitations of communication. Studying different languages helps identify the limitations of each, i.e the untranslateables. There's a great book on this topic (we need an equivalent for software), a 1300 page "Dictionary of Untranslateables".
http://www.washingtonpost.com/posteverything/wp/2014/07/16/h...
"This depends on what one means by “untranslatable.” Cassin and her team believe that an “untranslatable” word is not one that cannot be translated, but rather a word we can’t stop trying to translate, aware always that we haven’t quite hit it, that it isn’t right."
This is really more a social thing and about what the choice not to use capitalization communicates, i.e. you may be reacting negatively because you read it as a "I do not care to conform" or "I do not care about your appraisal of my writing" marker. Which is understandable, but I wonder if that isn't a too-quick judgement to serve as a rule.
So why the heck is not capitalizing your sentences ok? Language is a tool to communicate with the masses. We have rules and standards so everyone can understand them. If you can't do that effectively, then you have failed in your communication.
The two examples aren't the same, and the reasons a reader experiences discomfort reading your example text are different. They're about ergonomics. The erratic variations in letter footprints and the up-and-down-and-up from the ascender line to the x-height and back affect reading speed. It's also spurious; the capitalization style in your example doesn't add additional information.
Try giving some thought to capitalization along those lines. Does capitalization add information that otherwise isn't explicit? How does it affect reading speed?
The anwers are roughly "yes, sometimes" and "yes, sometimes" (the latter depends a lot on how you define "reading speed/performance"; "reading" decomposes into a set of different types of interacting with text, like searching, information/keyword retention, etc). You can call this a good case for capitalization, but I'm not convinced it's a given, and competing writing systems do get by well without it.
> We have rules and standards so everyone can understand them.
Sorta. "Understand" is a big topic to broach, see above. It's of course true that shared language and shared orthography enable sophisticated communication and grease its wheels. And in that light, not conforming may suggest an exclusionary attitude (just like e.g. excessive use of jargon can be motivated by tribalism). But it's not where I'd personally draw the line; I'd read a text rather than dismiss it beforehand based solely on a lack of capital letters.
> If you can't do that effectively, then you have failed in your communication.
The many other comments discussing the actual information content of the text seem to suggest that it hasn't.
Technically the (tiny, one-pixel) period is there, but personally I cue off capital letters rather than punctuation when dividing sentences in my head. They are also helpful when skimming. They provide easy-to-spot anchors at which to resume reading.
Seriously, just look at what I've written. Blur your eyes and slide over the text. You can see the capitol letters from a mile away, can't you? While the periods fade into the page.
Of course there's a complex interaction between letter and punctuation design there - if we didn't use capital letters, our full stop marks might be bigger instead. And perhaps that would be more elegant than having two versions of every letter. Now, that's of course a "what if ..." and not a practical argument that should affect your blog post today. (Nor is it an exhaustive argument, emphasized sentence beginnings aren't the same as emphasized sentence ends.)
But it's super-interesting that you bring up periods, because they're a great example of rules vs. the reality of written communication. The rules require ending sentences in periods, but a vast number of people start dropping them when the medium has an implicit full stop, like chats (IRC, SMS, ...) do (line/message end = full stop). Instead the period becomes repurposed as a sort of "aggression mark": http://www.newrepublic.com/article/115726/period-our-simples...
And the fact that we're discussing it here in this thread makes your point stand - it detracts from the message trying to be conveyed.