4 ms·
Would you hire a writer with bad grammar?
by mruniverse 10y ago
Would you hire a writer with bad grammar?
- gavanwoolery 10y agoIf they had a killer hook, yes. An editor can always review and fix the grammar. :) A coding analogy: A compiler or debugger can catch bugs. If they can't form a competent sentence, they probably would fail to write a convincing hook. But some margin of error is acceptable.
- deleted 10y ago[deleted]
- mruniverse 10y agoIs the "technical" part really analogous to grammar? I don't think many interviewers care about that. They don't care about missed semi-colons. They want to see that you know how to solve a problem. And a github portfolio is not going to give them that. As an aside, I think debugging is hard even with a debugger.
- rapind 10y agoI disagree. A github portfolio combined with time spent via screenshare reviewing and discussing some of that work is far superior to a technical quiz IMHO.
- gavanwoolery 10y agoThats true, probably a poor analogy, but the overall point is that: Determining a programmer's worth probably takes at least a month in my experience. Maybe even two months. I almost got fired within the first month of my first job, but quickly ramped up and turned around to be the highest value-adding employee by virtue of completing the highest paying contracts at a fast pace (the company was later acquired). Most companies can't spend a month, but a day long take-home test is a great alternative. There are so many facets to a programmer's worth, and so many ways to miss them or ask the wrong questions, that I just don't believe in short, high-pressure interviews. Take home tests have been highly successful in my experience (and a few others, from what I have heard).
- chrshawkes 10y agohow would a GitHub portfolio of problem solving projects and contributions not show that? I can't think of any better way.
- cm3 10y agoWhile true for writing books, I wouldn't consider code that doesn't pass a linter or compiler a useful part of one's portfolio. There is no editor equivalent who will fix your syntactic and semantic errors for you, and getting that right is an important part of your experience with a language/tool.
- dagw 10y agoThere is no editor equivalent It depends on what you are working on. A non-trivial part of my job involves working with domain expert scientists and taking their very clever, but badly written, code that solves some hard problem and turning it into fast, efficient and usable code.
- lucozade 10y agoThe point though, surely, is that having good grammar shows you can write not that you're a writer. The corollary being that passing a technical test means you can code not that you're a good developer. I think it would be a step forward if it became standard practice to expect an online portfolio of a developer's work.
- HerpDerpLerp 10y agoIt is only a certain sphere of devs that have such a portfolio. All my work is done for money and I don't have the rights to show it to anyone else.
- antisthenes 10y agoThe unwritten hand-waved expectation is that you should develop side projects in your spare time. I find that this is incredibly discriminating against people who have other hobbies and don't like to spend 80 hours a week coding with only 40-50 of those being paid. Where the programmer/photographer analogy fails is that usually, the photographer retains the right to the vast majority of their creative body of work, whereas a developer might not have anything client-facing to show at all, even if they have side projects.
- Angostura 10y agoPerhaps http://www.huffingtonpost.com/2014/02/20/grammar-rules_n_4768485.html http://www.huffingtonpost.com/2014/02/20/grammar-rules_n_476...
- d_t_w 10y agoDepends what you're hiring for, grammar never troubled James Joyce.
- crdb 10y agoAs an example of a brilliant book with awful grammar, there's Heinlein's The Moon is a Harsh Mistress.
- atom-morgan 10y agoI would hire a writer who can communicate effectively. Knowing the differences between a gerund phrase and participle phrase is irrelevent imo most of the time.