skysight-inc/HackerNews huggingface dataset:
You can determine how someone thinks without trying to code on a whiteboard. I've interviewed many people for tech jobs recently, I've never even considered asking them to code on a whiteboard.

Writing code on a whiteboard is massively obnoxious. The times I've been asked to write code on a whiteboard I've spent more time screwing with the 'interface' than I ever have spent 'thinking'. e.g. trying to keep a line of text level, figuring out how to get brackets to line up, and erasing lines to reorder or writing lines off to the side with an arrow pointing to where it should go. A whiteboard is the worst possible interface for creating strictly structured text.

You aren't testing how the person thinks, your testing how they deal will a situation you've artificially made as awkward as possible, why? What does this actually indicate to you about the applicant?

If you want to quiz a candidate on how they think when coding then hand them a laptop that is already setup to duplicate its display to a projector. Or give them a simple 'take home' project. You'll learn vasty more than having them regurgitate algorithms on a whiteboard.
> So you continue to use that question?

Well, yes. Is the most simple one I can think that show if a person can declare variables, do a loop and show the result. If exist something better, I wanna know!

Before that question, I do things more complicated. Like do some CRUD, or some kind of task that was realted to the company I was before. But my first results with that lead me to simplify the interview a lot (in time and questions) because I see that if a person can't do this kind of task is pointless try with something better.

And I don't do much presure. I let them alone and give them all the time they want, with internet acces and that. I continue doing my work while they complete the task.

Is important to understand that in my past companies I was tasked to interview fresh graduated coders, and for a lot of backgrounds. And they pay badly. So no much oportunity of get "top players" back them. However, I interview several people with (in theory) experience or from reputable universities and that not change at all the end results.

P.D: Some point to the complications of do this task properly (because unicode). I don't even expect that kind of depth in the answer, looking more in the basic skill, code formatting, and the ability to explain the code writed...
kippt is more like read-later service, not a bookmarking service like Delicious
Thank you for writing openly about these issues, Bubs. You really hit the nail on the head about not being able to have honest conversations with people, especially in SF. Since I moved here, I have met hundreds of people and interact closely with dozens... but I only count one person as a true friend in whom I can confide my personal struggles. Having to maintain a never-ending facade of success and happiness really is draining. Sometimes I wonder for what gain am I paying this price?
Why is Windows still a Thing?
I get spammed a bunch. Really LinkedIn is intended to serve the employer (not the employee), but it can be helpful when you need a very specific skill set. I know over 400 programmers. I only know of one that took a job based on linkedin interaction.

The truth, no platform is helpful or even necessary. I would only take a job offer recommendation from a friend, mostly because they would better understand what I am looking for.
There's a couple flavors of Creative Commons licenses too, which work well for artwork and media, but are terrible for source code.
HTML -> XHTML might happen once IE < 9 becomes irrelevant, but I doubt it

I think XHTML is actually declining in popularity, offset by html5.
Good stuff. It hits a little close to home, but one thing stands out: the bit about how you fear showing any weakness or self-doubt, because of the impact it might have on others.

I would be very reluctant to share some of my own internal fears and self-doubt with anybody. Some of it is pragmatic (what if that person relays it to an investor), some of it is ego, some of it is, well, who knows?
Wow, glad to see this is stirring up a lot of discussion. Thanks for all your contributions guys.

There are a ton of comments down below with a ton of criticisms and suggestions. I will attempt to summarize and respond to the key ones here:

#1: The list is missing a lot of very well-known JavaScript gotchas.

That's intended. My goal here is not to provide a complete, comprehensive list of all known quirks with the language - those exist in far better fashion on the web already. Rather, my goal is to create a simple list of issues that I KNOW will trip up newbies out of the gate.

Oddness with truthiness, undefined and arrays is definitely irksome, but from my experience people tend not to run into those problems until they've already written a good chunk of JS. On the other hand, issues like var, confusion over closures, and the this keyword come up very quickly - almost immediately.

#2: The list seems very negative and biased against JavaScript.

My apologies, as that was not the intent at all. JS is great. But it is also extremely flawed and there are some things flat-out wrong with the language. I'm definitely not the only person who says this, either. :)

It's a great language to work in and you can do some wonderful things with it once you grok it, but if we're going to be completely objective, we have to admit that it has some definite problems that make it hard to learn.

#3: This seems full of preferences, not hard-and fast rules.

That's definitely by design as well. I circulate this list out to my team and so it has my fingerprints all over it.

If this is a real sticking point with you guys and you feel it would be better having that stuff removed, please send me some pull requests and I'll be happy to review.

#4: The author comes across as snarky and unhelpful.

That's just a personality flaw and I apologize for it. :) I didn't want this piece to be dry and I injected a bit of voice. If you feel it's actually detracting from the article, please feel free to shoot me some examples and I'll clean it up.
Also because I like working with my friends!
I used to use light boxes in the morning, but have recently switched to heavy boxes, and find them much better personally.
Windows 8: Design over Usability
I agree. In late 2009 when my startup tanked and my SO left me I was in a really bad place. Having a large family (parents, but also siblings) really helped me stay sane.
Founders can talk to therapists who won't talk to anyone else about their troubles. It's not a perfect solution, but probably better than not talking to anyone.
I built a better Google. It was easy.
Oh, and one more thing. If you see anything in there that's flat-out WRONG - not just a preference or stylistic choice, but actually WRONG - by all means, shoot me a pull request! That's what it's there for.

I see a few of you already have, so thanks!
TL;DR: use vh/vw CSS units in your bookmarklets.

I have a 15" MBP (older than retina, but higher resolution than the default configuration, 1680x1050) and another laptop with same screen size and even higher resolution (1920x1200), and most of the time I need to zoom in to comfortably read text for long periods.

I also have some grips with contrast, so I ended up using a bookmarklet that increases the text size and improves contrast, based on the Darken bookmarklet popularized in LifeHacker some time ago.

The interesting change is that since I browse with my browser window maximized most of the time, I took advantage of the vh CSS (vh = Viewport Height) unit to find the text size I'm most comfortable with, and then I can use the same bookmarklet in both computers.

Unfortunately VH/VW is relative to the window size, not screen size, so I wouldn't recommend using it for websites in general -- although for mobile web apps it should be a great fit!

The gist of it is:

font-size:2.5vh !important;
line-height:4vh !important;
background: black ! important;
color: #DDD !important;
text-shadow: 0 0 black !important;
Re: Google (et al), "I’m purposely focusing on companies that got it all wrong."

As someone who's hired hundreds of people and worked to build three startups, I am increasingly of the opinion that it's critical to carefully study the hiring practices of companies that appear to employ a consistently high level of talent, like Google. And Google's talent base was one reason I thought the employees of my last startup would be happy there, and argued (to me) in favor of an acquisition by them. (Virtually all of them are still there, too.)

That said, entrepreneurs should take with a grain of salt any definitive pronouncements about hiring practices. In my experience, hiring and organizational design are not solved problems yet, by any means.
Could not agree more. There's tons of value in using a standard, even if that standard is getting a bit long in the tooth.
Isn't this more the arena of a procedural than federal law? This definitely seems more feel good than reality. I believe the court precedent is called "legislative entrenchment"[1] which seems to prevent Congress from passing these laws that "bind" future Congresses.

So, to answer the Representative's question, it would appear that courts would hold this bill unconstitutional.

[1] http://www.yalelawjournal.org/the-yale-law-journal/essay/leg...
Yet another reason to allow the use of firearms: the sheer labor of killing an assailant (or worse, the ignominy of having been killed) with a kitchen pan! But a merciful byebye by bullet beats bludgeoning by bat.
but I only count one person as a true friend in whom I can confide my personal struggles.

For me, I wouldn't even share my struggles with my best friend. It's hard to explain exactly why that is, but I don't think I could do it. Some things it would be easier to tell a random stranger at a bar... maybe because they don't have any expectations of you, and you don't have to worry about a feeling of letting them down, or disappointing them or whatever.

Having to maintain a never-ending facade of success and happiness really is draining.

No doubt.
My only worry is how long it'll take for ES6 to get adopted. It's one thing to write a spec and implement it into the compiler yourself...it's another thing to write a spec and wait for several key browsers to implement it.
Eh. I think he complains a bit too much, but consider the reverse direction. Why do employers get to be such dicks?

This doesn't happen very often, but every once in a while I get one of these "oh we're so interested, you're so great, you did so well in the interviews ... <silence on the line for 3 weeks>".

Or, when I bother to write you a cover letter, you can bother to write me back 2 sentences, even if you don't want to hire me. "I'm too busy" is not an excuse. I'm busy too! If you can't take the 30 seconds to copy-paste a nicely written canned message and edit it up to let me know you want / don't want me, then you suck. It's just common courtesy, and you're not exempt from it.

You also can't pressure me to make a decision once you've made an offer. I'm going to shop around, just like you shop around. You probably don't have a hiring emergency for the one junior position you're hiring me for, so shove it. Or just hire someone else, but quit calling me to pressure me. I understood the first time. I almost fell for this when I was fresh out of college.

You also really shouldn't be claiming IP rights on unrelated things I work on out of office. That's my business and my work, and I shouldn't need permission from you to own it myself.

Where is the decency? I see this post as a reaction to that frustration.
Too late to edit, so I also wanted to add that my intention with my previous comment is not to create an "us-vs-them" dichotomy, but to try to make the debate more inclusive by teaching everyone how to be safe around guns and how to recognize someone who is not being safe.
We have it easier than he does, but I'll tell you what our practicals look like:

* We test a lot of web applications, so we rigged up a sacrificial web app that we run on random EC2 instances and have candidates take an hour or two seeing what they can find in it.

* We test a lot of crazy custom client/server stuff, so we built a client/server system with a custom protocol that we have candidates reverse and then attack; we tried to calibrate this so it'd take less than 2 hours to beat.

* We write a lot of fuzzers, so we have candidates write a fuzzer for a file format.

Key attributes of good practical tests in our experience:

* They can't take too long to complete.

* They have to relate somehow to the actual work candidates would be doing within the first six months.

* They have to produce results that are objectively comparable in some fashion to those of other candidates, so we can learn from the trends. This is probably the most important thing I've learned about hiring in the past year.

We'll probably swap the fuzzer challenge for a memory corruption challenge sometime this quarter, because the fuzzer scores high on the first two attributes and low on the last.

I'd love to do a crypto challenge (mail sean AT matasano dot com if you'd like to do a bunch of crypto challenges, by the way; just say "Thomas told me to mail you"), but they score low on the first two attributes.

So if I was doing engineering interviews again (About 10 years of my career were as a full-time dev), I'd probably look to:

* Taking a time-inefficient algorithm and making it faster

* Taking a space-inefficient system and making it tighter

* Writing an importer for a specific file format

I agree that actually asking candidates to jump in and produce code for issues in Github is a losing strategy. In particular, because you're making it unnecessarily hard to learn from your hiring decisions; when you look at someone who is kicking ass on your team, can you go back to the hiring decision that selected them and see whether they outperformed or underperformed a metric and adjust the metric accordingly? If not, your hiring process is suboptimal.
I have just gone through the scanners this week, and will do so again next week; I find it more annoying then anything else. However, I do find myself thinking that the Greyhound buses of 30 and 40 years ago had a lot to be said for them--no-hassle travel, and for that matter comfort at least equivalent to coach seats with the current spacing.
I agree, and note that Google also has radically different hiring challenges than a startup does.
It's very useful. I noticed that it doesn't show Xcode in the auto-completion list, like it shows Visual Studio, Vim etc.
Chrome: http://i.imgur.com/VBgcURG.png

IE10: http://i.imgur.com/ZBrhDoS.png

Firefox: http://i.imgur.com/ROwDLkb.png

Chrome's text rendering has been pretty broken on Windows since September 2012-ish. There are lots of long bug reports on Chromium's tracker with little effort to fix them. Custom fonts render too thin to the point of discontinuities in the glyphs. The blitting algorithm was messed up so non-black text is often rendered a significantly different color than is specified in the stylesheet. High DPI support is nonexistant (while it was supported for Mac and Linux quickly), so rasterized text is simply scaled up by fractional multipliers, which makes it terribly blurry in both the UI and webpages.

I can only imagine that so many on the Chrome team are running Macs and Ubuntu that they don't see how terrible their software is becoming on Windows in fundamental ways.
I facechaired. You know, when facepalm is not enough?
That was my experience at Amazon as well. Most of the interviewers were very good and the questions were a reasonable judge of skill IMO.

I didn't get an offer (understandably so) but I thought the interview was good.
I couple days ago I wrote something to the effect of "There are genuine culture fit issues in startups, but the term culture fit has become so poisoned that we're probably going to have to invent another term for them", and this is exactly what I meant.
Hey mgkimsal, I remember when you were doing something like that before. I would probably actually want to get involved in such a group. I'm about to head off to Chicago for 3 months for a consulting gig, but when I'm back in town, I'll get in touch.
My machine has 16GB total. I give XP 512mb and 1 processor/core. Ubuntu/CentOS 2GB with 2 processors and 2 cores, OSX has 4GB also with 2 processors and 2 cores per processor. I actually have 2 XPs, 1 with IE6 and another with IE7. I've noticed a bug or two that IE9's developer tools didn't mimic exactly, that or it was a combination of XP+IE6/7. Either way we had a bug once that couldn't be reproduced in IE developer tools but we could see it in BrowserStack.

I've not tried a beefy 8 core OSX to try Final Cut Pro on yet, that would be interesting to see performance output.

All VMs run in bridge mode, connected directly to network so they have their own static IPs, makes it nice if I want to connect to a database on a VM

I also bought a separate SSD to run all these VMs off of

Note, that if you prefer OSX to Windows from a UX perspective, you can do the same thing with VMware and run Win7 in a VM. Really we all want linux for coding but a better desktop of our personal choice without having to read a ton of docs and deal with random bugs/gotchas for specific this or that's.
Ah, I'm disreputable and dishonest, too. Got it.
> Why exactly?

I haven't spent the time to stay up on codec development. I by all of my music in a physical format (usually a CD). I like the redundancy and the DRM free-ness of it. The last time I seriously investigated (and ripped the bulk of my library) was in 2005 when I was also active on Oink. The prevailing opinion then was that EAC with LAME and VBR was the best trade off of a secure rip, high audio quality and small file size. To let iTunes rip with it's default AAC codec produced to many errors. Also, at the time I was on a Windows machine and iTunes was so bloated and slow I refused to use it. I had an early iPod with Rockbox which freed me from the need to ever use iTunes.

When I got my MBP, I initially used RubyRipper. Then I found XLD and have been happy with it since (using LAME+VBR settings).
My apologies if I came across this way. The intent was not to whine about var or function declaration, but rather to provide clear direction about a standardized "okay" way of doing these things without causing yourself undue headaches.

So please don't interpret my calling these issues out as whining. Just trying to make new people aware that they are there. :)

If, on the other hand, I am legitimately WHINING and not realizing it, also feel free to tell me where so I can fix it. Thanks!
Cant wait for the Chernobyl Country Park

Actually, the Red Forest in Pripyat is a place where many people can't wait to go. The exclusion zone has created a very interesting nature reserve.
CoffeeScript can't target ES6 while maintaining backwards compatibility

Is that really true? I mean, it is not as if JavaScript is a subset of CoffeeScript. [1]

It seems to me that the worst case scenario here (for CoffeeScript) isn't backward incompatibility, it is drifting further away from the JavaScript syntax/grammar than one might like. Take the `for/of` concern raised in the thread. Why would CoffeeScript need to change its semantics to match that of ES6? ES6 could introduce a new and different meaning of `for` and `of` (whatever that is) but CoffeeScript could keep its meaning for `for` and `of` (whatever that is). The problem, if any, will be in "wetware".

Isn't the analogy here something like

CoffeeScript is to JavaScript as Closure is to the JVM.

Does Closure break if the JVM adds new features? Why would we expect CoffeeScript to?

[1] Excepting the back-tick delimited escaping for literal JavaScript, but that's not an issue here.
I base it on the panic-filled threads I see in places like Warrior Forum and Blackhat World every time Google changes something.
Since we're using anecdotes - I know and go shooting with a lot of people, and I don't know a single person who only owns 1 gun, it is either 0 or 2 or more (I personally own 3).

The reason is that different guns have different uses. If someone is concerned about personal protection, they'll have a handgun. A big rifle is useful for hunting or just messing around, but the ammo might be expensive (ammo for my M1 Garand is over $1.25 per round!) so someone might have something like a .22 rifle (ammo has historically been less than 10 cents per round) that can be used inexpensively for fun. If you hunt birds a lot and/or like to shoot clay pigeons, you'll also have a shotgun.

3.3 seems pretty reasonable to me.
I stumbled upon the last printed edition of this (ESR's version) at a bookstore in high school. I had dabbled with programming on and off since elementary school (back when that was unusual!), but now I was seriously getting into it.

While almost none of the terms in the book resonated with me as anything I had heard before, I strongly identified with the cultural aspects described in the book. I suddenly felt like my ways of thinking about computing, and about the world in general, were in fact not that strange, but shared by a lot of people who were into programming.

The book introduced me to many things that I went on to become more involved with; at least indirectly due to the book: learned LaTeX, Emacs, and Lisp; studied Knuth, reading carefully until I earned a check; volunteered for GNU, resulting in working directly with RMS.

As a technical resource, the book is close to useless now. But it was mostly useless when I encountered it. Maybe there's still some value left in it somewhere...
You can't find something which is not there.
Show HN: A UIImageView subclass that ignores touches on transparent pixels
There are also a limited number of public site tours each year, focusing on the B Reactor. (The first full scale fission reactor in the world.)

http://manhattanprojectbreactor.hanford.gov/

I've gone twice and it is really fascinating. You get to stand about twenty feet from the face of the reactor core, walk around the control room, etc. I have some pictures and video I can share if anyone is interested, although I'm sure some Googling can turn up lots of them as well.

One of my favorite anecdotes is that the valve covers for all the cooling pipes are open and have to remain that way so that the Russian inspectors can verify each year that there is no evidence that the reactor has been in operation. (Not sure if these inspections are actually still happening.)

Also for arms control purposes, there is an open pit elsewhere on the site where decommissioned US Navy reactors are stored. (Russia can monitor the number and position of them via satellite.)
You can buy dual monitors for a price of a cheap tablet.
Haha wow - sorry, but if you think you can create a "better Google" by limiting the scope of searches to specific sites that you've selected ahead of time, you're missing the point of the this entire decade.
You misspelled Google in the third line of your article.
Enterprise software is a game; corporations are just really boring LARPs.

pro-tip: 5th level marketing droids can be defeated if you ask them to sell something to themselves...
I really didn't want to write that. Ignorance is never really a good solution. :)

But from my experience, someone who is coming into JS for the first time is probably not setting up a complicated object hierarchy - they're probably just trying to figure out how to bind some events to a DOM element and get some basic UI functionality. And they probably don't need to use the this keyword as much as they think they have to.

I completely agree that this could be a bad decision on my part, or at least a very controversial one. But I'd rather have truly new JavaScript developers focus on things like encapsulation and closures before they get too far into the this keyword and constructor/prototype.
Isn't the point of search engines to find sites you don't already know exist (or, more prosaically, have forgotten the URL for)?