A week ago, a reader in China bought the 300th copy of JavaScript Interview Questions. In retrospect, that’s pretty good for a work-in-progress technical book with virtually zero marketing budget. The book is not even finished yet. By the time of this writing it has 46,033 words and298 pages, and there are still empty pages, incomplete sections, and drafts in it. I will come to that soon, but first let’s agree on the definition: “Self-publish” means that I did not have a publisher that helped me when writing JavaScript Interview Questions.
The book is not even finished yet. By the time of this writing it has 46,033 words and298 pages, and there are still empty pages, incomplete sections, and drafts in it. I will come to that soon, but first let’s agree on the definition: “Self-publish” means that I did not have a publisher that helped me when writing JavaScript Interview Questions.
But if I do not have a publisher…
- How do I manage the overall process?
- How do I communicate with the readers?
- How do I distribute the copies?
- How do I market my material?
- How do I get it reviewed?
- What tools do I use to actually author the book?
Those are some of the many questions that I receive regularly. In this post, I will try to clarify them, share my story and describe the types of challenges that I faced along the way. If you have any other questions just send me a convo, I will try to answer them all, and update this post accordingly.
Before we begin though, I want to clarify the most common misconception:
You don’t write a book to be famous.
Self-Publishing a Book Is not for the Fame
No matter how perfect, authentic, and unique it is; your book will not stand out. – Stephanie Meyer’s will. Yours won’t. Get over it.
Why? Because the odds are already against you. An average ebook on amazon will sell around 100 to 150 copies. Coincidentally enough, that’s the number of your of your friends, colleagues, relatives, and family combined, known as the Dunbar’s number.
So the hard truth is no one cares about your book. Your friends will seem interested, so that they can get free copies of your hard work, maybe.
Welcome… to the real world.
That’s why self-publishing a book is just like leading a startup (more on that below): In either case, the odds are brutally against you.
So Why Even Bother Writing at All?
So if it’s not fame, nor money? Then why write a book?
Well… everyone has their own reasons for this.
One of my reasons is the instant satisfaction I get when I share knowledge. If you are a blogger, you know what I mean: It doesn’t matter whether you have a single reader, or a million readers. You will have an ongoing thirst to write and share more.
Another reason is the incurable curiosity of mine:
I’m a geek, and I’m proud of it. In every aspect of my life, I want to dive deeper, and learn more. I urge to have a deep and solid understanding of a concept, before talking about it.
All these years what I’ve found is that simply doing extensive research and reading a lot on a subject matter is not enough to fully grok a concept. And I feel like the best way to learn something goes through actually teaching it.
Why? Because knowing that people will read your arguments pushes you to do more fact-findings, to be more rigorous, and to fully understand the idea you’re about to present. It switches your mind from being a consumer/memorizer to being athinker/analyzer.
Ever been to a code review? Then you’ll see what I mean.
I’ve realized that I learn a lot while I write. I would not have gained half of that knowledge if I were passively doing research.
Why Self-Publish?
Okay; there are reasons for someone to write a book. But why suffer all the pain to do everything yourself by self-publishing, rather than talking to a publisher and letting them do most of the legwork, so that you can focus solely on your writing?
The answer to this is simpler than the one above:
Self-publishing gives you more control over the content and design of the book.
You don’t want to fight to convince your publisher about why you present a chapter the way it is. You don’t have to convince them why the use of a technical term should be exactly the way you intended to be. And moreover, you don’t have to deal with a teenage intern, sending you editorial changes that you completely disagree with.
You have total control over your own content.
This freedom gives you great power. And as always, power is not without side effects.
Before coming to that, I want to share how my ebook adventure began, if you bear with me.
How It All Began
Due to reasons that are out of my control (startup bankruptcies, corporate strategy changes, layoffs, and so on) in the last couple of years I have been to at least a hundred technical interviews on JavaScript Engineering,Front-End Development, and related positions.
So it started with a layoff, and then I found myself preparing for the upcoming job interviews like crazy.
To prepare for those interviews, I had read a dozen of “technical programming interviews” books. That’s almost all of the candidates on the job market do, anyway.
And at a point of epiphany, two things smacked me right on the forehead:
- First and foremost what was written in most of those technical interview books were either ill advice, or extremely open to misinterpretation, or werwedownright wrong in so many levels.
- Secondly, although JavaScript was the most widely-adopted language in the known universe, and it was a skill that’s widely sought for, there was not a single technical interview book on JavaScript at all.
Let’s take a typical interview question, which almost all of those books have:
How do you balance a binary search tree?
… bah humbug!
To be honest, why on earth would I need to balance a BST? Even if I do need to balance one, I will google it. And I will not use a whiteboard to devise my algorithm. Whiteboards are extremely inefficient for compiling, debugging, and running code. If you ask me why I would use a binary search tree though, then we’re on to something.
Can you see how a virtual reality the interviewing setup is? Every step of the process is specially crafted to keep you out of the game.
Jokes aside, if acing your dream job was as easy as memorizing a set of questions and parroting them to the interviewer, then everybody would have done it.
Nobody Had a Clue
The sad thing I realized was, without having a single clue of what to do, candidates were constantly doing the wrong things, while expecting a positive outcome.
In deterministic systems, when you feed the system the same input, you always get the same output. Interviews, no matter how well-designed they are, are far from being deterministic.
And don’t get me started about the feedback mechanism. The only feedback you will get out of the process will generally be a “we will call you back later”. And either you get an offer, or they never call you back. In the latter case, you will never have any clue of what went wrong at all.
In the Land of the Blind…
It was that moment, when I realized almost everyone was doing it wrong:
Interviews were not something that one would be prepared overnight by memorizing a book. Moreover, it was not about the questions; it was all about the process.
You are not preparing for your CS101 final exam, you are getting ready to make a career shift. And memorizing questions is neither the correct, nor the most intelligent way of doing it.
In conjunction with all these, it suddenly appeared to me that most of the interview books were nothing but a to-be-memorized pile of definitions, Q&A, and brain teasers, along with lots of ill-advised suggestions on sensitive topics including “salary negotiations”, “how to deflect a question by asking a counter question”, “how to manipulate the interviewer to take control of the overall process” (hint: youcannot, and you should not), and the like.
Rather than giving the readers some HR Manager’s perspective on what interviews should look like, I aimed to hand over them the red pill and tell them what the JavaScript Engineering interviews really are, and what they will need to know to get the job they want.
With a belief that can I disrupt the status quo, and make a change, I rolled up my sleeves to write a book that teaches how to think.
Instead of forcing the reader memorize a set of rusted questions; I would be showing the most important parts of JavaScript and how they fit together in an interviewing context.
Long story short, I had a strong motivation to write the book. The next thing was to gather as much data as I could.
Collecting Materials
After having decided to write the book, the next thing was to gather resources.
Luckily, I was taking notes after every interview I attended to (an advice I took from one of my mentors, which worked out really well). I generally did it even before leaving the building, while my mind was still fresh.
I used those notes as an initial framework for the book. These notes were not only about the questions being asked, but were also about:
- What I did,
- Whether I have any moments of embarrassment,
- What I woul have done better, if given a second chance,
- What were my weaknesses, what were my strengths,
- How I expressed myself, how I should have expressed myself,
- If I were passionate enough, how I felt,
- Whether I believed that I was a match, if not, why? … and so on.
I noted down all the technical interview questions, too. Then I changed some of the technical questions to be put in the book due to NDA requirements, while trying to maintain the same difficulty and tone.
I also conducted an extensive research on the topics that I had been asked in the interviews.
After two months of initial preparation, I came up with a bibliography of more than 200 articles, tutorials, and websites, along with hundreds of draft manuscripts.
Then I organized all my references into logical pieces: chapters, sections, and subsections, resulting in a semi-organized knowledge, enough to write a series of books.
After having all the resources bundled together, the next thing was to seek a tool set to merge them into one coherent book; find a way to communicate with the audience of the book, figure out how to do sales and marketing, which I want to call as “My Setup” as a whole.
My Setup
For creating books and writing academic articles, two tools that are mostly suggested are Latex and Pandoc.
Both are excellent tools for ebook authoring. I even have a plan to publish another book using Pandoc as a learning experience. However, there are things about those tools that are not so appealing:
- They have a steeper learning curve;
- Part of the syntax is counter intuitive;
- And sometimes you find yourself type too much markup then writing actual text.
Being a geek, I love to play with new toys. That’s why I tried Latex and Pandoc for a while.
They were awesome. With one caveat: They were moving me away from my actual goal, i.e. writing the book, into the geekdom of learning and trying new and nerdy things.
That took me back to the “When in doubt, write the darn thing” rule that I’ll mention a few paragraphs below.
So instead of learning a new language just to write text, I chose a set of tools that I would feel comfortable and productive. The tools I used have changed over time. Here’s my current setup:
- sublime text (distraction free mode): For the initial manuscripts where I only focus on the text and not on the formatting (bold, italic, headings etc.), nor the presentation.
- iWork Pages: To bind the manuscripts as a book. It is monumentally better than MS Word. When I initially started writing the book in word, what I found was I started too much time reformatting code, and less time on the content – it simply did not work.
- slexy.org: For highlighting the source code (because iWork Pages does not have a source code highlight support by default, but you can copy and paste formatted code, and it works just fine.
- github: For maintaining the source code and tracking issues related to the book.
- PayPal: To track orders.
- A dedicated website: A site that only the readers can access, for them to download the updated copies of their books, along with any other items that I would be providing them.
- iMac Mailer: For managing my reader base, and sending monthly newsletters.
Creating a (private) github repository was the one of the best things I did to get organized:
- It was useful to keep track of the book’spublish cycles;
- It was a central hub for the readers to conveniently access the book’s source code;
- And, it created a medium to connect and exchange ideas with the book’s audience.
Not Having a Publisher Does not Mean You Are Free
Why? Because your community is your biggest publisher (we’ll come to that later). But apart from the book’s audience, you have another publisher very close to you: it isyou.
Treat yourself as if you are working with a publisher, because if you are self-publishing, by definition, you are the publisher.
Since nobody but you are the publisher, it means that the design, editing, proofing, marketing, distribution, and any other thing that you would do with a publisher is yourresponsibility.
It’s a hard job: You have to be highly motivated to create the best possible book. Also remember that you will need to sustain this motivation for a long time, to come up with the final version of your book. To stay motivated for such a long time:
- Make sure that you’ve chosen a subject that you are passionate about,
- And constantly engage and collaborate with your audience.
Do you see the similarity between having a startup, and self-publishing?
I’ll come to that later, too.
It Will Take a Lot Longer than You Think
After gathering raw data, and perfecting my publishing setup, I was pretty sure that I could finish the book in less than three months. I was completely and utterly wrong.
Writing a book is brutally hard; writing a technical book is harder; and it will cost you a lot of time.
If you good at time estimations (hint: most software engineers are not) multiply your initial estimate by three. If you don’t trust your time estimation skills, then multiply your initial estimate by five. Hitting version one of your book will take at least that amount of time, and possibly much longer.
The reason is simple: You are not a professional book-writer. You will be doing your writing on the off hours. And important life events will always interject your writing agenda.
For instance, your new job might require you to gather a new skillset and you might need to freeze contributing to the book until you gain those new skills; you might have a newborn baby who grabs your attention every time she’s awake; you might move to a new city, or a new country, or hell to a new continent!
I have been through all these and more in the last six months, and I can honestly say that it’s extremely hard to allocate time for a book during life’s ups and downs.
If do not see your book as your startup, then don’t even bother writing it at all. You will not be able to survive to the end of it.
If, and only if, your book is your startup; that is to say, it’s the most important thing that motivates you all the time, you will find time for it.
You Will Have Show Stoppers
Related to the former topic; it’s impossible to stay motivated, focused, and productive at all times.
You will have distractions.
In any side project that takes more than a few months, you need to have a clear set of guidelines to keep you on track. You need to have a ninja focus.
In addition to your fluctuating motivation and passion levels, you will also haveobstacles along the way: Some of them will be technical (such as how to format the source code, and how to choose the correct type face), and some of these problems will be behavioral (like how to stay focused, how to prioritize).
To overcome those obstacles carve the following three rules to the back of your minds:
Rule #1: Form Follows Function
Or content comes first.
The irony to design a great user interface is that you don’t think about the interface at all; instead you try to understand the user’s intentions, motivations, and tasks.
Why should it be different when you write a book?
Don’t worry about how to present your content. You will have plenty of time to decide about that. Once you focus on the structure only, presentation of it will turn out to be much better.
Besides, your book will evolve in time: You will need to add sections, remove sections merge sections, combine several sections into chapters…Don’t worry about them from the day one. It will paralyze you. The more material you have, the better idea you will have about how to present it.
If there’s only one thing that you should focus it should be writing:
Writing as much as you can.
When in doubt, write the darn thing. Worrying about styling, formatting, and presentation is a synonym for procrastination.
Rule #2: Share Early, Share Often
Just because you will be self-publishing does not mean that you won’t have any publishers. Your community (i.e. the readers of your book) is your publisher. They will be deciding the quality of your book; they will be giving feedback about it, and theywill be suggesting corrections and improvements.
Ask for your readers’ feedbacks. Revise your book; make corrections and editions based on those feedbacks. You can use those feedbacks later as “testimonials”, too.
Since you have nothing but your community, treat them well. And one way of treating them well is to regularly provide them with new material.
In my case “new material” is monthly newsletters, and monthly updates, new chapters, new drafts, and updated source-code. Those who opt in to be “editors” receive even more frequent copies.
Rule #3: Perfection is Boring; Laugh at It
Do not deal with problems you don’t have.
Believe in yourself, and be your biggest fan!
Declare a war on perfection; laugh at it. It’s boring and it keeps you from getting things done. If you are not producing any useful output for the sake of making things perfect, you are only fooling yourself.
Accept everything is constantly and continually in a draft mode, it helps to get it done.
Done is the engine of more; done is better than perfect.
This war on perfection also supports the “share early, share often”, and “write as much as you can; worry about the presentation later” guidelines.
Do you see how these rules relate to each other, and how they foster one another? It’s like the MVC of self-publishing. Without them you’ll have a hard time. Learn them by heart, and stick to them, always.
Building a Community is Harder Than You Think
By now, you are well aware that your readers are your community. You have to keep a bi-directional open channel to them; talk to them, and listen to them.
In deed, creating a community is really hard: If you have a group of readers who proactively respond to what you share with them, and give their valuable feedback, and support; then you’ve “done something”. And that “something” is not a community. It’s an “audience” at best.
Constantly think how you can turn your audience into a community.
The difference between an “audience” and a “community” is not merely semantic: A “community” is a living and breathing entity. Members of a community engageandbuild relationships with each other; they support one another.
The fact is there’s a tipping point, or an accumulation point, or a threshold number where your audience starts to become a community. Honestly, I’m not quite there yet.
If your book is going to be the hub for a major breakthrough; it should have a potential to establish a strong sense of community. If not, why bother writing it in the first place?
I’m an engineer (as well as a social media enthusiast). So if there’s a requirement; the first thing I would do will be to specify the elements of that requirement.
A “community” revolves around these element:
- Membership (or fulfillment of being a member of something);
- Influence (or the self-confidence in the belief that you can be a part of something and have influence on a bigger scale);
- Integration;
- Fulfillment of needs;
- And a shared emotional connection.
I just want to elaborate on the most important, and often overlooked element: “establishing and fostering an emotional connection”:
Great communities feel a sense of connection through a shared state of mind. They rotate and oscillate with similar emotional frequencies.
One way to create a shared emotional state is through creating an epic, or a shared history, that the community can get their hands on, and take possessions of.
- Frequently sharing ideas;
- Increasing the quality of interactions;
- And living (and creating) a set of experiences that members can gladly share with everyone else around them…
is the only ways to sustain the emotional connection.
All of which begets the question of “What a community is not?”:
Your Facebook Friends are not Your Community
I’ve dived into this much detail to underline the fact that community creation is not as easy as it seems.
Don’t force it. An organic-growing, closely-know, niche community is the most enduring one.
That’s why I intentionally, and purposefully, do not try to reach everyone. Target a “narrowed down”, elite audience whom you know for sure will learn from you, and add value to you.
Do not focus on building the community first. Focus on what you know best: “Writing the darn thing”.
One may argue “Build it first, and they will come” is a cliché; and clichés exist for a reason.
That’s a long reasoning why I haven’t added any social media buttons at all to the book’s site. That’s because my Facebook friends is not my community, nor is my twitter audience. At least most of them are not.
Social Media is Overrated
Here is the hard truth about social media management: it’s an oxymoron:
Social media cannot be managed, it’s saturated, and it’s overrated. Social media “manager”s who think they can “manage” social media are in a massive delusion.
Social media stems from the liberty, democracy, and wisdom of the crowds. It logically follows that “manageability” is against the very definition of it.
You cannot trust a fad, so the only reliable way is foster your community is do it the hard way: provide something of real value.
Even if your audience is ten people, treat them as a community. Engage with them, answer to their questions, probe their feedback, add value to them, and listen to them.
Your time and attention is limited, give them to those who deserve most.
Your core objective should be providing value, not promoting value.
Everyone will be famous for fifteen minutes. Going on the top page of Hacker News is overnight fame, and it will fade away in less than a week. Building a community is freaking hard work, and it will take years. Not everyone has stomach for that.
How to market your book is a non-issue. If you know that there’s a market for your book, and you can create an awesome book to beat the competition, and you have avalue proposition that no one else has, which can make you stand out anddifferentiate, do not bother marketing your book right now.
Remember? Do not deal with problems that you don’t have.
Your Book is Your Name, Treat it That Way
In the end, always remember that the way you market your book is a direct reflection of your name. And your name is your brand. In other words, if you spam others to promote your book, then that’s what you will add up to.
There is no sustainable business in spam. Do things the hard way, you’ll see that the attention to your book will, no matter how gradually it will be, snowball.
Your Book is Your Startup
What I have learned from this ongoing book-creation hassle is that books are like startups: You create a lot, you pivot a lot.
An as in every startup, it all begins with the idea that “you can be the change”.
By having a startup, you’re also an entrepreneur by definition, too. Don’t you feel your book, your idea, and your vision will stand out in the crowd? (If you don’t stand out, go home and come up with a new book idea.)
You are everything, the publisher, the copywriter, the technical reviewer, and the marketer.
Nobody has time for all these. Delegate as much of it to the community.
Being a Startup has its Benefits too
Everybody knows what a pain in the rear founding a startup is:
Being responsible for anything and everything of your product is like kind of a “torture”. On the contrary, nobody can deny the appeal of it: You are the master commander; you are on top of everything; when you succeed you feel legendary.
Actually, it’s not the success that makes startups appealing. It’s the instinct that you can be better, you can challenge the status quo, you can make a change, and you can be bigger than yourself. Otherwise it’d be plain stupid to dive into an industry that has 75% chance of failing. It’s not the success; it’s the experience that’s important:
Given that there are virtually zero barriers to entry, the chances of your book being successful is even lower than the success rate of a VC-backed start-up.
Conclusion
My starting point in JavaScript Interview Questions was the idea that “all those so-called ‘interview questions’ that people were forced to memorize so that they can trick the interviewer to get a job, was a complete nonsense”. Then I ended up creating a solid path to walk for those who really want to ace an interview.
I had empirical evidence that what the majority of the people were thinking about the interviews was wrong. What I had experienced during hundreds of interviews that I had been to supported that evidence. And I felt that by pointing out the elephant in the interviewing room, I could make an impact.
Do you know how to do something better than anyone else in the world? How would you let the world know about it? By writing a book, maybe?
Write a book, tell authentic stories. Make them as sexy as possible.
If you have read this far; then I assume you still have a passion, or an interest to write a book.
I’m not sure if your book will sell millions; I wholeheartedly wish it will. What I know, though, is that your book will change you, and it will make you stand out:
Writing a book makes you an expert in your field. At the very least, when you hand someone a book you wrote, it’s more impressive than handing a business card. Not only, it shows that you have enough expertise to write the book, it also shows you value the relationship with them enough that you are willing to give them something that’s dearly yours. Something you created.
You can’t say that you don’t have time because… whatever… you have a job to do, you’re running a business, you have to study your classes… so freaking what!
You don’t have time. You make time.
Good luck in your new book. And until then…
may the odds be ever in your favor.
