Have Your Say on Hacker Noon's Submission Guidelines


If there’s one thing I’ve learned about Hacker Noon in my first 30 days on the editorial team, it’s that the organizing principle guiding the development of this platform is prioritizing the views of its contributors and community, above all else.

In that spirit: we thought we’d make our first stab at defining submission guidelines open for community input - please scroll down to check them out, and let us know what you think!

Here’s a link to the Google Doc if you’d like to add comments to specific sections: https://docs.google.com/document/d/1XfgCHnRe1fiSuBS6iHzG6_A8GTizP6JTraypXjT18pA/edit?usp=sharing

How to Get Published on Hacker Noon

Hacker Noon is an independent tech blog - built on a worldwide contributor network of honest, unfettered stories and opinions written by real tech professionals - with:

  • 7,000+ contributing writers,
  • 200,000+ daily visitors,
  • 8,000,000+ monthly pageviews
  • 1,000+ Shareholders
  • 28 million users in 2018 alone

Hacker Noon is the best place for tech professionals to publish.

Most of our 7,000+ writers work in tech.

They write about how they do they job: what they’re building, why it’s cool, and how exactly they’re building it.

Three entry-level editorial guidelines you can immediate assume off the back of that assertion:

1. Don’t Be Afraid to Write in the First Person (‘I’)

Tell your story. Leave the pronoun ‘we’ at home, because only branded content should come from an celestial-sounding conglomerate.

2. Write about Technology (how its made, what its impact is, and why it could change the world)

While tech is a topic that infiltrates all industries and people from all walks of life, we still receive a fair amount of high-quality content that has nothing to do with the tech industry.

When in doubt, refer to the tags you’ll find attached the top stories featured on our homepage:

- links to all of the below tag pages are included the Google Doc: https://docs.google.com/document/d/1XfgCHnRe1fiSuBS6iHzG6_A8GTizP6JTraypXjT18pA/edit?usp=sharing

  • Agile
  • Architecture
  • Artificial Intelligence
  • Automation
  • Big Data
  • Bitcoin
  • Blockchain
  • Books
  • Cryptocurrency
  • Cybersecurity
  • Data Science
  • Deepfakes
  • Deep Learning
  • Design
  • Economics
  • Engineering
  • Entrepreneurship
  • Facebook
  • Future
  • Hacking
  • Google
  • ICO
  • Investing
  • JavaScript
  • Learning
  • Machine Learning
  • Marketing
  • Management
  • Motivation
  • Network
  • Nodejs
  • Pitching
  • Privacy
  • Productivity
  • Programming
  • Python
  • Robotics
  • Scaling
  • Security
  • Software Development
  • Startup
  • Technology
  • Tools
  • User Experience
  • Venture Capital
  • Vim

3. Write something that hasn’t been written before

The Hacker Noon audience is diverse. It includes everything from data scientists and developers to driverless vehicle engineers.

To hit up the homepage at Hacker Noon, you’re going to need to search for the freshest possible angle on your chosen topic.

Do your research, then ask yourself:

  • What’s the larger narrative around this space?
  • How might the Hacker Noon audience already feel about it?
  • What are the contentious or challenging issues worthy of deeper analysis here?
  • What is my unique point of view on this topic?
  • How might my own anecdotal experience in the industry provide a new point from which to start a conversation?

Hacker Noon is a place where people actually read.

One of the most exciting features of Hacker Noon 2.0 (coming soon!) is that too easily gamed ‘claps’ won’t count for much.

Our critical number when it comes to deciding which stories make it to the high-visitor-volume homepage?

Read Time.

How many minutes, hours, and days have people spent actually reading your words?
That’s the information we want to publically provide, for the benefit of both our writers and readers.

Which begs the question, what makes a highly readable article?

Craft a killer headline

_Even today you can look through almost any consumer or professional publication and find headlines that possess not a single one of the necessary qualities, such as self-interest, news, or curiosity. _
– John Caples

When writing headlines, I find it helpful to drown out the pressure of appealing to an audience of 200,000+, and instead imagine I’ll be sending my article to just one person: a friend, a colleague, a mentor; someone who matches the persona of the audience I’m trying to reach.

If - for even a second - I can imagine that one person thinking “So what?” in response to my title, I know I haven’t yet hit the proverbial nail on the head.

Once you’ve landed on a headline you think will speak to your intended reader both mentally and emotionally, run through the following checklist:

  • Is my headline 80 characters or less?
  • Is My Headline Written in Title Case? And if not, is there a good reason for it?
  • Is my headline an accurate reflection of the content that follows?
  • If I saw this headline on Twitter, would I click through?
  • Could this headline be construed as clickbait? (If yes - rewrite immediately.)

Use images and media to add real value

Your featured image is worth 1,000 words, so to speak. With how social networks work today, the featured image is the second headline.

Never submit an article without at least one image.

For bonus points:

  • Original image preferred
  • But also unsplash, pexels, pixabay + lunapic is option (why not use lunapic to Greenify your image while you’re at it?)
  • Use graphs or infographics to capture attention and add educational merit
  • Embed a relevant video or two to include a variety of voices on your topic
  • Break up lengthy sections of text with media to make for easier reading

Remember: easy reading = challenging writing

Bad writing is easy AF. Good writing requires time, revision, and spell check.

You can generally judge the strength of any piece of work by how a writer approaches their introductory paragraph:

  • Does the first paragraph set up a burning question that leaves you completely incapable of not reading further?
  • Is it clear from the introductory paragraph what you can expect to learn in this article?
  • Are their any careless spelling mistakes, typos, or grammatical errors?
  • Are sentences so long I lose track of the original thought before I get to the full stop?
  • Is there any evidence of blatant punctuation abuse…!!!

The objective of every sentence you write is to entice your reader into reading the next one.

Take the time to consider each and every line of your article through that lens.

Share your sources, as well as your own credentials

All great work builds on what came before it: don’t be shy to share and attribute the wisdom you’ve gained from other great writers and thinkers.

And, when setting the scene for why your point of view is one worth considering, be sure to include one or two lines on who you are and what you’re about.

Remember, Hacker Noon stands for real stories, written by real tech professionals.

We will always value first person perspective over breaking news.

Format beautifully

Respect your readers: use paragraphs, subheadings, and bulleted or numbered lists to structure your work for maximum readability.

Also: make links look natural: hyperlink them to your text (don’t just paste them next to the relevant phrase, like this: https://hackernoon.com/why-you-shouldnt-raise-a-friends-and-family-round-923083e15df0).

Tag like you’re trying to win an SEO competition

Last - but certainly not least - before you publish, ensure you’ve selected 5 tags that closely match both the content of your article, as well as the terms you think your intended readers are likely to be searching for.

Heads up: Hacker Noon 2.0 will allow you to add not 5 but 8 tags for extra SEO power!

“Good SEO is paying attention to all the details that most bloggers ignore.”
— Ryan Biddulph

There you have it! Your complete guide to getting published on Hacker Noon. Whether you’re a new or existing writer, I hope you found this a helpful primer on what it takes to hit a homerun with Hacker Noon in 2019.

If you think we left out anything important, please feel free to let me know in the comments, alternatively leave us a comment in the doc: https://docs.google.com/document/d/1XfgCHnRe1fiSuBS6iHzG6_A8GTizP6JTraypXjT18pA/edit#


pinned globally #2


This post has some excellent advice, and I love the style, but I have to disagree with your assertion that we shouldn’t use “we” in Hacker Noon articles. It’s a useful word, for building a rapport with the reader, to make them feel like they’re a part of what you’re saying, that you’re in it with them (I personally use it in tutorial-style pieces). Or, it could be useful when you’re writing about a team effort, for example, HN 2.0 and its architecture (I’m working on a post like this now). I’d be curious to hear what the community thinks, especially our contributors!

In general, I think posts can be written from any perspective, not just first-person. Second-person could be interesting, e.g. “You are at a terminal. You see a blinking command prompt. What do you do?”. Third person could be good as well for more journalistic pieces. Generally, I’d rather be inclusive and avoid discouraging anyone from posting a unique perspective on Hacker Noon. That said, I do agree that “we” should not be used as though you’re a “celestial sounding conglomerate” :wink:. What do you think? Is it worth changing the guidelines to include these other perspectives?



Isn’t read time as a quality metric heavily biased toward longer posts?

Wouldn’t something like (total read time)/(length) be better?

1 Like


Looks like there are lot of topics allowed.

1 Like


Read time can be biased towards longer posts but only if you can keep people engaged long enough to read the whole story. It doesn’t matter how long the post is if you’re losing people in the first paragraph. I suspect a lot of long-form content would actually generate more total reading time if it were broken down into smaller posts.

One thing to keep in mind with reading time is we’ll be showing aggregated stats (all time, by month, by tag…). So even if an individual story gets a little boost, that doesn’t mean writers should go all-in on a single post.



@Dane, consider two stories, one is 2000+ words, and another is ~300 words. Both get the same aggregate read time. But readers tend to complete and enjoy the 300-word article while they bounce from the 2000-word article after reading about 300 words.

With the total read time system, you’re rewarding both posts equally, when the 300-word one is, in fact, better quality.

But with (total read time)/(length) as the quality metric, stories are rewarded for completion rates, not just read time, which would also incentivize writers to optimize the length of their posts.

Or are you saying that in your experience, such a scenario is unlikely to occur?



Nice thoughts here.

Before I get into any details, I just want to point out that we’re working on pre-launch theories at this stage. Best intentions and reality are often two very different things. So just want to point out that anything could change once we launch and get real usage.

One challenge I often see in these types of metrics is the balance between simplicity and accuracy. Adding logic to the way you compute the metric often increases accuracy while decreasing simplicity. You might be thinking, “Dividing time by story length isn’t really reducing simplicity.” and I’d agree with you from a math POV. But math complexity isn’t what I’m worried about. I’m actually more concerned about the complexity from a linguistics perspective. Consider how people would talk about this metric.

I finally passed the 1 year of time reading milestone on Hacker Noon. My goal for next year is to hit the decade reading milestone!


My time reading divided by story length stat is 7 weeks. Is that good?

Sometimes you can bundle complexity into a nicely encompassing phrase like “Completion Percent”. Once the phrase becomes “Quality Score”, then I generally believe you’ve gone too far with accuracy at the expense of simplicity. But this only applies if game mechanics are involved. If it’s some metric used to automate some process…then go nuts with complexity to maximize accuracy.

I do really like the completion rate metric Medium uses as a quality score. But my gut tells me that this score might be more relevant to the typical type of content found on Medium vs the typical Hacker Noon story.

If a story is a one-time read, designed to be consumed in a single sitting, then a completion percent metric is great. I feel like technical stories are not necessarily linear, one-time reads. I find that I often stumble on a story and find that it is interesting technically but it lacks immediate utility. So I might bookmark it, share it, and come back later.

My main point is you can get a lot of value from a Hacker Noon story without reading the entire thing. There are a lot of different use cases for technical stories and we currently feel like “time reading” is the potentially a better way to understand if a story is generating value.

Having said all that, I still think long-form and short-form stories are both valuable and we probably shouldn’t skew too much in either way with the metrics we display. I initially talked about showing aggregate stats as a way to encourage both long and short-form content. Here is an early mock of a WIP stats screen to show an example of how we might show aggregate metrics.

This is a really important topic for 2.0. Thanks for bringing it up and helping us get into the details. I can’t wait to see how stats evolve!



Yeah, that makes sense. (time/length) would be a weird thing to brag about.

Ok, so that’s what I missed. I was thinking more on the lines of traditional articles.

I can’t count the number of times I’ve seen “deep dive” articles where I skip to the part I need, quickly close the tab, but still get a lot of value.

The article might be a comprehensive guide to all possible bash commands, but I might only need the one to print the working directory. It doesn’t make sense to penalize the article for a low completion rate here.

Wow! This looks amazing. I can see what you mean by having a simple, interpretable statistic.

Though as someone who has gotten used to Medium’s “number of readers over time” graph, it might take a moment or two to adjust.

I’m assuming that some reader-related statistics (total number of unique readers, unique readers per day, unique readers per week, etc.) will also be available in the final version. Something like this will be included, right?

1 Like


I have a WordPress plugin that exports stories to Medium. The plugin automatically adds “Originally published at X” at the bottom of the post. Is this looked down upon or encouraged?


Sponsor Hacker Noon: Beta Referral Program & more