
How I ended up conducting successful tech interviews with just 1 question - bubblicious
http://www.nicolasbize.com/blog/how-i-ended-up-conducting-the-most-successful-technical-interviews-with-a-single-question/
======
ruswick
The problem is that this method disproportionately hurts people who don't have
the time or energy to effectively hold two jobs (one full-time position at
their day job and one as an independent developer or open-source contributor
by night) because of family, friends, or some other facet of life beyond their
laptop.

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.

~~~
slang800
> 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?

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.

~~~
doorhammer
> True, _competency_ doesn't require fanaticism, but if you want to _excel_ at
> something

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 :))

------
asuffield
The flaw in this method is that it assumes there is only one kind of
developer: the lone architect, who builds fine tents out of whatever is lying
on the ground and then departs.

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.

~~~
Goladus
I don't think that question precludes all of those things. Anyone who is a
"full-stack thinker" with broad experience should have at least one project in
their past where they created something they're proud of.

~~~
asuffield
I'm just going to pick one person to reply to at random since there seem to be
half a dozen comments misunderstanding the same thing...

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?"

~~~
Goladus
_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._

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.

~~~
asuffield
Without exception, my experience of hiring in small companies has been that
there isn't a "list" of plausible candidates, there's a series of interviews
that go on for months, rejecting hundreds of candidates, until you finally
find a good one. So I don't really buy into the "sort a list" idea. Maybe the
companies I've worked for have all been unusually picky about hiring, it's
hard to tell, but I'm pretty sure I wouldn't want to work for a company that
wasn't rejecting at this rate.

~~~
Goladus
_Maybe the companies I 've worked for have all been unusually picky about
hiring_

...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.

------
kabdib
One of my favorite questions is, "Tell me about the best bug you've ever
found."

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.

~~~
YZF
I think when you're just starting that first race condition or memory
management issue are exciting. After a while it's not that exciting any more.
I got asked that question and the first thing that popped to my mind was a
very unexciting bug I was chasing in legacy code I was maintaining. I don't
think the interviewer liked that answer because it was mostly grunt work and
not some some amazing feat of engineering.

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...

------
randomfool
In these free-form discussions I find it really important to politely disagree
with some technical decision of their project to see how they take the
feedback and defend the decision. Red flags are when they either cannot accept
disagreement or come up with questionable justifications. Correct answers
include clear explanations of what the trade-offs would be and clear rationale
for their original decision process.

~~~
clairity
this is a good point. one developer i hired had the spark but not the maturity
to deal with disagreement objectively. he has trouble communicating and
working with others. he has potential, so i'm hoping he grows out of it over
time.

------
Goladus
tl;dr:

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.

~~~
wildpeaks
The _" project you're the most proud of"_ might be a more precise way to
phrase it because _" best project"_ could mean either:

\- 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.

~~~
spoondan
People can be proud of either of those accomplishments as well.

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.

------
lifeisstillgood
Everyone seems to have missed the most important part of the article "this was
in France, and you can't just fire someone so if you hire badly you are stuck
with that person forever"

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)

~~~
Renaud
Even in the US, where labour laws generally don't favour the worker, it
wouldn't make much sense to set the bar too low and count on being able to
fire people to eventually get the right one.

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.

~~~
lifeisstillgood
Tokenadult has a regular post that has grown to the size of a small essay
which basically says the only way to tell if someone can do the job is to give
them the job to do.

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

------
xur17
From an interviewee's perspective, these are my favorite interviews too. I get
to talk about something that interests me, and have a discussion about the
different decisions I made. If the interviewer wants, they can dig into
specific details, or ask more pointed questions about the programming
language. I find trivia questions off-putting, and tend to limit the depth of
discussion into my skills.

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.

------
warcher
It's always surprising how often interviewers fall back on "API Jeopardy" when
trying to make hiring decisions. Maybe it's just because my career hasn't
really allowed the luxury of getting deep on any technical stack and staying
there, but I just don't keep the details of obscure function calls in my head
all the time. And I have to wonder at the utility of testing a developer on
having memorized the kinds of things that they will always, ALWAYS be able to
look up when they're actually working.

------
crazygringo
On the one hand, this resonates with me... the last time I was doing a round
of interviewing (being interviewed at several companies), one person asked
this question -- and it was the one point when I really "lit up" and really
enjoyed being interviewed.

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...

~~~
bubblicious
To answer your question, I worked for another year for that company and must
have done about 100 interviews with that method. It wasn't perfect, but I
found that it gave better results than the other stuff I had tried. Also, I
found that the more I would bring the person in his comfort zone, the better
appreciation I had for their qualities as a programmer. Also, that one
question would always lead to a 30 minute discussion about their project
(hobby or work). I would of course ask a bunch of other questions, but it was
on the things they were the most comfortable with. I didn't have to ask them
if they knew this or that, they would tell me all that they knew and we would
discuss it. And wherever there was excitement, there was an indication of a
good hire.

------
cottonseed
The best advice I've seen on how to structure an interview came from Nick
Corcodilos of Ask the Headhunter [1] fame, from his book Reinventing the
Interview to Win the Job [2]. If you want to show someone you can do the job
(or see if they can do the job), do the job, or as close as you can get to it
in an interview setting. Anything will be selecting for indicators that will
be more or less correlated with job performance.

[1]
[http://www.asktheheadhunter.com/articles.htm](http://www.asktheheadhunter.com/articles.htm)

[2]
[http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=...](http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0452278015&linkCode=as2&tag=wwwonebadseec-20&linkId=OBQZTIGOSOWYFUSZ)

~~~
cottonseed
Coincidentally, the most recent Ask the Headhunter article [1] is "The Single
Best Interview Question... And The Best Answer". Hint: It isn't about your
hobby project.

[1]
[http://www.asktheheadhunter.com/habestinterviewquestion.htm](http://www.asktheheadhunter.com/habestinterviewquestion.htm)

~~~
djur
This is specifically about technical interviews as one of several steps,
though. "What is your plan for being effective in this job" is the kind of
question that, in the OP's three-step interview, should be asked by the
manager.

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).

------
falsedan
I like a more structured technique called GRASS, described in Ovid's 'Agile
Companies go P.O.P.' presentation:
[http://www.slideshare.net/Ovid/a-14058644/22](http://www.slideshare.net/Ovid/a-14058644/22)

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.

------
gregwebs
Others have noted that the best way to interview is to see if someone can do
the job is to have them do the job or the closest thing to it. For the typical
developer not available for freelance I combine this approach with the
approach in the article.

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.

------
nwhitehead
If you are limited to one short question, a better choice is to ask them:
"Teach me something technical you've learned recently." You can evaluate their
answer on technical depth and correctness, communication skills, and
timeliness of the topic. And if they can't think of anything they've learned
recently, that tells you something as well.

~~~
dpark
I suspect you're largely filtering for people who are aggressively
interviewing. When I'm deep into a meaningful project, I spend less time
learning interesting technical bits. When I'm looking for a new job, I spend a
lot of time learning random things that might be useful as a clever answer in
an interview (because that's what so many interviewers want).

------
dzink
To add on to the "Tell me about a project you are most proud of?" question,
having gone through different stages from burnout to re-kindling of the hacker
within, I can see it measures attitude well, which is crucial. For aptitude,
however I would go a few layers deeper. "What was the toughest problem you
have worked on or solved?", "How did you solve it?", "What did you learn?" the
choices of problems tell you as much if not more than the answers about where
the candidate's passion stands. Are they vague or specific? Do they use
industry terms or are they self taught? What types of issues make their eyes
spark? etc. If you are hiring entry level people, passion is most important,
but if you need to have people who hit the ground running in an area, nothing
beats a nice rigorous interview, with some code writing involved, in addition
to your question.

------
kika
That's almost exactly what I was doing for years. Two differences: 1\. I
sometimes ask 1-2 technical questions, for example if the candidate claims
exceptional knowledge of some important (for us) technology, but his/her
resume doesn't show extensive use of it. Like: "You say you know CouchDB
inside out, but you've used it only once and not for long, interesting.... Can
you tell me how the _changes feed works - if I listen on this feed do I get
just the changed documents IDs or whole documents?" 2\. Instead of "what's
your best project" I ask more aggressive question - "imagine I give you 1
million dollars right now and in return I want to be a part of what you use it
for - a share of profits, credits in the movie, etc. What would you do?".

Edit: ah, the almost mandatory third question: why do you want to leave the
job you're currently having?

------
zeroonetwothree
It seems that every week there's a post on HN about the "right way" to do
interviews. It's too bad there's never any research done to actually test
these strategies. I don't believe that you can get a good answer just from
personal experience.

------
coldcode
Thank you, finally someone who gets the idea. Though I like to ask two
questions, one the best project you ever worked on, one the worst project you
ever worked on. You can learn a lot about a programmer by the details they
relate in both cases.

~~~
chippy
ooh, that is a good one! I wonder if some people would mention the same
project?

------
dj-wonk
I really hope that the magic question is useful, and I agree that many
boilerplate Java-specific questions are misguided and less useful. Still, but
I find it unwise to bet everything on one question.

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.

------
fillskills
In addition to hiring people passionate about coding, I have found out that
anyone who is really passionate about something (music/surfing/rock climbing
etc) is a good programmer. Some of the best programmers I worked with were
either crazy about programming or passionately followed through with something
else in their lives. The key being that they followed through with their
passion. Has anyone else seen this? Or is my data too limited to my personal
experience

------
sheepmullet
My best project was 12 years ago and I hated it at the time.

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.

~~~
sumedh
If you know body language you can figure out if the candidate is honest or
lying.

------
rbobby
Shows up to the interview and then spends 5-10 minutes quietly reading the
candidate's resume and making notes. Not very courteous and makes for an awful
first impression.

~~~
vehementi
Said commenting, not silently reading. "Ok you worked here... and here... you
worked on this? Ok..." without saying "explain your work here" etc.

------
nardi
The real problem with this style of interview question is that it is good for
those who talk well, and bad for those who don't talk well. I have seen my
fair share of candidates who are great talkers, but can't code for crap. The
interviewers who didn't ask coding questions loved them, but those of us who
made them code knew they sucked.

You should have stuck with programming on the white board. That's the right
way to find good programmers.

------
danmaz74
The "tell me about your best project" question is great, but I always combined
it with one apparently simple programming question, like giving the quadrant
from the (x,y) coordinates. Maybe the OP is able to understand how logic-
minded his candidates were just from talking, but many times I was
disappointed from the actual ability to write down some code (even discounting
the stress of the situation).

------
fiatjaf
I see this kind of passion about personal projects and excitements about doing
something only in the programming field, maybe some other fields, but never
fields like dentistry or civil engineering.

Am I missing something? What prevents people from other fields from having
"personal projects" to be excited with?

------
rdtsc
Ok this is good. I have been facing the same problem. I did fizzbuzz, we have
the quiz I also often ask about he "favorite" or most challenging "project",
but I don't dwell enough on it. But now I think I should. I like this, I will
have to steal this idea.

------
chazu
Great article. Despite the comments decrying this 'one question' as unfair, I
think we can all agree that having a real passion for programming is the
single most important thing in making it from nooblet to competent and
confident developer.

------
cportela
I'm fairly certain I can't pass this test even though I've tried. Just haven't
had the skills yet for what I want to make and the stuff I've made doesn't
impress the people I want to be with.

------
recalibrator
TL;DR _Please tell me about the best project that you’ve ever created_

------
ScottBurson
I like to ask a variant of this: "what's the most interesting project you've
done?" If they come back with something that impresses me, I take that as a
good sign.

------
Tomis02
Give it a couple of months, it will start not feeling right again.

------
capkutay
With all the APIs and frameworks that make churning out good looking, usable
apps a relatively simple process, I don't think this is a good question by
itself.

------
netforay
My interview question was similar "What is the biggest program you have ever
written" (As I hire only freshers). Problem is, not even 1% seems to pass this
test. For those who are talented but lazy till now, I offered another choice,
or "Can you do me a small Snake game now"?

------
reality_czech
Everyone knows that the only question you need to ask is "how is this an
issue?"

[http://27bslash6.com/interviews.html](http://27bslash6.com/interviews.html)

------
insaneirish
I can't take seriously someone who doesn't capitalize letters appropriately.

~~~
sho_hn
Most alphabets don't have letter case. Its utility particular in written
English is questionable at best.

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.

~~~
insaneirish
He or she is writing in English. English has rules. Some rules are made to be
broken. Capitalization is not one of them when it comes to writing coherent
prose.

~~~
sho_hn
I disagree. I think the bar is "does this text accurately convey the intended
meaning and is comfortable to read?", and I think it's interesting and worth
thinking about that written English largely still meets that bar when you
remove capitalization. Capizalization _mostly_ doesn't encode significant
additional information (yes, there are counter-examples - the article we're
talking about actually does capitalize acronyms) or enhances ergonomics all
that much.

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.

~~~
xux
Nah DuDE if I wrItE liKE thIS DO u AUdoMAticalYLY geT annoyINgED? Yes.

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.

~~~
sho_hn
> So why the heck is not capitalizing your sentences ok?

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.

~~~
sliverstorm
_Does capitalization add information that otherwise isn 't explicit?_

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.

~~~
sho_hn
Aye, that's one of the things in capitalization's pro-column (it's what I
meant with "searching" in there).

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...](http://www.newrepublic.com/article/115726/period-our-simplest-
punctuation-mark-has-become-sign-anger)

