skysight-inc/HackerNews huggingface dataset:
I'm going to ignore the bad assumptions based on the author never having used an Apple Watch, and address the heart of the matter: are smart watches "the next big thing"?

By the standards people use for Apple where the 2007 release of the iPhone, of course not. Very few products can completely rebuild the largest tech market in their image overnight. No other Apple product has done it—that's why so many pundits were disappointed with the iPad's performance as a new product even though it was orders of magnitude more successful than any previous tablet and made the category relevant in a way people had been trying for almost a decade prior. The Apple Watch just can't pack that much punch, because it's basically just an extension of your smart phone, not a new category. Frankly, I was the opposite of the author, I haven't warn a watch since I was a kid, and I didn't see the appeal of any of it.

However after receiving one as a gift, I have to say that I am subtly impressed with it. I don't think it's a life-changing device the way a smart phone is, but it can definitely has unique utility. The first thing the author gets wrong is the idea that it's all his phone apps and notifications shrunk down onto his wrist. Yes, a lot of apps rushed to release Watch functionality for launch day, but frankly, you don't want to look at most things on your watch. What you want is to show only the most essential notifications, and the apps which have something you might want to glance at. If you're receiving email notifications on your Apple Watch god help you, that is the path to a new level of distraction (I'd argue you don't want those on your phone either, do you really want to give the world more opportunity to distract you?). My advice on setting up the watch is to first turn off everything and then add the pieces you want one by one.

In the end I've found quite a few small but practical conveniences which are going to keep me wearing the watch for a while: taking a phone call from my wrist when I'm sitting the car and don't want to fish into my pocket; telling siri something on the fly; responding to a text message with boilerplate responses; haptic feedback for turn-by-turn directions when cycling; having an "urgent" level of notification so that I can pay less attention to my phone without completely shutting off a given lower-priority notification; reminder to stand up and walk around once an hour; and last but not least, checking the time is actually more convenient when you don't have to pull a phone out regardless of how adept we have all gotten at that maneuver.
I read that as "But 9 times out of 10, [when I wanted to respond to notification,] I still had to pull my phone out". Maybe I'm wrong, but I'm also surprised anyone would respond to 90% of notifications - 90% of my notifications don't even have a way of responding to them (app update, nearby fire, calendar reminder, your order's been shipped, etc.)
Do you know what those cloverleaf shaped metal beams are called, and how you can learn more about building hardware prototypes with those kinds of products?

I know very little about mechanical engineering and hardware prototyping, but I saw those metal thingies about a year ago in a DYI tinkerer community (it was used in a DYI 3D printer), and I have been wondering about that topic ever since.
Using the log domain is cool but log summation still has the same problem. Logs just transform numbers into a different range, they don't magically add more bits of precision. That is adding a very small number in the log domain to another much larger number in the log domain, will just round it down.
Why can't those who want to use Python3 just use 3? Why do they have to push the rest of us over?
This read as war against the silent majority to me.

The transition has failed. Python is now 2 separate communities and we only have the 'leadership team' to thank for that. Until they make more compromises this will continue.

That ~17% userbase is your new Python3 community.
When you are an interviewer, remember you are given power to determine whether people get the job and are their gatekeeper. You are determining career paths and opportunity. Don't make the interviewee do things they wouldn't do on the job but find out who they are. Even when you hire you really learn who you hired in action, even if you have a circus hoop based interview process, the real test is the first 2-12 weeks.

It is sad some pedantic people can determine your success on a one off trick question and whiteboard exercise interview judgement like a rogue war tribunal rather than your work.
I think you'll find startups to be more flexible on this, with the downside that they are often still figuring out their own processes. At Nylas we ask a range of questions from high to low level but all related to the kinds of problems engineers would be working on - for example, if you'd be working on the platform team, we ask you about things like concurrency and locks because we actually use those, not because we read some CS 101 textbook and thought they'd be cool.

Sometimes, the goal of an interview is to get you to think about something you don't know. If you knew every answer to every interview question perfectly, what does the interviewer learn? It's quite enlightening to get out of that comfort zone and see whether someone pulls an answer out of their backside, honestly says that they don't know, or somewhere in between. I'm not saying all interviews should be like this for everyone, and I think interviewers should be very much aware if that's what they're doing -- which I think is less the case ("oh, the candidate didn't use a linked list but solved the problem some other way? 0 points!").
Not really a function of the UI...

Personally, in the latest updates I've found it much harder to get to whatever list you're playing from.
If you are looking for a job, I cannot recommend giving technical presentations at user groups highly enough...

As you have pointed out the dynamic of interviews sucks. A potential employer will be seeing dozens of people for a position and comparing you to all of them. You will be talking on a topic decided by the employer which you may or may not know anything about.

Giving technical presentations inverts this dynamic beautifully. Instead of one position and many candidates, there is one of you and potentially dozens of people in the room looking to hire. Instead of doing white board problems in a domain you may not know about, you will be talking on a topic that you KNOW MORE ABOUT than anybody else in the room! Instead of speaking off the cuff in an interview, you can polish your presentation for weeks in advance.

I am a freelancer. Every time I have done a technical presentation at a users group I have picked up at least one job out of it. Many of the people at the users group are looking for employees. They are always disappointed to find out I'm not looking for a full time position.
Here's one interesting strand you can pull on..

http://en.m.wikipedia.org/wiki/Psychogeography
I have to agree. Part of me wonders if this is a generational/cultural/personality thing. Perhaps some of us are in that age group (or culture/subculture or personality...) where smart watches seem alien (or frivolous). I've always loved watches, particularly analog watches for similar reasons to you, but I also suspect I'm definitely not in the target market for smart watches. You might not be either.

I also have a special fondness for ultra-thin watches which are sometimes hard to find even as analog watches, so there's that.

While I won't be parting with my archaic time pieces any time soon, it'll be interesting to see where the technology goes.
"Berkeley engineering students respond with automated bong."
What's the Point of a Professor?
The funny part about this is that the founders of these startups, who in many cases wrote the code that got the funding to start hiring programmers, couldn't come close to passing these interviews themselves. They also in many cases aren't very good programmers, and are looking to hire people better than they are for rewards that won't come close to what the founders receive.

Case in point: I recently emailed a simple question to the Magic (getmagic.com) folks. I asked why they didn't make the short code on their home page (which used to be a 10 digit phone number) a clickable SMS link. It seems obvious right? They are asking people to send them an SMS. Why make people either memorize/type or copy/paste? But not only did they not think of it, they didn't respond to my email and haven't implemented it. These guys basically got a check for $12M at a $40M valuation after 1 weekend of buzz and couldn't figure this out on their own - and either could the VC's that wrote them the check apparently (and they're in charge of billions of dollars).

So walking into these interviews (especially at recent startups), understand that if you have a bad interview experience, then the people that are already there probably aren't very good at what they do. Bad interviews tend to be conducted by bad managers/coders that are suffering from extreme bouts of justifiable impostor syndrome. If you are not hired after a bad interview experience, it's probably a good thing, because you wouldn't want to work everyday with the people that designed that experience in the first place.
Yah, I've been interviewing a little lately, and while I understand the need to see if the person can code, white-boarding isn't really it. I've been doing this long enough that i've been the guy on the other end of the table more often than not.

Anyway, over the past couple years I've steadily moved into the take home test camp. These can be tweaked such that its apparent if someone tried to google an answer and use it.

But that said, I'm not sure I want to be implementing a "challenging" project for a job that I might never get. How much time do you think someone should be expected to put into a project for a job they might not get. How about if they are interviewing at a half dozen places?
> One of the problems the author mentions - iMessage received and a notification coming to iPhone, iPad, Watch at the same time - actually doesn't happen. Apple was smart enough to ensure the notification only goes to the watch if the other devices are not active (and the watch is being worn). If you are on the phone, you get the notification there and not on the watch. It's beautiful and one of those little things that make a big difference.

They should add a mechanism to do this for all notifications. It could be a headline feature in an OS X/iOS update.
> But all three of us are very reluctant to start interviewing because we all know how much interviewing really really SUCKS.

Have you interviewed much recently, or are you going on what you hear about bad things in the interview process? (The bad stuff tends to get more mentions.)

It might not be as bad as you think. Yes, some amount of whiteboard work is common. But it shouldn't be about "topics you may or may not know" - that sounds bizarre to me. You should be tested on a language you know, and on a problem that a reasonable person would be able to solve. Also, the focus is often on how you approach the problem, not if you write up a perfect solution or not.

Overall, what you describe sounds like a horror story ("one interviewer wants us to code a particular dynamic programming question the way they are picturing in their head"). I don't think that's as common as you appear to think.

It sounds like you are reluctant to even start interviewing. Why not try, and see how it goes?
Spotify does allow cache-ahead on mobile. It's a premium feature, and it's well worth the $10/mo.
Go have coffee (or whatever) with your colleague and have a 1-to-1 conversation with them saying you want their feedback on code. You want their expertise to make you a better software developer. Even if you are better at this than they are, you can learn something from the sharing.

The team’s lead should make sure that the individual in question knows that software development is a cooperative process and that code review helps build the team.
If you or your friends are interested, you should check out Matasano (disclaimer: I work there). Our hiring process is much more focused on work-samples, and the in-person interviewing is pretty laid-back. We're also very up-front with candidates about what to expect and where they are in the process. Check out our careers page:

http://matasano.com/careers/

Feel free to drop me a line if you (or anyone else) has questions - I'm andrew AT matasano.com
I'm well aware of the history of the US meddling in Latin America. On the other hand, many governments in Latin America have been over-eager to just blame external forces for their economic problems and attempt to solve them via expropriation. I still hear this argument from supporters of the Venezuelan government; you don't have to be a raging capitalist to think that the government of that country is catastrophically incompetent. Last time I looked they were nationalizing supermarkets.
You can hide the "Friend Feed" with the View menu, and your settings can disable social features AND announcement notifications.
The 6502 was special because it was so, so much cheaper than its competitors, at least initially, making home computers practical. And that's probably why it was so limited.
Accused of Spying for China, Until She Wasn’t
Thank you for the link. Very informative.
Balancing the critique with some positive feedback - parts you liked, appreciation for the features shipped, etc. - is one idea I've seen floated around, for a particularly touchy coworker.

Also, generally managing tone - "Looks good! Don't forget to add the doc comments on functions X Y and Z" vs "Why are X Y and Z missing doc comments?". Both have the same fundamental information (X Y and Z could use doc comments), but:

With the former, you're acknowledging progress, a "good" first draft, and pointing out what remains to be done in an ego friendly way ("I know you're good enough to make this even better") that doesn't demand a response.

Meanwhile, the latter demands a response, all of them negative. Either "it doesn't need them", or "I forgot them (because I suck)", or silently ignoring the question. None of these are ego friendly.

.

If the code just plain sucks, however... I'm not really sure what to do.

And if the coworker gets defensive even with positively slanted feedback... maybe there needs to be a conversation with them, to try and shift their mindset. Show them you get things pointed out in your own code reviews, that it's a team game where everyone is just looking out for each other. That bad code doesn't mean they're a bad programmer, that critique of their code isn't a critique of their skill, that everyone gets blind to the problems in their own code and benefits from a second set of eyes.

Maybe get them in your shoes - helping critique someone else's code, and help explain that they're not being an asshole when they point out edge cases and ugly code, but that they're being an asshole to future them when they have to go back and add a feature, fix a bug, or handle a corner case they'd missed.
Hired.com. If you don't want to deal with a lot of BS and are able to make decisive choices, you can't go wrong.

Otherwise, you end up interviewing at places were recruiters are just trying to get another body in the door and half of them are not prepared.

I was very skeptical but it got the job done.

http://join.hired.com/x/XfELvW if you want to toss me a referral but honestly, it doesn't matter to me either way. The quick decisive moment is the hard part but Hired.com really does take care of the rest.

Also Mattermark is hiring and I would encourage anyone interested in full stack or dev ops to apply: http://mattermark.com/jobs/ (other business roles are on there too)

Why Hired.com is good: if you are a bad negotiator, you'll learn very quickly that you need to filter out jobs early on based on salary expectation. Nobody talks to engineers/geeks about that. But once you go through the hired.com process, you realize that hey, it's an open field -- you can establish up front what your criteria are in terms of compensation and discuss that early in the potential interview process. Because time is money, hiring is complicated and compensation is all over the place. You are the best judge of your value. It's complicated. But you are also the best judge of what you'll accept in terms of tradeoffs (cash vs equity).

Everyone single person who contacted me via my Hired.com profile was a founder (or a recruiter pretending to be the founder). Either way, I got a great summary of what they were looking for along with up front knowledge of the compensation (so I knew we were on the same page). I got 11 or 12 offers and I did 4 on-site interviews. I ended up at a company that I am very happy with.

So I recommend it to those that don't have a perfect network. With a great or perfect network, you can likely do better. But like online dating, Hired.com exposes you in a way that optimizes presenting your value to potential employers. I think that most of us engineers do not have a perfect network and/or do not know how to leverage that network so it is a huge win.
Basically, interview questions at such companies test your knowledge of basic algorithms and data structures. If you have problem with answering such questions, I recommend you taking a couple of courses in these fields on Coursera or read basic algorithm books (and of course solve exercises).

I interview people a lot, and I always ask such questions. I just don't want to have people who don't know how data structures they work with every day work and which time complexity they have. You would be surprised, to see how many people don't know the basics.

Often companies, like google, and facebook ask brain teaser, i.e. tricky questions with tricky answers. I agree with you that such questions are mostly useless and make people feel stupid, especially if they didn't have experience with them.

P.S. It would be nice if you provide examples of tasks which you against, so that everybody who reads this is on the same page.
I realized that I missed the part that he's talking about log2(x) rather than log(x+1), which changes the interval.

Since MiniMaxApproximation gets quirky when the function is 0 in the given interval (it minimizes the relative error, so a division by 0 occurs, unless you cancel it), I'm rather using the interval [0.25, 0.5] with t=1/4:

-3.64631 + 7.93796 x - 5.30406 x^2

This gives a maximum relative error of 0.00334047, which is still an order better than his.

As for the (2,2) approximant:
(-5.83261 - 16.7012 x + 22.394 x^2)/(1 + 11.2638 x + 7.81124 x^2)
max rel error: 1.69763 10^-6

I checked several other values of t, and the max rel error for (2,0) approximant is roughly the same. This leads me to believe that the reason he is getting 10 times larger error is because he is imposing that errors should vanish at certain points. Not only this increases the max rel error, but it also distorts the smoothness of the function in a bad way (the kinks in the plots are a bad sign in general).
Oh cool, thanks for making it!
For me, my go-to tool for stuff like this is Python. It's been a while since I've done an ncurses tool with it though, I'm not sure how painful/unpainful it would be. It's easy to install on Windows, and generally just works out of the box on OSX and Linux.
I have, and it was more an attitude/cultural thing: the reviewee took any criticism very personally, and was hence super defensive and unlikely to change anything anyway.

Honestly, I think it's actually really, really hard not to react that way (to varying degrees) especially as most code-reviews basically come at the wrong time: you've already written the code, it works, it has glorious unit-tests -- who cares if it's a for vs while loop or whatever. It's actually even worse if there are serious design or maintainability issues, as that's even more code to re-write/"fix".

Personally, I really like having code-reviews -- it's better to get rid of serious problems if they're there. However, I've found a lot of reviews to be rather worthless "rubber-stamp" exercises -- especially if the dev team has just been told Thou Shalt Do Code Reviews Because Reasons! (I've also found the opposite, for sure: getting nice solid advice or missed cases; but these are invariably with other developers who want reviews no matter what management said).

...but all that said, I think so-called "code reviews" really work best if they're spread out over the coding (unless it's really small chunks at a time) -- a bit of pair-programming (or "hey, can you help me with ...") and design (or whatever you call "early on in the cycle") reviews make it a hell of a lot easier to take a different approach.

I think they used to call this "collaboration"?

Companies that just blast out a "new rule: everything gets code reviews!" memo without helping people understand the benefits, and how to do more "along-the-way" validation of design, refactorings, etcetc are always the very worst at having code reviews that are in any way effective. At such places, I find "code reviews" devolve into either useless "rubber stamp" affairs or something like what you describe. Or worse.

Also, if you have "Junior Developers" blasting out code for a couple days (or more!) with no adult supervision with a hope that some last-second "code review" procedure is going to equal amazing code, you're doing mentoring wrong. It's a lot nicer for everyone involved if there is someone sitting down with (or chatting or watching-the-commits-of or whatever works) the less experienced developers. These mentors should be providing hands-on, practical advice as they go. Some devs might need more hand-holding, some will need "a plan", maybe you need to sketch out classes or method-signatures for them, perhaps they need a bunch of half-day tasks written down, etc...Such mentoring should, IMO, be what your Senior Developers are spending a decent chunk of their not-coding time on.
As others have said, you're making a fair amount of assumptions about the way the "median" interview in Silicon Valley goes. Interviewers tend to be less concerned about whether your code matches the picture in their head as much as whether your code works and isn't doing anything unduly stupid. (Being aware of performance concerns and how to optimize for best O(n) values is a huge, huge deal.)

The biggest challenges I've personally noted are these:

(1) Despite all the (probably sincere) claims many startups make about not looking for computer science degrees, coding questions are absolutely, positively optimized for computer science majors. I have lost more than one job because I'm "not strong enough with algorithms." For certain kinds of positions that's assuredly correct -- the engineers where I work now, who are building a high-performance realtime database, for instance -- but the number of times I've needed a routine to return a list of strongly connected components in a network graph as part of my 15-year web development career is exactly zero. (I have, however, needed it for a coding interview; as it turned out, writing that and a shortest path method and a simple parser just got me to the final face-to-face interview, where I was asked three or four more algorithmic questions. I did not get that job.)

(2) I increasingly see jobs requiring experience that I literally cannot get without already having one of those jobs, i.e., "must have already worked with high-performance clusters and web sites serving millions of hits a day." It seems like the only way to get that experience is to either start a startup that gets to that point, or get an internship at a company that already has it (which is not an option once you're out of college).
i don't think you understand the question. the problem presented is about the interview itself and not about how to find a place to interview.
Yes. Now I regret I upgraded my Ubuntu to 15.04 Since there is no support for cuda from NVIDIA, so is the Intel graphic driver. If you are using an OS without third party applications, I think it should be fine, but that is not the most case.