Introducing Flow from Mixpanel - <AUTHOR> http://flow.mixpanel.com <comment><USER2> I like the simplicity of the UI overall, but I'm always surprised when people go through the trouble to make certain interactions really fancy when the less fancy version would be both better for the user and easier to implement.

In this case, the little popover when I hover over a circle. As I move my mouse around the circle, the popover follows along on the perimeter of the circle, and I must hover over the (hopefully) tiny red piece to get the dropoff stats.

Given the small amount of data being shown in the popover, why not show me the stats for "continued" + "dropoff" in the same popover and just place it to the right of the circle? No fanciness needed, and it'd be more usable.

<comment><USER3> _As I move my mouse around the circle, the popover follows along on the perimeter of the circle_

Seconded, this is a terrible design. Scrap the popovers and just display those 4 figures right inside the circle. Save the eye-candy for where it doesn't get in the way.

<comment><USER4> Exactly. I shouldn't have to hover my mouse over everything to see all the data. Also those tick marks on the outer edge of the circle signify nothing. I thought perhaps the '6' visitors would be signified by 6 ticks... nope. And why does the dropoffs have to fade out? That just is confusing. It would be nice if the dots on the flowchart arrows were proportionally sized to the traffic flow.

It's like "mystery meat navigation" of statistics. If I care about statistics, I'm probably comfortable looking at a page full of numbers. Give them to me, don't make me hover everything.

</comment></comment></comment><comment><USER5> Why is this free?

Is this a loss-leader to get people to sign up for the full Mixpanel service?

These days I just don't trust free services. I don't think there's anything nefarious about them, I just don't trust that they're going to be around in a year (why keep running a service that has costs but no revenue), or that they won't get bought for their talent and promptly shut down.

If it uses resources to any significant degree (a JS on every page load can definitely do that when used at scale) there should either be a fee or a damn good reason why I should put my faith in it, especially if you're asking me to base business decisions / process on it.

<comment><USER6> This is free because to install it, you must put a link on your page back to MixPanel. MixPanel likes links because Google likes links: it increases the domain authority and PageRank for MixPanel. You'll notice that alt text in the link back to www.pixpanel.com is "Real Time Web Analytics", surely a set of keywords that MixPanel is aiming to own in search.

This is a very clever and subtle SEO move that provides real benefit to users at the same time.

<comment><USER7> Adding the badge to your site is not at all required to use Flow. We would like it if you did, so we will give you 4x the page views if you do, but it's not necessary at all.

</comment></comment></comment><comment><USER8> This is neat looking, but I'm not sure how _actionable_ it is. Of course there is going to be a drop-off of users as they drill down. That happens in almost every funnel situation. Also, this doesn't seem to account for other factors that may be to blame. What happens if you stop your marketing? What if you pushed a new version the night before?

What is most illuminating for a chart like this is seeing these numbers as a total % of activations/daily users/daily visitors over time. That way, you can see if a particular change you made (such as doing some landing page optimization) actually increased conversions which is ultimately what you're trying to look at in something like this.

<comment><USER2> The Google Analytics version of this feature does let you do this. In case my other comment mentioning it gets buried, it's called Visitor Flow: [http://support.google.com/analytics/bin/answer.py?hl=en&...](http://support.google.com/analytics/bin/answer.py?hl=en&answer=1709395).

In the Google Analytics version, you can view and interact with the flow graph based on different segments, including "Visits with conversions", "Visits with transactions", and a bunch of other metrics.

</comment></comment><comment><USER9> I'm a paying customer of Mixpanel. I like Flow. My biggest request is the same as the biggest request for the rest of Mixpanel: remove the wall between page views and other events. A flow of pages is nice but a flow of events might really teach me something new about my users.

</comment><comment><USER10> This is the coolest thing I have seen in Analytics for a long time. This really gets to the heart of most of the information you need on user flows and its fast and clear.

Can't wait till they add events to this.

<comment><USER2> Not sure how many are unaware, but Google Analytics has had this same feature for at least a few months (I think) with a different, slightly more fancy, UI. From the new Analytics dashboard, if you go to Standard Reporting => Audience => Visitors Flow, you'll see it.

[http://support.google.com/analytics/bin/answer.py?hl=en&...](http://support.google.com/analytics/bin/answer.py?hl=en&answer=1709395)

<comment><USER11> I've been using GA's visitor flow for a few months and I still think its presentation is really neat. It only shows the first 3 pages viewed, at least on my free account.

I suspect many people still don't know about it, since it wasn't featured upfront like Mixpanel is featuring Flow here. One of those low-profile upgrades that is really quite useful but left unmarketed.

edit: Another thing is that GA's flow presents the actual size of flows visually, whereas Mixpanel's doesn't - the sizes of the circles are based on step number, and you have to mouseover the small points to see the traffic flow percentages. I have to say Google's is superior, at this point.

</comment></comment></comment><comment><USER12> Does this work for single-page javascript applications using html5 pushStates or hash-bang URLs?

<comment><USER13> It does. Using the new Mixpanel JS library you would call:

mixpanel.track_pageview(window.location.href);

</comment></comment><comment><USER14> > _Follow your users every step of the way_

Cyberstalking at its finest!

As analytics tools get more and more sophisticated, one question keeps bugging me. Are companies lying when they say in their privacy policy that they will not share user data with anyone except when compelled to do so by law, and then paste a couple of lines of third-party analytics code in their footers?

It's not uncommon for Ghostery to alert me about 5-10 third-party tracking tools on a single page. Some companies mention analytics explicitly in their privacy policy. But many websites don't. Privacy paranoia aside, I'm curious about the legal aspect of using analytics tools, and whether Mixpanel makes any effort to help its customers comply with relevant regulations (if necessary).

</comment><comment><USER15> Flow looks nice but it doesn't show what I want out of analytics, which is link sources and conversions. What I would like to see is flows like:

CPC ad click -> Product Page (secondary goal: email signup) -> Cart -> (time passes) -> Googled "product" -> Product Page -> (time passes) -> email click -> Product Page -> Cart Page -> Payment (primary goal)

I want to see is where people come from, where they went, and why it works. In the example above, the thing that worked was email reminder. It gets even worse when referers are involved, and blog posts don't remove the utm_campaign=email link.

Basically, I'd like a backwards flow from individual conversions.

<comment><USER16> You should try foretaster, it's very close to what you've just described - <http://www.foretaster.com>

</comment></comment><comment><USER17> Overall the visual design is nice but this doesn't seem very practical.

Issues:

1) Requires too much effort (rolling over hover states) to dig out information.

2) Pairing circles and rectangles as a node make it hard to parse when your eyes are scanning the page. These shapes don't naturally go together.

3) URL's are truncated too short. On the bottom left of the live demo, you see "/account/listi..." twice, and they're actually different URL's. For some websites I can see this becoming a major issue.

4) The rounded circular graphs with the blue and red look nice, but doesn't convey the information very well. Any type of circular chart (pie chart, tachometer graphs, etc.) is not recommended.

Suggestions: I would consolidate the information for each node and show all of the visible and rollover data into a single box. Use varying font sizes, colors, and weights for necessary emphasis. Instead of the circular graphs, use a horizontal bullet graph[1] along the top of each node. Use the bullet graph to display the historical high and low as the bar, and the daily range as the background (or vice versa). This way, the user can scan the page looking at the bullet graphs along the top, and then if something strikes there eye as unusual look below and examine the data.

<http://en.wikipedia.org/wiki/Bullet_graph>

</comment><comment><USER18> Awesome. I've been wanting to see this in analytics for a long time. Not because I would use it, but because I thought it made the most sense. I came across this article on HN a while back that seems to hint at the same thing: [http://www.contrast.ie/blog/the-future-of-analytics- products...](http://www.contrast.ie/blog/the-future-of-analytics-products/)

I believed it was such a necessity that I worked on building a MVP for about a year, but then gave it up a few months ago. The project was way outside my technical ability even after all that I learned and I had absolutely no experience with analytics in general. It was a bad decision to work on it for any period of time, let alone a year. Especially since I had other ideas that I was better suited to build and believed more in.

Now all that's left of the project is a demo video I put together for a job application. This isn't really what I had in mind then, but what the hell...

Show HN: Real-time, visual, click-path, analytics (pathtrends.com) <http://vimeo.com/27327367>

</comment><comment><USER19> Feature request: Please let me have multiple simultaneous URL Groups (or if this is already possible, I can't figure out how to do it). It also wasn't very clear that the URL Groups aren't stored, so I have to re-enter them each time depending on what data I'm viewing? Or am I mixed up there, too?

</comment><comment><USER20> Well this sure looks really cool, but it strikes me as really over designed. Getting at information requires a large number of clicks and hovers over very specific areas.

It is also hard to get a sense of any 'big picture' data. Datapoints are trapped in hover interactions and you have a limited view of your site due to the canvas.

While line graphs are bar charts aren't very cool looking, they provide an enormous amount of visual economy. I care more about the speed of which I can consume big picture and detailed information than my ability to visualize my site map.

</comment><comment><USER21> This is beautiful. It would be nice to be able to collapse pages together or somehow view cycles. On sites where users tend to have long sessions the graph of site traversal has cycles which may themselves be as interesting as how users exit a given page. For example if you have a group of desirable actions (say you have a site with shopping and user-user messaging) and you want to roll up the exits (collapse the above pages together and find out how much in users are falling out of those pages into help).

<comment><USER22> Allowing cycles in your graph is confusing. If a user visits pages A -> B -> C -> A, what is the dropoff between A and B?

</comment></comment><comment><USER23> It looks pretty, the example looks pretty slick, but, it's not all that easy to use in a hurry, and I'm not even sure history exists

It shows a very good 'State of the Machine' at the current moment in time, but it does feel slightly like candy

One major, major thing I would add to convert this into something I would use for my 'strtup' is time, and the ability to see what happened at a time, or event

I am basing this on the 'live demo', but it seems like a report on what's happening now, which isn't really that useful in the grand scheme of things. For instance, if I drop a new feature or blog post on HN, I want to see what effect that will have on my application, and what users do and where they go after first opening that email or clicking on that link

This may seem insane, but I promise I am going somewhere. In my GCSE Physics exam, we were given energy diagrams, and told to do things with them like fill in the blanks. On the left, there was a kind of 'origin', which represented the energy given out by an object. So say a lightbulb gives out 80% light, and 20% heat energy, that would be represented by a 10cm wide arrow on the left hand side, which then breaks into a 8cm wide arrow pointing right, and a 2cm wide arrow breaking off from the main chunk and pointing downwards, to represent waste energy.

This loops back into analysis, say when Flow was first posted onto HN. You could break that down into signups, showing where people dropped off, what pages they viewed and where they went from there, and then render that in a pretty diagram, hopefully showing you where the friction points are

I do also have two minor issues I picked up on from Flow, and I suppose Mixpanel

Given it's a free product, which may or may not have the aim of pushing users into Mixpanl, I could not find any obvious links to <https://mixpanel.com> on the main page. Which was kind of sad, I wanted to read more about Mixpanel and what the bread-making product does, and how it sustains this free app

Secondly, I emailed Mixpanel back in January asking about details for an internship. Since then, I have received a grand total of nothing from them. Which is sad, metrics and user statistics are two things I thoroughly enjoy, and I would love to work with Mixpanel to build things like this

<comment><USER11> Your idea is pretty much exactly what Google Analytics' Visitor Flow does, complete with 'waste' flow dropping off downwards:

[http://support.google.com/analytics/bin/answer.py?hl=en&...](http://support.google.com/analytics/bin/answer.py?hl=en&answer=1709395)

Good that you had the idea, though :) Maybe you can apply it profitably in some other domain.

</comment></comment><comment><USER24> I found the UI very pretty (I had to check it wasn't Flash) but a bit confusing and limited:

\- Only shows 3 flow destinations at a time (and I nearly missed the scroll buttons)

\- Had to mouseover to get percentages. I don't know why why percentages seem more useful to me than actual numbers

\- It didn't feel very "actionable". I can't put my finger on why, but I wasn't sure what I'd do with this diagram.

<comment><USER25> You can click through on any node to drill down - that might not be as clear as it could be.

</comment></comment><comment><USER26> It's really difficult to get a good sense of how a user moves throughout your site. So, I think this could be amazing.

As a next step, they should allow you to click on one of the nodes and turn that page into a cohort. Then, we could analyze the impact of our improvements. That'd be sick.

</comment><comment><USER27> Is this a part of complete Mixpanel service or is it something separate?

<comment><AUTHOR> It's separate and free, however the JavaScript you paste is the same for regular Mixpanel and Flow. So if you already are using Mixpanel then you can just login.

</comment></comment><comment><USER28> Very difficult to use on iPad. You end up drilling down when you try to touch the circle for the pop-up. It's also hard to hit the red part of the circle.

</comment><comment> Tim-Boss How long is this going to be free for? Hate to convert a some websites to it, only to have to move on again in a few months!

<comment><USER25> It will be free forever, and integration is almost zero effort - just paste a snippet of code.

</comment></comment><comment><USER29> Awesome UI - Nicely done. Fancy UX always has its limitations but also serve as exploration into future trends, etc.

</comment><comment><USER30> This is very intuitive! Graphical representations are always better than data in such use cases, IMHO.

</comment><comment><USER31> Interesting, they just mask listia.com's data for their example.

</comment><comment><USER32> It'd be great to be able to segment logged in/out users.</comment>


Slow down your code with goroutines - <AUTHOR> https://appliedgo.net/concurrencyslower/ <comment><USER2> Thanks for this great article :-)

I wonder if I should learn Go, but in Kotlin we now also have Coroutines :)</comment>


Long term support considered harmful - <AUTHOR> http://www.tedunangst.com/flak/post/long-term-support-considered-harmful <comment><USER3> > _Frequent upgrades amortize the cost and ensure that regressions are caught > early. No one upgrade is likely to end in disaster because there simply > isn't enough change for that to happen._

Oh, how I wish this were true.

For what it's worth, it's pretty true as far as OpenBSD is concerned, in my experience. But OpenBSD is the exception here, not the rule. Everywhere else, developers all seem to have embraced "break early, break often".

Eventually you get burned. For me, it was a routine should-have-been-minor web server update where one of the packages I relied on suddenly became unsupported and _every single hosted site stopped working_. Since there's no way to roll back server upgrades, I had a marathon night involving building a new server stack and migrating all hosted sites there by 8 a.m.

But you can't yell at anybody when that happens, because the answer's always the same: it's not the developers' fault.

Who really believes sysadmins wouldn't update everything all the time if they could? Old, dodgy, out-of-date servers exist exactly because updates are butthole-puckering, because everyone's been burned at least once by a "minor" update, and because once the damage is done, undoing it is horrifyingly difficult.

<comment><USER4> "Since there's no way to roll back server upgrades"

It is if you run a modern filesystem like ZFS or btrfs. You just do a cheap snapshot before upgrading(can be automated) and roll back if there are problems. Even works with lvm.

<comment><USER5> Sadly as zfs isn't as widely available as I'd like, you can use LVM to provide snapshots.

Its not as friendly as ZFS snapshots, but it is at least available in centos 5 [https://www.centos.org/docs/5/html/Cluster_Logical_Volume_Ma...](https://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/snapshot_command.html)

(sadly somethings need long term support)

<comment><USER6> rolling back a LVM snapshot involves dding off the snapshot, and on to whatever you want your production disk to be (or just running off the snapshot forever, which has.... performance consequences with LVM.)

Yes, LVM snapshots exist, but they are of limited utility compared to ZFS and the like.

I've been experimenting with CentOS6 and ZFS on Linux; so far it looks pretty good. it handles failing consumer grade hard drives vastly better than lvm on md, and snapshots are inexpensive.

<comment><USER7> You can also roll back lvm snapshots using the merge option

[https://access.redhat.com/documentation/en- US/Red_Hat_Enterp...](https://access.redhat.com/documentation/en- US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/snapshot_merge.html)

<comment><USER6> nice. I had not seen that before... that makes it a lot more useful.

</comment></comment></comment></comment></comment></comment><comment><USER8> > A one year support window isn't too short; it's too long.

Wow, I'm in very strong disagreement with the author on this point.

I don't think I could find a single person, technical or otherwise who didn't use the same operating system for more than a year. In fact its the default for almost everyone who isn't technically inclined to upgrade their os only when they get a new computer.

What about every single car produced today. I doubt you'd want to upgrade them every 6 months.

As a ubuntu user, I find that I cross my fingers every time I run sudo apt-get upgrade. About half the time I get broken builds and once a year my OS will just flat out crash from it, or fail to reboot in virtual box.

This view, while idealistic is just so laughable I can't begin to believe the author is serious.

I've worked with some mission critical systems( stock exchange's) They take more than a year planning a big OS upgrade. To turn around and tell them that they should be doing this every 6 months is just so out of touch with reality, I don't know how to respond to the author:(

Many companies won't install a new piece of software until its been proved out in production for 6 months to a year by someone else....

<comment><USER9> From a different perspective...

... perhaps if we were to actually get serious about doing small/incremental updates all the time, we'd get better at actually doing them without incident.

I think one of the major obstactles is that the software stack has become ridiculously (and hideously) complex over time. If we could converge towards a world more like what's described here[1], then I think we'd be in a better place overall. (Granted, this the video is talking about deploying services, but AFAICT there's little _essential_ difference between that and a modern GUI system with all its DBUS interfaces and whatnot.)

[1] [https://www.youtube.com/watch?v=GaHzdqFithc](https://www.youtube.com/watch?v=GaHzdqFithc)

<comment><USER10> Small, incremental upgrades are something I'm finding are essential to maintaining sanity as the only dev at my company doing what I do. Waiting to upgrade only increases the pain. Now instead of having one potential issue to troubleshoot every now and again, I have dozens when I finally do buck up and upgrade.

So I get in the habit of upgrading the dependencies of all the apps I work on, every time I work on them. Issues happen, but only to one dependency at a time. It's manageable.

What I would love is to eventually have a CI server do it for me. Every single day, it would run bundle update, run the tests, and deploy unless there's a problem. If there is a problem, it drops me an email with the trace and fixing it becomes part of my morning routine.

If subtler problems surface this way, then I've discovered an oversight in my test coverage, or an overly complicated architecture that I need to remove dependencies from.

I'll probably implement this sometime this year. I'm thinking I'll want to redo deployment instead of relying on Capistrano, then finally growing my own CI solution. I'm slowly moving away from big monolithic apps to smaller, homegrown solutions that do only what I want them to do. I've already reimplemented provisioning and configuration management. I believe in DevOps as code.

<comment><USER11> > What I would love is to eventually have a CI server do it for me. Every > single day, it would run bundle update, run the tests, and deploy unless > there's a problem. If there is a problem, it drops me an email with the > trace and fixing it becomes part of my morning routine.

Agreed. A while back, there was a security fix in the default php5-fpm configuration (0666 -> 0660, I believe), and I skipped it when updating. My website went down until I learned to change the owner of the process. And this wasn't even a _dist-upgrade_.

Sometimes manual intervention is required.

In my case, I run updates almost every day. If I had to wade through 6 months of backlogged updates, I would have wasted a lot more time identifying where it broke. Smaller feedback loops are a win.

</comment></comment></comment></comment><comment><USER12> Upvoted for some interesting points, but it's quite wrong for the simple reason that on a commercial timescale one year is nothing. There are reasons Microsoft end up being dragged into supporting old OS versions, and it's because running an operating system is just a means to an end, which hopefully is doing something useful. "Upgrades" have, understandably, become synonymous with unnecessary pain and breaking things.

Maybe OpenBSD really is more rigorous about quality control, but (as an example) if you were to just accept every Ubuntu update it wants to install you'd be wasting a significant amount of time just ensuring your system works properly.

<comment><USER13> > on a commercial timescale one year is nothing.

I've worked in commercial environments where common invocations of `tar` did not work, because `tar` was a _decade_ out of date. I had to learn things and habits that had died before I even started programming. It wasn't pleasant. Do not underestimate the age and stubbornness to upgrade of some environments.

Recently, I've helped migrate software from Ubuntu Precise to Trusty, and the amount of differences make things mildly frustrating. We don't get to just run one or the other, and we can't just drop everything and move to Trusty. We have to continue to support the old while we build support for the new, briefly support both, transition to the new, then tear out the support for the old. Migrated. It's a lot of work when the changes are huge, but much more manageable when I can take the changes more piecemeal (it's one if statement, as opposed to many, that I need to manage at any given time). That's in a production environment.

I run Gentoo at home. I much prefer its rolling releases to Ubuntu and Debian which I ran alongside and before, respectively. Things break every now and then. It's a tad annoying, but it gets fixed sooner or later.

</comment></comment><comment><USER14> "Considered Harmful" Essays Considered Harmful: [http://meyerweb.com/eric/comment/chech.html](http://meyerweb.com/eric/comment/chech.html)

I think the OP is being a bit naïve if they expect all users to upgrade to a new OS every year. Upgrades of Ubuntu and OSX are usually quite painful endeavours, fraught with UI-breakage and new bugs to solve, and there's usually little incentive for users to upgrade in every 6-monthly release.

IMHO Ubuntu has a good two-pronged approach - short-term support for most releases, but a LTS every couple of years for those who don't want to handle the pain of upgrading all the time.

Anecdotally, even upgrading to stay up-to-date with the LTS versions can be difficult. A company I deal with is currently scrambling to ditch Ubuntu 10.04 before it loses support in April this year. That's 5 years old now. Companies don't upgrade for fun.

</comment><comment><USER15> Personally I think a 6 month release cycle is the worst of both worlds. Either give me LTS and I'll do that one big upgrade every few years, or give me rolling release where any breakage should be relatively localized and minor. But with 6 month release cycle you have to constantly be upgrading, but the upgrades are still big "break the world" upgrades.

</comment><comment><USER16> >Now on the one hand, this forces users to upgrade at least once per year.

The problem with this article is this assumption which is not true in the slightest.

There's no force which makes users upgrade - some users will upgrade when they're told; some will wait 5 or more years - and may have good reason to.

> Nothing kills a bug report faster than "My network card worked in 4.4 but > stopped working in 5.6." Developers aren't going to bisect five years of > changes; you get to do that yourself.

This statement can translate into _don 't ever upgrade_. Is that really the goal?

<comment><USER11> No. Ideally, the goal is that users will upgrade as soon as a fix is available.

<comment><USER17> The author makes it sound like the developers won't care about the bug because the user waited from 4.4 until 5.6 to upgrade.

In this case the user is better off not upgrading if the developers aren't doing to do anything about it.

<comment><USER11> No, in this case, the user should have been upgrading this whole time, not putting it off for 3+ years.

Downvote me all you want. Tough love is what's needed here. Hiding my comments isn't going to make peoples' negligence any less _their_ fault.

<comment><USER18> Their network card still would have broken at some point and they'd be in the same bind they are in now: A non-working critical part and at the mercy of the developers to identify and fix the bug.

<comment><USER19> Exactly this thing happened to me in an OpenBSD upgrade. My network card no longer worked. That prompted me to actually read the release notes, and I quickly found the reason.

</comment></comment></comment></comment></comment></comment><comment><USER20> Every time this topic comes up, we have people talking about really different things not clearly explaining what they are referring to, and causing confusion and people not understanding the reasoning of others.

I've read the following arguments already, but with portions of them implicit. See if you can determine why the people are talking at cross points:

\- "I generate VM server images for all my needs, and deploy to virtualization infrastructure behind load balancers to handle services. I treat he OS like an application like the rest of the stack, and all my data is abstracted to a data layer. I just generate a new image with patches and test it, then deploy if it works in my test suite."

\- "I have hundreds of servers in dozens of roles with different software needs, and I need them to be _secure_ and _stable_ in a timely fashion, and I can't spend multiple weeks achieving that. Long term support and back-patching allows me the time to plan needed large changes in infrastructure without having to spend all my time managing updates, software changes and configuration changes multiple steps down the dependency graph."

\- "I have a few servers with a few roles, or many servers with one or two roles, and I can manage frequent updates just fine, and it allows me to take advantage of the newest features, get security updates immediately as the software authors fix it, and I don't have to worry about end of life of software."

\- "I have an application stack with multiple dependencies, and I just make sure to update my stack as I make changes to the software. I would love/have set up continuous integration software to build and test everything as I go, so I know if it works or not before taking it live."

As someone who's been in all of these situations at different points, often multiple at once, let me be clear: _Unless you have an argument that addresses ALL of these situations, you really haven 't thought through the issue._

<comment><USER21> I think the author is advocating that those scenarios should converge. His argument is that second scenario is an anti-pattern and should be corrected to be more inline. It might be a pipe dream, but it's still his perspective.

<comment><USER20> They serve different needs. The second scenario may well be better served by moving towards the first, but that's not a quick project, especially when uptime and reliabiity is important. Even with that, the for the third scenario a full VM infrastructure may by overkill. This whole topic can be summed up with "Examine your needs, examine your options, make the best choice you can at the time, try to make your life easier by leaving pathways to change your choice with the least problems based on expected future needs."

Just because someone _looks_ to be doing something similar to you, doesn't mean their needs and constraints aren't quite different. I think this is the big thing most people miss.

</comment></comment></comment><comment><USER22> It's funny that just today, before I found out about the glibc vulnerability, I reconsidered if I really want to upgrade my Ubuntu 10.04 mail and web servers to Ubuntu 14.04 LTS. I was triggered after reading some bad things about 14.04 [1]. I've looked at the M:Tier binpatches and package upgrades for OpenBSD, looked at FreeBSD, Debian with it's experimental LTS, but eventually I'm still in favor of the 5-year support for Ubuntu server.

I have bad experiences in upgrading production machines in-place, whether it is OpenBSD, Ubuntu or Debian and always install a new machine (vps) side-by- side which is really the only stress-free guaranteed way to go in my opinion. Having to do this only once every 5 years is really a lot nicer then at least once a year. The good security backports of Ubuntu, minimal breakage (auto- security upgrades at my Ubuntu servers have been working almost flawlessly [2]) are the least maintenance, stable and secure setup I can imagine.

OpenBSD having only one year of support, no binpatches of the kernel and having no stable security fixes of the packages are the reason I only use it with anything that can be done by the base system (backup host and nameserver). OpenSMTPd looks very promising, but I would need supported amavisd packages, same goes for httpd that needs php in my setup. Besides it's limited use, I still love OpenBSD and the mindset that stewards it. If only they had longer support and binpatches for kernel and packages :)

[1] [https://tim.siosm.fr/blog/2014/04/25/why-not- ubuntu-14.04-lt...](https://tim.siosm.fr/blog/2014/04/25/why-not- ubuntu-14.04-lts/)

[2] the mail config was overwritten once after an auto security update of dovecot in 10.04, quickly recovered it with etckeeper (/etc in git)

<comment><USER23> Thanks for the tip on etckeeper! I've been wanting something like that for a while.

</comment></comment><comment><USER24> His reasoning makes sense but, as all developers tend to do, he spots an error in a system and wants to switch to another or invent a new one. You know the xkcd.

Often times the solution is just to work together and fix the old one. For me the logical fix would be to patch all kinds of malicious, undefined or non- spec behaviors in LTS releases in short cycles regardless whether the developer thinks, it is security-critical or not. To make this more feasible you could either pay for it or use a minimal base system separated from the user-space. Both exists today.

<comment><USER25> That's both a lot of work and a lot of churn, though - people choose LTS because they _don 't_ want things to change!

<comment><USER24> In a sense, things do not change, they stop to be changed from a assumed state.

</comment></comment></comment><comment><USER26> There are a lot of problems with this argument, especially when you go into the ports section. For example, the version of go between 5.4, 5.5, and 5.6 is different for all three versions, which means you're going to have to rebuild packages, run regression tests, etc every six months to make sure some new feature doesn't run into your code, or some bug isn't introduced. Similarly, in the case of the base install, you are still going to have to run a regression test there to ensure that any deprecated or removed features don't impact your workflow.

These things are expensive from a development and ops perspective, and why most commercial software vendors tend to stick to a releasing for a few platforms they know are going to be supported for longer than a year or two. Yes, OpenBSD upgrades are mostly painless, but still, bugs can and do happen, and expecting everyone to be able to just drop everything and rebuild is plain and simple unreasonable.

</comment><comment><USER27> In theory, I agree. I've often likened code development to muscles; you get good at what you do, and what you don't do atrophies. If you push changes ever hour, you get very good at making sure that works. If you push them every three months, you get good at pushing them every three months, and panic when something requires you to move within days. And so on. This applies to all sorts of development process aspects (test a lot, get good at testing, fail to test, becomes impossible to test later, etc).

In practice, neither what tedunangst nor I think matters, because once you ship something to a customer in any way, they're not going to upgrade it. Offer automated upgrades and they'll demand a way to turn them off. It's not just developer boxes we have to worry about, unfortunately.

</comment><comment><USER28> Forcing users to upgrade frequently has one outcome, and one outcome only: they will stop upgrading, period. If you give users only two choices, they will choose one, but the one that requires less effort.

There is more to life than keeping up with the constant upgrade treadmill. It's already bad as it is. Some Linux distributions are on a 3-year support cycle, which is too short. If you have many servers, especially many servers running a lot of different things, upgrading every 3-years means having people doing nothing more than upgrades.

Once you fix your applications to support the changes in the next OS release, that release is almost out of support...

<comment><USER29> _they will stop upgrading, period_

Has that been observed with Chrome, ChromeOS, iOS, etc.?

<comment><USER28> That's an apples to oranges comparison. To upgrade Chrome a consumer depends only on himself. To upgrade a server OS, the "user" (the sysadmin) depends on a number of other people with different priorities. And that's _if_ the people he depends on are still with the company...

I've been faced inumerous times with impossible upgrades (nobody cares about upgrading besides you, so nobody cares to fix whatever is preventing the upgrade). And when the upgrade is possible, many times it takes years.

That same user that upgrades Chrome on his laptop, is still stuck with IE7 at work because his company relies on it to pay his salary.

</comment></comment></comment><comment><USER30> Oh please, all it would take for this "Ghost" vulnerability not to happen was someone at glibc to have made the right call regarding how to treat a buffer overflow in a function dealing with external data. They didn't, so what? The lesson here is that Red Hat & other companies should do additional review if they are shipping something branded as super secure and stable.

Long term support is great. People screw up sometimes. Additionally, it's about time core software components get more attention from companies with the big bucks (and that are profiting from it).

<comment> vezzy-fnord Personally I'm of the idealistic belief that glibc is really starting to show its corrosion, and should be replaced by a clean-room, standards-compliant and elegant design like musl: [http://wiki.musl- libc.org/wiki/Functional_differences_from_g...](http://wiki.musl- libc.org/wiki/Functional_differences_from_glibc)

Of course, this would be a massive change for the Linux ecosystem at large. It is my hope that projects like Sabotage Linux will eventually procure most major software to become musl-compatible, though.

The source of the GHOST bug was in NSS, which musl lacks by design.

<comment><USER31> Speaking of corrosion, maybe we should be building systems with a language which avoids most of the problems of C.

<comment><USER26> I think that the OpenBSD team has more than definitively shown that C isn't a problem, programmers' attitudes is the problem. While I disagree with them on the premise of upgrade early and often, I do agree with them on active reviews, active documentation, and enforcing code hygiene, which prevents the sort of problems that proponents of other languages harp on about when talking about C.

<comment><USER32> > I think that the OpenBSD team has more than definitively shown that C isn't > a problem, programmers' attitudes is the problem.

To err is human, no matter what your attitude. While having the correct attitude can help, this line of argument - that it's the programmer fault and not his tools - is part of the very attitude that causes problems!

Any decent programmer embraces the fact that they'll make faults - and beyond simply trying to improve, they'll also embrace tools that help them compensate. Such as static analyzers. Fuzzing frameworks. Safer programming languages.

Perhaps they'll choose tradeoffs that sacrifice some of these options - <USER2> certainly do, coding in C++ all day, a language with at least 40 references to "undefined behavior" in the '03 standard alone. But that doesn't mean those tools aren't worth considering.

> I do agree with them on active reviews, active documentation, and enforcing > code hygiene, which prevents the sort of problems that proponents of other > languages harp on about when talking about C.

I see zero inherent reason to rely on extreme vigilance by programmers to catch errors that better tooling can catch without having the occasional shared blind spot where 5 programmers all miss an uninitialized variable.

You can help use these to help compensate for C's weakness if that's a tradeoff you need to make, but that's quite an opportunity cost - leaving them with far less time to catch other logic bugs and ship features.

There's a reason nobody preaches about how it's going to be the year of the OpenBSD desktop (and that's not a knock at OpenBSD!)

Vigilance also requires the right knowledge. A coworker recently revealed to me he'd only recently learned that C++ member variables will generally have unspecified values if you don't initialize them. He thought other threads were to blame for garbage values.

Every now and then, I check to see if any of the compilers we're using have added a warning I can enable that will catch leaving members uninitialized after a constructor completes. So I can enable it. And configure it as an error. So everyone who builds the code knows there's a problem. Immediately.

So far, no dice.

</comment></comment></comment></comment></comment><comment><USER33> The downside of this is that OpenBSD is pretty difficult to upgrade in a clean manner given it's "uncompress the tarball over /, then clean stuff up manually" method.

I really like OpenBSD, but it desperately needs a modern package management system. This is frankly my largest sticking point with it - it's faster and much cleaner in most cases to wipe, reinstall, then apply configuration than to try to upgrade.

<comment><USER34> How about debian with freebsd kernel?

<comment><USER35> The new pkg tool in freebsd is pretty good and meshes nicely with the ports tree. The marginal improvements for 3rd-party built packages with apt aren't really worth getting rid of the rest of freebsd for. It also doesn't help OpenBSD, which really needs a new package manager.

</comment></comment></comment><comment><USER36> A problem with the lack of long term support is that you have to keep moving.

The most important part of "long term support" distributions is that breaking changes are kept to a minimum. If a "long term support" distribution releases an update to for instance glibc, you can expect that applying that update will change nothing other parts of your software stack might depend on.

The dependencies might be subtle; for instance, a new version of a database server might have optimized its query planner, which happened to make one particular query your software does a couple of percent slower, which led to it using a few more seconds to do its processing, enough to push it over the timeout limit for a different part of the system. So the only sane way to avoid breaking changes is to avoid all changes.

The opposite would be, as advocated in this post, frequent upgrades. "Frequent upgrades amortize the cost and ensure that regressions are caught early", but that means you are dealing with upgrades and regressions all the time. You arrive at work in the morning, planning to write a new feature; but an upgrade has just arrived, and it needs a few changes to your project. You develop, test, and deploy these changes; in the meantime, another upgrade has just arrived, needing more changes, to something you had changed just a few days ago. The day ends, and you didn't even start to develop the new feature. You use more time chasing the upgrade stream than doing productive work.

Long term releases "batch" the changes. When several changes affect one part of your software, you only have to deal with them once. Sometimes, you can even discard that part of your system and do something else, while with a continuous change stream, you might have wasted time adjusting little by little.

A somewhat relevant post from Joel on Software: [http://www.joelonsoftware.com/articles/fog0000000339.html](http://www.joelonsoftware.com/articles/fog0000000339.html)

</comment><comment><USER37> Spoken like someone who has never had to maintain a large production system.

This notion is handily disproved by the market, though. Red Hat and Canonical enjoy commercial success and mindshare precisely because they provide stable long-term support platforms on which others can build software. Most of Canonical's worth is actually embodied in their commitment to LTS releases, which provide a sweet spot between stability and the glacial pace of RHEL.

</comment><comment><USER15> Isn't 6 month release cycle and support for past 2 releases essentially also the Fedora release model? From what I've heard (and used) that hasn't been massively successful.

> No one upgrade is likely to end in disaster because there simply isn't > enough change for that to happen.

That might be true for OpenBSD, but in Linux land the rate of change certainly is great enough to cause major breakage even at 6 month cycle.

</comment><comment><USER38> The only thing that would make this realistic is if open source developers prioritize backwards compatibility very highly.

Of course, there will always be some bugs anyway. And it varies across language (or other open source affinity) communities. But in many communities, developers aren't really even _trying_ to ensure backwards compatibility.

If developers committed to backwards compatibiilty with successive versions for X number of years -- then you could update to the latest release for a number of years worrying less about breaking things, rather than needing to freeze the versions you use for that number of years.

Yes, this would significantly increase developer hours on open source projects. Nothing comes for free.

But wouldn't those developer hours be better spent centrally on ensuring backwards compatibility in the projects themselves; as opposed to every developer of every consumer of the project needing to deal with backwards incompatibility on every upgrade? Or every distro needing to backport patches? (This latter is more debatable, which is exactly why we have the status quo)

</comment><comment><USER39> There is a cost to upgrading and there is a cost to staying behind. As soon as the cost to stay behind outweighs the cost to upgrade I upgrade, but no sooner. Otherwise I'd just be throwing away money and time. The bigger problem here is that the cost to upgrade is only known after the fact. What should be a routine job can easily spiral out of control into a marathon of misery.

</comment><comment><USER40> Reading the title I assumed this was a rant about how proper ops processes replaced the need for LTS releases and the demonstrably bad practices they could be seen to encourage. IMHO, this would have been a more interesting and valid point.

The current post is a straw man argument for a few reasons.

First, because vulnerabilities will be exploited whether the window of availability is 1 day, 100 days, or 1000 days (like this one) and likewise, upgrades will be missed, for various reasons, whether or not they are encouraged.

Second, the author spuriously implies that a 6 month sliding upgrade window ("one size fits all") approach is superior, easier and more appropriate for everyone through a combination of broad assumption and vague hand-waving about developer time efficiency. Rubbish.

If you want newer code, then ASAP is the go and BSD-style monolithic releases are _bad_... something closer to the versionless OS ideal of constant, incremental, package-wise release processes such as Gentoo's _portage_ (BSD- inspired!) where you can even install a _-9999_ ( _git HEAD_ ) version of many packages would be ideal. Obviously, with such an approach, stability caveats must be considered (as they are). Thus, both FreeBSD and OpenBSD actually represent a 'middle-ground' between Gentoo and commercial Linux vendor LTS, with OS wide release processes incorporating some greater collective package and package interoperability testing, combined with the package-wise release of things through the ports trees.

 _What 's the real ideal here?_ A general purpose means to build working, tested, maintainable, secure systems with minimal effort for a broad audience.

 _How to get there?_ Clearly, not by whinging about external release window frequencies of volunteer-based projects, as any frequency still creates bugs, and no process is perfect. The answer, I believe, is time-honored. Careful design for failure and minimalism, and good process. Test. Measure. Remove surplus features and components. Iterate.

</comment><comment><USER41> Can we have a ban on "X considered harmful" titles? Have some originality.

</comment><comment><USER42> This is not an argument against long term support. It is an argument against using OpenBSD for any project you need to work for more than one year.

</comment><comment><USER43> Yes, we should all step forward into the wonderful world of running brand new software all the time in production. I'm sure it will all be much more secure than relying on year old software that is being actively maintained.

Is the date on this one supposed to be April 1st?

</comment><comment><USER44> PostgreSQL has a 5-year support window.

I'm curious what negative consequences the author thinks PostgreSQL suffers as a result from that policy.

<comment><USER45> It's a lot easier with a 5 year window for PostgreSQL: Kernel developers have to support all kinds of weird semi-buggy hardware that they can't buy in their country, they have to make the kernel work with badly written GPU drivers , and they have to deal with interrupt-level code which is notoriously difficult to debug.

<comment><USER44> The author's primary example for the "LTS is bad claim" was glibc, which is not a kernel.

Are you saying the "LTS is bad claim" only applies to kernels and other things very close to the hardware (closer than a database)?

</comment></comment></comment><comment><USER46> "[Useful popular thing] considered harmful."</comment>


Ask HN: Using vague metaphors as job requirements - <AUTHOR>

What comes to mind when you come across a job opening which requires you to be a "CSS rockstar" or a "PHP wizard"? Is this a by-product of a job market so oversaturated with incompetence that the employers must resort to extremes to make sure only people with real talent apply, or should I just disregard the entire thing as a meaningless trend? <comment><USER2> I don't see anything wrong with it if you actually know what all that (being a supposed "rockstar" in a field) entails. It only annoys me when I hear it thrown around in general conversation by folks who have no clue what a "insert-programming-language-or-framework-or-markup-language here" rockstar really is and they're just tossing it around because they've heard somebody else say it.

> "Is this a by-product of a job market so oversaturated with incompetence > that the employers must resort to extremes to make sure only people with > real talent apply"

I think it might be. I figure folks would still just ask for an "expert" in a job description if that concept hadn't been taken up by a bunch of folks that aren't (in fields _everywhere_ \--not just writing code).

</comment><comment><USER3> Copy written like that are probably from younger companies/startups with less care for rules and being formal. They're just describing the type of people they want and are looking for. Nobody wants someone "proficient in CSS", "experienced with PHP". If the applicant is uncomfortable describing themselves as wizards/rockstars, they're probably unqualified for the position, right?

</comment><comment><USER4> I read that kind of thing as "only those suffering from severe Dunning-Kruger syndrome need apply".

</comment><comment><USER5> I would assume that the people you would be working for are kind of corny, FWIW.

<comment><USER6> Or don't understand the field at all.</comment></comment>


Lightwear: Introducing Magic Leap's Mixed Reality Goggles - <AUTHOR> https://www.rollingstone.com/glixel/features/lightwear-introducing-magic-leaps-mixed-reality-goggles-w514479 <comment><USER2> > As for the cost: "So we have an internal price, but we are not talking about > that yet," he says. "Pre-order and pricing will come together. I would say > we are more of a premium computing system. We are more of a premium > artisanal computer. "

So...to me that sounds like we can expect a $2-4k price tag for the first release? Maybe more?</comment>


Worker Classification and Secure Work in the "Sharing Economy" - <AUTHOR> https://casetext.com/posts/worker-classification-and-secure-work-in-the-sharing-economy

<comment><USER2> For profit entities will never stop trying to skirt regulation. It's one way to get ahead of your competition. We just need to make sure that there is adequate disincentive to do it. Uber is trying to do an end-run around employee laws, and it should be cautioned that this is not acceptable behaviour.

Labor laws in the US are already some of the weakest in the world. The US is the only developed country with employment-at-will, All other developed countries use a just-cause model. Due to at-will employment, you can be fired for wearing the wrong shirt to work in the US.

Uber wants to jettison even these weak protections and go totally unregulated. This would be fine if the other party was in an equal position of strength (i.e. another business). Employers always have the upper hand, and therefore must be subject to regulation to level the playing field.</comment>


Securely store passwords with bcrypt - <AUTHOR> http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/ <comment><USER2> Very interesting stuff here-I've never heard of anyone using bcrypt for encrypting passwords, but it seems like a good solution. The only problem that I see for large implementations is that even with the lowest time setting on bcrypt you're introducing at LEAST a second delay every time someone logs in while you generate the hash. And even on his MacBook Pro he was only able to generate a few hashs per second-if you ever have a rush of signups your potential users could see quite the delay while submitting their passwords.

<comment><USER3> If you're introducing a 1-second delay for login, and that's not what you wanted, you're doing it wrong. The point of bcrypt is that it's tunable, and its defaults are nowhere near that slow. You do not need to slow hashing down to user-perceptable time to make dictionary attacks infeasible.

Also, bcrypt is pretty much the de facto industry standard adaptive password hash. It's not Phusion's crazy idea. There's a PKCS function that works on similar principles (PBKDF), but it isn't as resilient as bcrypt is.

</comment></comment><comment><USER4> Nice to see scrypt getting discussed:

[http://blog.phusion.nl/2009/08/13/securely-store- passwords-w...](http://blog.phusion.nl/2009/08/13/securely-store-passwords- with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/#comment-9081)

<comment><USER5> There's a small Ruby binding for Scrypt available on GitHub. All it needs is for someone put the time into making it a gem, and maybe bundling it with Scrypt as a Ruby extension.

<http://github.com/coderrr/scrypt-ruby/>

<comment><USER6> That's a binding alright. But it's not easily installable: one has to install the scrypt library manually. I'm not sure how to do that because last time I checked scrypt is a program. Scrypt is also not packaged by Debian at this time. All in all, I think it's not the right time to use scrypt yet - at least not until there are easily installable libraries.

</comment></comment></comment><comment><USER7> Ok so what happens if my site gets popular - and I can dream, can't I? - and I get hundreds of people logging on per second?

</comment><comment><USER8> I don't think this is necessary. SHA1 was designed to be fast, yes - and fast is exactly what you want when you're logging thousands of users into a web site. But that's not even the problem.

Security is all about the weakest link. There is no point dialing one of the links up to absolutely insane heights without taking commensurate measures with the rest of your links - and a salted, hashed, SHA1 password is already pretty freaking secure.

Let me give an example. If your opponent possesses the _incredible_ resources necessary to brute force SHA1 in a useful timeframe - and there are probably only a handful of such organisations on earth, all governmental - then they will not even bother with that. They will simply bug your server and collect the passwords plaintext somehow there. Or they'll subpoena you and force you to start collecting the plaintext. Hell, what do they need the passwords for anyway?

See what I mean? It's solving the wrong problem. Anyone who could actually brute force SHA1 is such a formiddable opponent that they could not care less if you changed to bcrypt or whatever. You have already lost if they even decide to mess with you.

Plus, it's yet another dependency. And then the speed penalty. Forget it. Put the time into setting up SSH keys or turning off root login or something; you're a million times more likely to be compromised by those kinds of everyday flaws than NSA-level shit like this.

<comment><USER3> This isn't even an argument; it's just an attempt to troll this conversation. You've written enough stuff elsewhere on HN that I know you're not this dumb, and I know you don't actually think people are talking about brute-forcing the SHA function itself, despite Phusion's poor choice of words.

You and I both know this attack is about running a dictionary of possible passwords against a stolen password database, and, because you seem smart (if annoying), I'm pretty sure you also know that attack is lightning fast. You also seem young, so you might not realize that this attack was the "industry standard" password cracking mechanism throughout the entire 1990s; it's the attack that Crack and John The Ripper are based off of. Before the crappy LANMAN hash, it was the only password attack Unix hackers had available to them, and it was so effective that every Unix system had to implement "shadow" passwords.

Please stop trolling, sho.

<comment><USER8> tptacek, I am not trolling. If you can show me an instance where anyone, ever, has successfully brute forced a properly set up (salted AND peppered) hashed password from ONLY the hash and the salt then I will quite literally eat my hat. It simply cannot be done with current technology and no amount of rank- pulling will change that.

However, I've actually changed my mind and conceded defeat on this one. If the attacker could grab a copy of the app code as well and get the pepper & hashing setup, bcrypt would indeed slow down the ensuing attack on the passwords. You're basically screwed by then, of course, but it would be nice for the users if they had a little while longer to change their passwords on other sites.

I'll be using bcrypt from now on.

<comment><USER3> You're not even reading my comment before responding to it. Focus your attention on the part about how the attack bcrypt defeats was the sole attack used against Unix passwords for an entire decade, the basis for two of the most popular security tools of all time, and the reason we have shadow passwords.

Also, there's no such thing as "pepper", despite what the PHP forums may say.

If you weren't deliberately misleading developers into using insecure code patterns, I'd just ignore you, sho.</comment></comment></comment></comment>


Graphtage: A New Semantic Diffing Tool - <AUTHOR> https://blog.trailofbits.com/2020/08/28/graphtage/ <comment><USER2> Hideous screenshots aside, Graphtage itself looks very useful. Can it generate Git-compatible diffs for use as a Git difftool?

Also-- for "standalone" tools like this that are written in Python, I highly recommend Pipx for installing them: [https://pipxproject.github.io/pipx/](https://pipxproject.github.io/pipx/). It installs each tool into a separate self-contained virtual environment and symlinks the executable itself to a "bin" directory, which prevents tools with different dependencies from conflicting.

</comment><comment><USER3> This is very interesting and a much needed tool. I have been searching for a tool like this for a long time. There are so many tree-like structures that I'm sure there will be interesting use cases...

I was recently working on a similar tool[1] but specific to the domain of "content trees" that consist of content nodes organized into a hierarchical structure. In my case each tree node has a persistent `content_id` associate with the underlying content file and independent of its position within the tree, which allows me to detect "move" operations[2] (a node with the same `content_id` appearing in a different place in the tree).

The use case is for educational content: Kolibri channels[3] are these huge trees that consist of thousands of nodes and it's difficult to know what has changed when we create new versions of the channels. I tried all kinds of general-purpose diffing tools and failed miserably so I started working on treediffer. It's almost done; I hope to finish it later this fall, and will look at graphtage to see how it works.

[1] [https://github.com/learningequality/treediffer](https://github.com/learningequality/treediffer) [2] [https://treediffer.readthedocs.io/en/latest/diff_formats.htm...](https://treediffer.readthedocs.io/en/latest/diff_formats.html#example- of-node-moved) [3] [https://kolibri- demo.learningequality.org/en/learn/#/topics](https://kolibri- demo.learningequality.org/en/learn/#/topics)

</comment><comment><USER4> Has anybody went through React's HTML diffing algorithm? If this one's good, we could write a JS version and use it for HTML diffing in browsers.

<comment><USER5> Graphtage could be compiled to wasm and used in a browser.

</comment></comment><comment><USER6> I was staring at a diff today and longing for better semantic diffing.

I'd changed a shell script, with a chain of commands. I added a second call to the same command with different args and the diff was just... bad.

        something && fizz foo && another

        something && fizz bar && fizz foo && another

It decided that "bar && fizz" was my edit, and I just stared at it (it was already a tough day). Even if they had just weighted punctuation characters differently, it would have gotten the right answer, as it would with adding new functions or array entries, which it always gets wrong too.

Sort it out please.

</comment><comment><USER7> interesting "This tool was partially developed with funding from the Defense Advanced Research Projects Agency (DARPA) on the SafeDocs project."

I like the idea that it can do semantic diffs across different formats.

</comment><comment><USER8> I would recommend deleting the screenshots, though. I looked at them and thought "so what? that's been done many times before" until I read the text more carefully.

<comment><USER6> I would recommend reshooting the screenshots. Navy blue on a jet black background? Removing new lines in the initial example but not in the diffs? Fixing those would get the point across better.

Also, turn the saturation down. That's the greenest green and the reddest red next to the darkest blue. My eyes.

<comment><USER9> I can't see a problem - there's no pic. I guess they need JS to show images.

Back on point, I see so much of this grey-on-grey type thing, just a little common sense would suggest it's very poor practice but it keeps happening.

<comment><USER6> Exhibit A:

[https://i1.wp.com/blog.trailofbits.com/wp- content/uploads/20...](https://i1.wp.com/blog.trailofbits.com/wp- content/uploads/2020/08/example.png)

<comment><USER9> First thought was you'd given me a nethack screenshot by accident, but thanks! Interesting project.

</comment></comment></comment></comment></comment><comment><USER10> super cool, having worked on related problems independently (tree-based file compression & arbitrary graph-based file compares) _and_ currently been in search of better way to compare web scrapes over time

kudos for putting the two concepts together / will give it a go

</comment><comment><USER11> I want one that can also find non-perfectly matching moved lines :)

looks cool already though, got to try it some time.

<comment><USER12> At my previous job I've built a tool that was capable of doing that (we were merging XMLs with form definitions). The main idea was an interactive mode.

Initially, tool would merge based on series of heuristics and then user would manually adjust "matching" nodes (user could say "actually, this A on the left and B on the right are the same, it's just that it was heavily modified").

<comment><USER6> It seems like if the editor produced hints this would work better, but your target audience also shrinks.</comment></comment></comment>


Men, women use web like prehistoric hunter-gatherers - <AUTHOR> http://www.ctv.ca/servlet/ArticleNews/story/CTVNews/20081009/internet_behaviour_081009/20081012?hub=TopStories <comment><USER2> I wonder if a similar effect is behind male/female differences in mathematical, scientific, and computing fields.

Mathematics usually requires that you go deep into a field, through a long chain of prerequisites. In order to understand general relativity, you need to understand differential geometry, which requires tensors and calculus, which requires vectors and linear algebra, which requires algebra, which requires arithmetic. In order to understand Haskell, you need to understand monads, which requires parametric data types and type classes, which requires algebraic data types, and so on.

Meanwhile, female-dominated skills like communications, law, or management usually require a broad base of knowledge and a relatively shallow chain of prerequisites. Lawyers have to know a ton of information to do their jobs, but much of it consists of court precedents that build upon the basic principles taught in first-year law school.

For that, matter, among the sciences, the ones with the largest female populations are those that require a broad base of knowledge rather than a deep chain of prerequisites. Compare biology and geology to physics and advanced mathematics.

<comment><USER3> If you compare the university student populations: Math has around 50% females while physics has perhaps 20%.

I wonder what causes this.

</comment></comment><comment><USER4> I like - in the words of nostrademons - deep chains of reasoning. When I'm in a foreign city, I rather wander around for two hours than ask for directions. Very male so far.

When it comes to web pages though, I hate _unneccessary_ complexity. I also prefer man pages to info.

</comment><comment><USER5> This has implications in site design: male and female versions of the presentation layer?

<comment><USER6> In an ideal world yes, you would have differing presentations. I would imagine someone like Amazon has experience in this area. Also, see the difference between mens/womens categories at online retailers.

<comment><USER7> You imagine correctly:

[http://www.grokdotcom.com/2007/12/18/thats-my-amazon- kindle-...](http://www.grokdotcom.com/2007/12/18/thats-my-amazon-kindle-but- those-arent-my-hands/)

</comment></comment></comment><comment><USER8> Reminds me of that classic New Yorker cartoon that goes: "On the internet no one knows you're a dog".</comment>


What if we hired writers like we hire developers - <AUTHOR> http://hitesh.in/2012/hiring-process/ <comment><USER2> This ignores different realities in how programmers and writers work.

If you're hiring a writer, you cam ask to see his previous work. Unless he worked for CIA, he can point to books he's written, articles he published etc. You can then read them and that's all you need to make a decision if he's competent enough (you might still interview for cultural fit).

If you're hiring a senior engineer that claims he spent last 5 years coding Big Table at Google, you have to take his word for it. It's not that you wouldn't like to see all his past checkins, you just can't in most cases.

Not being able to see past work, we do the next best thing: interviews, coding questions etc.

The simple explanation is: we don't hire programmers like writers because we can't, not because people hiring programmers are inexplicably so much more incompetent than people hiring writers (despite running much more profitable businesses).

This is changing a bit due to open-source in that more and more people _are_ hired like writers i.e. based on their publicly available past work, but it'll never be the case that every programmer will be able to show his past code.

<comment><USER3> Where is the fine line between coding tests and spec work?

I'm not a programmer, but I've seen startups co-founded by engineers try hiring designers in a similar fashion to I assume programmers as they test designers with a variety of unpaid projects. I've found it to be pretty annoying given that I've already shown a portfolio of work and it's not unlike spec work. I get that some people may have fabricated their history, but that's why some companies do a trial period before committing to a full-time gig.

<comment><USER2> I don't think the line is fine.

If I ask someone to implement a linked list during 1hr interview, it's clear that it's not because I need a linked list implementation in my company.

If I ask someone to stay for a week to work on the company's code base, that's clearly a work that should be paid for at a market rate.

Similarly, I'm pretty sure that you, as a designer, know without a doubt when company's request crosses the line from "I need to make sure you know what you're doing" to "I need you to do free work for me".

</comment></comment></comment><comment><USER4> _> Good spellings and knowledge of grammar rules does not indicate a good writer, and there are tools (spelling/grammar check) and (editorial) processes to take care of that._

Good grammar doesn't indicate a good writer, but bad grammar does indicate a bad one[1]. (Good grammar meaning, in this case, an ear for language. Good writers avoid grammatical errors because grammatical errors _sound wrong_ , like an off-pitch note to a musician[2]. Explicit knowledge of grammar isn't particularly important. For example, good writers may not know what the subjunctive mood _is_ , but they know how and when to _use_ it. Conversely, a writer who has the knowledge but lacks the ear is in for a rough ride.)

1\. Unless it's for effect, obviously, which can range from Rimbaud's "Je est un autre" to Zora Neal Hurston.

2\. Which, of course, may also be done for effect. Which is why listing out rules (about writing, about music, etc.) is so fruitless. Which is true even if the rule is "Don't start three sentences in a row with the word 'which.'"

<comment><USER5> "Good grammar doesn't indicate a good writer, but bad grammar does indicate a bad one"

that is not true at all - not knowing grammar well doesn't mean the writer has nothing good or creative, or worthwhile to say (or write about).

Grammar is just a technicality to be overcome. Creative writing (as opposed to technical writing), is something that is not measured by the knowledge of the language, but by the knowledge of humanity, science, culture and anything that intersects in between. An eye for details also helps. But not grammar.

<comment><USER6> Having something good, creative or worthwhile to say and saying it well are two different things. I understand the phrse "good writer" to mean the latter. Too often have I come across excellent insights buried like diamonds in a dungheap in ugly, tortuous prose. This runs the great risk of these insights being lost or misinterpreted. The converse is possible too, of course; utter nonsense put beautifully.

<comment><USER7> To support that, ghostwriters and copywriters are two examples of writers that take the gist of another person's thoughts and express them well in writing. They are creative writers, but they don't necessarily have to have anything to say to do their job.

</comment></comment></comment></comment><comment><USER8> A developer is a writer; one writes English and the other writes code, but they both write _to a human audience_ (the only "code" a machine needs to see is 0s and 1s; programming languages are for humans).

So there really shouldn't be a big difference in hiring a writer vs. a developer; and a good test would probably be to have developers write essays in English about a technical question: can they make themselves understood?

I would not hire a developer who is incapable of explaining what he's doing, why he's doing it, what the other options are, etc.

Wouldn't it be a good technique to have interviewees bring an example of their own code that they're especially proud of, and have them explain what it does and why it's great?

<comment><USER9> > A developer is a writer; one writes English and the other writes code, but > they both write to a human audience (the only "code" a machine needs to see > is 0s and 1s; programming languages are for humans).

I definitely agree with this! That's what I had been thinking the whole time while reading the articles and the comment threads. This is also my motto, here in the office.

It's too simple to say that there are differences between writers and programmers. I think "writer" should be treated as an umbrella term that encompasses braod ranges of skills. After all, a journalist, a poet, a technical writer and a translator aren't really doing the same thing, are they? I like to believe that the core subset of skills needed to be one of these is also needed (or at least highly valued) to be a good programmer.

Programming is writing. Absolutely.

</comment></comment><comment><USER10> At many newspapers they ask prospective reporters for

1\. Clips (writing samples) 2\. A copy editing test (to make sure they write cleanly) 3\. Actual stories written from some facts or info provided.

That's not so different from asking a developer to write some code during technical interviews. Good clean copy requires similar precision, but your compiler happens to be a human.

<comment><USER11> I think it's very different to give someone a weekend to do an edit test and story sample, than to demand code whilst looking over the applicant's shoulder. One is much like how normal work is done, and the other adds unnecessary stress and pressure that is rare in a functioning workplace.

<comment><USER12> So give them the weekend to do the code test.

</comment></comment></comment><comment><USER13> I had to hire a writer previously. Not being a writer, and never having done this before I was wondering what I could ask them. But it seems more relevant just to ask them to write something than to quiz them or ask them to repeat tongue twisters (I don't understand the benefit of that). So I did 2 rounds where I asked candidates to write a short article on a topic with some loose instructions. I figured, whatever they answer in interview questions the real candidate I wanted will be found based on what article they chose to write and the actual quality of their writing.

For the more typical Q&A interview process all I wanted to find out was would they be a good cultural fit.

Perhaps I oversimplified it but it worked out quite well.

</comment><comment><USER14> The tongue twister was a dead giveaway. Personally, I'd walk out (or hang up) as soon as the Oxford Comma came up, but I have less patience than most.

<comment><USER15> Really? I thought the Oxford Comma question was the only useful one there. You might have to define the term but it's good at showing basic knowledge of grammar conventions.

Anyway this article has a point that this process isn't effective for finding _good_ writers, but I'll be damned if asking people to write _one or two sentences_ doesn't filter out the illiterate people that wander in your door (think FizzBuzz).

<comment> mkr-hn A writing sample is a great filter. Any good writer will jump at the chance to write out a quick (and good) piece of text if it means they might get paid.

<comment><USER16> Why would a good writer be any more likely to do this than a bad writer? Surely it would depend on market conditions?

<comment> mkr-hn It's easy to write out a few sentences or a paragraph for something you're interested in. If you really want to test a writer, ask them for their opinion on traditional publishing. There's no "right" answer, but most writers have an opinion on it and shouldn't have trouble writing a little on the subject.

</comment></comment></comment></comment></comment><comment><USER17> It looks like it's time to recycle some electrons and post the FAQ that Hacker News readers have helped me put together with their previous thoughtful comments about hiring procedures. There are many discussions here on HN about company hiring procedures. From participants in earlier discussions I have learned about many useful references on the subject, which I have gathered here in a FAQ file. The review article by Frank L. Schmidt and John E. Hunter, "The Validity and Utility of Selection Models in Personnel Psychology: Practical and Theoretical Implications of 85 Years of Research Findings," Psychological Bulletin, Vol. 124, No. 2, 262-274

[http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...](http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf)

sums up, current to 1998, a meta-analysis of much of the HUGE peer-reviewed professional literature on the industrial and organizational psychology devoted to business hiring procedures. There are many kinds of hiring criteria, such as in-person interviews, telephone interviews, resume reviews for job experience, checks for academic credentials, and so on. There is much published study research on how job applicants perform after they are hired in a wide variety of occupations.

The overall summary of the industrial psychology research in reliable secondary sources is that two kinds of job screening procedures work reasonably well (but only about at the 0.5 level, standing alone). One is a general mental ability (GMA) test (an IQ-like test, such as the Wonderlic personnel screening test). Another is a work-sample test, where the applicant does an actual task or group of tasks like what the applicant will do on the job if hired. Each of these kinds of tests has about the same validity in screening applicants for jobs, with the general mental ability test better predicting success for applicants who will be trained into a new job. Neither is perfect (both miss some good performers on the job, and select some bad performers on the job), but both are better than any other single-factor hiring procedure that has been tested in rigorous research, across a wide variety of occupations. So if you are hiring for your company, it's a good idea to think about how to build a work-sample test into all of your hiring processes.

Because of a Supreme Court decision in the United States (the decision does not apply in other countries, which have different statutes about employment), it is legally risk to give job applicants general mental ability tests such as a straight-up IQ test (as was commonplace in my parents' generation) as a routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424 (1971) case

[http://scholar.google.com/scholar_case?case=8655598674229196...](http://scholar.google.com/scholar_case?case=8655598674229196978&q=Griggs+Duke+Power&hl=en&as_sdt=2,24)

interpreted a federal statute about employment discrimination and held that general intelligence tests used in hiring that could have a "disparate impact" on applicants of some protected classes must "bear a demonstrable relationship to successful performance of the jobs for which it was used." In other words, a company that wants to use a test like the Wonderlic, or like the SAT, or like the current WAIS or Stanford-Binet IQ tests, in a hiring procedure had best conduct a specific validation study of the test related to performance on the job in question. Some companies do the validation study, and use IQ-like tests in hiring. Other companies use IQ-like tests in hiring and hope that no one sues (which is not what I would advise any company). Note that a brain- teaser-type test used in a hiring procedure could be challenged as illegal if it can be shown to have disparate impact on some job applicants. A company defending a brain-teaser test for hiring would have to defend it by showing it is supported by a validation study demonstrating that the test is related to successful performance on the job. Such validation studies can be quite expensive. (Companies outside the United States are regulated by different laws. One other big difference between the United States and other countries is the relative ease with which workers may be fired in the United States, allowing companies to correct hiring mistakes by terminating the employment of the workers they hired mistakenly. The more legal protections a worker has from being fired, the more reluctant companies will be about hiring in the first place.)

The social background to the legal environment in the United States is explained in many books about hiring procedures

[http://books.google.com/books?hl=en&lr=&id=SRv- GZkw6...](http://books.google.com/books?hl=en&lr=&id=SRv- GZkw6TEC&oi=fnd&pg=PA271&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&ots=iCXkgXrlOV&sig=ctblj9SW2Dth7TceaFSNIdVMoEw#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&f=false)

[http://books.google.com/books?hl=en&lr=&id=SRv- GZkw6...](http://books.google.com/books?hl=en&lr=&id=SRv- GZkw6TEC&oi=fnd&pg=PA95&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology&ots=iCXkgXrnMW&sig=LKLi- deKtnP20VYZo9x0jfvqzLI#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology&f=false)

Some of the social background appears to be changing in the most recent few decades, with the prospect for further changes.

<http://intl-pss.sagepub.com/content/17/10/913.full>

[http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...](http://www.economics.harvard.edu/faculty/fryer/files/Fryer_Racial_Inequality.pdf)

[http://books.google.com/books?hl=en&lr=&id=frfUB3GWl...](http://books.google.com/books?hl=en&lr=&id=frfUB3GWlMYC&oi=fnd&pg=PA9&dq=Validity+and+Utility+of+Selection+Models+in+Personnel+Psychology+%22predictive+validity%22+Duke+Power&ots=5O9Hx_E1vY&sig=g-zERWztBWq3h4guEuv9VVkTh8I#v=onepage&q=Validity%20and%20Utility%20of%20Selection%20Models%20in%20Personnel%20Psychology%20%22predictive%20validity%22%20Duke%20Power&f=false)

Previous discussion on HN pointed out that the Schmidt & Hunter (1998) article showed that multi-factor procedures work better than single-factor procedures, a summary of that article we can find in the current professional literature, for example "Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann:

"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."

[http://geb.uni- giessen.de/geb/volltexte/2012/8532/pdf/prepri...](http://geb.uni- giessen.de/geb/volltexte/2012/8532/pdf/preprint_j.1468_2389.2010.00485.x.pdf)

But the 2010 article notes, looking at actual practice of companies around the world, "However, this idea does not seem to capture what is actually happening in organizations, as practitioners worldwide often use procedures with low predictive validity and regularly ignore procedures that are more valid (e.g., Di Milia, 2004; Lievens & De Paepe, 2004; Ryan, McFarland, Baron, & Page, 1999; Scholarios & Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, & Boramir, 2007; Taylor, Keelty, & McDonnell, 2002). For example, the highly valid work sample tests are hardly used in the US, and the potentially rather useless procedure of graphology (Dean, 1992; Neter & Ben-Shakhar, 1989) is applied somewhere between occasionally and often in France (Ryan et al., 1999). In Germany, the use of GMA tests is reported to be low and to be decreasing (i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use them)."

<comment><USER18> Are there any actually useful integrity tests?

<comment><USER19> Look at the personality tests investment banks ask, and reverse the scoring.

\- How often do you go to parties?

\- Do you find it hard to make friends?

\- Are most people basically dishonest?

\- Do you get a buzz out of taking risks?

etc.

<comment><USER20> I'm unfamiliar with these questions… Inverse the scoring? So what, going to parties is good or bad? How is this relevant to determine if you're good at your job?

<comment> excuse-me The other classic bank question is "do you prefer cycling on an exercise bike or on the road"

I think the idea is that an excerisice bike means you are fitness and performance orientated and able to work toward a arbitrary goal without any obvious reward or it means you are willing to do pointless grunt work instead of something pleasant and interesting - either way you are supposed to say exercise bike

<comment><USER18> "Exercise bike because I'm somewhat terrified of being around cars, random people, and far away from home/office without a nice metal cage around me and a trunk full of storage capacity." Perhaps one of many reasons I don't work at a bank.

</comment></comment></comment></comment></comment></comment><comment><USER21> I think it would be funny to do one of these for hiring plumbers. And you ask them what toilets they have unclogged outside of work for their own projects. And if they tell you they won't unclog toilets if they don't get paid, you dismiss them for having no passion for their work ...

</comment><comment><USER22> I'm a professional writer; i.e., I get paid to write. I didn't study journalism but I was in an interdisciplinary programme that consisted of literature, history, and language (somewhat of a modern day philology degree) in Canada. I've just recently started to learn how to program.

I think if this hiring process works for you, great! But as someone who recently started learning to program, I must say writers are vastly different from developers.

There are different kinds of writing. A novelist and a poet (and maybe even an essayist) cannot write business letters. Business writing is vastly different from any creative writing, an SEO writer is neither a creative writer nor a business writer, and so on and so forth. The difference between business writing and creative writing is each follow different rules. That is, each discipline gets away with different things. Creative writing exploits language any which way possible to get a point across, even if it means breaking the rules. Business writers are conservative writers. They follow grammar rules closer, as well as orthography. Most contemporary creative writers use post- structuralist techniques when telling a story; e.g., levels of narration that go from a protagonist to a secondary character to the world in which the book takes place to a far more omniscient narration and much more (narrative modes can get extremely complex). And if they don't, it is almost a given that a type of meta analysis of it is acceptable and encouraged (nowadays, especially). I don't mean to be condescending but business writers use a more primitive form of writing: straight to the point, the nitty-gritty, the meat of the matter. Business writers specialize in a different form of writing. They have more in common with journalists in that they do not exploit language, but seek the simplest form to explain a concept and be completely understood with no room for misinterpretation. I've always said half-jokingly that journalists aren't writers, because they deal with facts and events. I say this meaning journalists do not explore the frightening realm of creative writing, they only dabble in it. Few have ventured to write creatively within their pieces or let abstract concepts permeate throughout an entire piece. For me, journalists and business writers are data-driven and are hard empiricists. There is no market for creative journalists in the entire sense of the word "creative". When companies say "creative" they mean "Can you come up with an idea in which our audience is interested?"

The proof is actually in the tasting. You say you ask your potential hires to <i>spell</i> out a word. There is your first mistake. Do you know how many great writers were poor spellers? Rarely have I seen great writers who are also great spellers. Great writers have great ideas. This is why the world invented editors. It is an old cliché, but one that is true. What's more: do you know professors still teach and believe this? Right, this isn't Academia, and this brings me to another point. Those who do not major in journalism learn to write differently. Most of my peers were bad writers, but they might be a perfect match for a business's needs because they abide by the parameters set by the company. This brings me back to the point that in most business settings, people do not want creative writers. They want someone who writes within the parameters the business calls for or the higher-ups assign.

The Oxford comma. How much does a writer gain by knowing a definition of a word? Let me expand on what Richard Feynman said about what things are called: "I learned very early the difference between knowing the name of something and knowing something". Definitions belong to the category of "knowing the name of something". The problem with this type of 'knowledge' is, most of the time, the interviewer, as someone unfamiliar with the mechanics of language, does not have the capability to ask and know what function the comma holds when placed in a list before a coordinating conjunction. You are testing how many words a writer knows. So, you might as well ask what a Harvard comma is, just in case, to test if the hire knows this and many other words. Anybody can be a technical writer. Anybody can learn the simple rules of language enough to convey a comprehensible idea.

You're essentially looking for a person who fits your idea of a good writer, which should be understood as being a subjective notion. You have a process for knowing who can write best sellers? What are you waiting for? There is lots of money you can be making and, as I'm sure you are a man of science, you can test your hypothesis of being able to pump out best-selling writers.

Seriously. No. Writing a best seller is a completely different ball game, but please feel free to prove me wrong by giving me some results.

Also, I'd just like to clarify that I've not even touched upon the nuances and differing grammar rules from the US, Canada, Australia, and the UK. Suffice it to say that comma splices are not always incorrect depending on where you live and there are different rules for comma usage.

Also, the Elements of Style is an archaic and misguided book, for the most part. None of my professors ever stressed its importance or use. Unfortunately, I've run out of time and must go now. I wish I could touch on other points!

Sorry for any 'style errors' - I've not proofread this :P

<comment><USER23> Did you really not get that the OP is a parody? The point is that this is obviously NOT the way to hire writers. The implication then being that it is also not the way to hire programmers, even though, sadly, hiring programers is typically done just that way these days.

<comment><USER22> No, I did not get it. I think this is because, as I said, I just recently started learning to program. I started in January, but I do not commit 100% of my time to it, as I have a full time job that deals with something completely different.

I know nothing about hiring developers or being a developer.

Also, for the record, I just read in Hitesh's blog's comment section that this is not about hiring writers.

Thanks, everyone, for not beating me up for it! :)

<comment><USER24> Here's a development tip:

Obviously, to dabble in programming you must learn the fundamentals-- the syntax and grammar. However, your ultimate goal is to envision a problem, device a system that solves the problem, and then gracefully describe that system using your chosen language. You can always look grammar and syntax up in the documentation.

I think you will see the parallels to your current occupation.

<comment><USER25> As a Technical Writer trying to weasel his way into more developmenty tasks, I find this advice insanely insightful. I spend a lot of time frustrated at my lack of development training, and maybe don't step back enough to clearly define the problem-solution before opening Vim.

</comment></comment></comment></comment></comment><comment> mkr-hn edit: I should be less eager to click buttons

\----

Where do I begin…

'spelling of conscientious'

This would be covered in the first editing pass when I turn the spell checker on. I don't see what this is meant to demonstrate. Even good writers have trouble remembering how some words are spelled.

'explain oxford comma'

What's the point of this?

'repeating a tongue twister; I like the "Betty Botter bought a bit of butter" one.'

What's the point of this?

'Questions about rules in 'Elements of Style''

Elements of Style is not a rulebook. It's a stylebook.

'A few puzzles to test their creativity.'

A good writer is like a good designer. You either like their style or you don't. If you don't, you'd never ask them in for the interview. A quick writing sample is the only test of creativity you need.

'More spellings and grammar questions.'

A writing sample is all you need to assess grammar and spelling competence. My grammers is fine, but I couldn't recite rules and practices in a test.

'Some domain related question, for e.g. ask sports writer, the dates when the last football world cup was played.'

A good writer knows how to research. If you need an _x_ writer for some cultural reason then you'd ask for that in the ad. This is a poor filter since it doesn't tell you how well a writer can write on the subject.

'Question on lexical roots of some words.'

Is this an English class or an interview?

I would show myself the door pretty quickly and advise all my writer friends not to consider your company. Your interview questions display a serious ignorance of the craft of writing. Save yourself some headaches and ask the best writer in your office to hire other writers. The sort questions you ask are easily rehearsed by a bad writer with good memory.

<comment><USER26> Did you stop reading halfway? The entire point of the article is that you would never hire a creative writer using these criteria, and yet they are the types of criteria being used for 'creative developers'.

<comment> mkr-hn Apparently I did! I should be less eager to click buttons. I've edited a little note in at the top so I won't get any impulsive downvotes.

</comment></comment></comment><comment><USER27> As a writer, some of this strikes me as dumb. There are a lot of people who aren't "writers" that I'd be glad to hire. Why would you grill someone on the rules in the Elements of Style? They can look that sort of thing up. If anything, I'd be more interested to see if they absorbed the real lessons in the Elements of Style. (Hint: Not the rules.) Also:

"We have found that we are able to hire great writer from this process, who are able to create award winning content, whether it is a short article or a book."

Hire a copy editor.

<comment><AUTHOR> You should read the full article.. the hiring writers bit is just a parody.

</comment></comment><comment><USER28> If you were hiring an editor, rather than a writer, asking about the Oxford comma is perfectly reasonable.

</comment><comment><USER29> I'm an English major and I sweat bullets before I read to the "For the naysayers" part. I wouldn't have gotten past the phone screen.

</comment><comment><USER30> Someone once made a blog with the same argument but used the comparison of a mechanic instead. Anyone know the URL?

<comment><USER31> This might be the one you're remembering: [http://blog.jitbit.com/2011/05/what-if-drivers-were-hired- li...](http://blog.jitbit.com/2011/05/what-if-drivers-were-hired-like.html)

</comment></comment><comment><USER32> No Fizz Buzz for writers?

"Write a 20 line poem. Rhyme every third line with "Fizz" and every fifth line with "Buzz."

</comment><comment><USER33> I am pretty sure James Joyce would fail this test.

<comment> excuse-me I don't know - I can see job offers that say we are specifically looking for experience in consonants not vowels.

Or we need 5 years experience of using the word "necessary"

</comment></comment><comment><USER34> he probably meant assessing and not accessing in the phone screening part - would he have passed his own interview?

</comment><comment><USER35> Is this _not_ how we hire writers?!</comment>