skysight-inc/HackerNews huggingface dataset:
> However, a drone flying a mile in the sky over the entire city does nothing to further that familiarity.

I think this is where we actually start to diverge. Aerial surveillance (whether by drone or by manned aircraft) is an excellent way of directing limited police at actual problems (hopefully before they become crises) during tense situations.

As only one example, being able to see that a given protester group was substantially "imported" from out-of-town might change the appropriate response dynamic significantly from a protest where the protesters are all pouring onto the streets from their own communities. Beat cops should be familiar with the members of the latter group at least, but how can they be familiar with people who come in from out-of-town?

As far as legality, things may change with future rulings but as of this point the question's already been put before the Supreme Court, and the answer is that aerial surveillance is legal -- you just can't use sensors above-and-beyond the types of senses a patrolling cop might have walking around the street.

So perhaps high-zoom lenses would be ruled against at a court level (things like IR have already been struck down), but as a general principle the law is already clear on this (in favor of the police).

> I fail to see the connection you're drawing between proles and this situation

The proles were kept more or less completely alone to rot in their own slums as long as they didn't do anything to draw the attention of the Party. They didn't even have to worry about telescreens, they were simply apart from the government completely for better and for worse, left to fend for themselves as best they could.

In 1984's world that would probably be a better fate than being in the outer Party, but my point is that in the real world one of the responsibilities of functioning governments is to forestall security crises by acting before crises appear. You can't do that without at least paying attention to what's going on outside the police HQ, and during riot situations there's no way to stay aware of what's going on in the community by just sending out a beat cop to go make a round.

If we were talking about a normal day in a normal city then I think I'd agree completely that police shouldn't just be having drones hover around taking livefeeds of downtown (though it would probably be legal barring future statute changes or court rulings). But Baltimore during the riots wasn't a normal city going through just another day, there were literally state military forces walking through the city to help keep order...
Boost used to have a minimax approximation algorithm in its codebase. Unfortunately, nobody knows enough about how it works it to maintain it, and you have to look in much older releases of Boost to get it.
I interviewed for Google two times, FB one time and Amazon once. I hated every single one of those interviews. I got another call from Google and I told the guy if he is expecting me to go on a 2-3 month interview loop with one day of hoping to give the answer the interviewer wants (on those situational questions) than what makes sense in the context with limited info, deal with guys who think they are the gods of the universe ... i am not interested.
Thanks for replying, I was genuinely curious.
Why we should't judge a country by its GDP
I found that group chat on Facebook doesn't work through XMPP.
Like OP this (mostly) just works for me, but it's not as "perfect" as they make it out.

The first message in a conversation will sometimes go to all my devices regardless. Once I respond on a device it figures things out and only notifies that device from then on. However, if I don't acknowledge or answer the message relatively quickly it will try the others again.

So maybe you aren't responding fast enough?
Yes, but it precludes easily sharing routines from different projects. I remember being frustrated a number of times because I didn't have source for something that conflicted with another library I wanted to use.

(Just to add to this, that hundred or so free bytes in the $0300 page IIRC was also a problem. Lots of utilities used it, so I remember there being a lot of conflicts there too).
I get many emails from recruiters but ignore them because I simply don't know what to expect from interviews - not really interested in being asked to solve someones' pet algorithm on a white board. I wish there was a list of companies who do project based interviews where they ask you to work on a small but challenging project related to the actual work you'll be doing, and then bring you to an interview to present it and defend it in front of your potential future colleagues.
Definitely. I expected to think that smart watches were dumb, but found otherwise. My Pebble lets me ignore my phone more.

The notifications I allow to my wrist: phone calls, text messages, and calendar alerts. 90% of the time I do nothing more than acknowledge the alert or send the call to voicemail, meaning I can leave my phone in my pocket.

I like that because my phone is a source of distractions. If I take it out to see what an alert is about, I find it too easy to check other notifications that have piled up, or to go and look at something entertaining.

I don't think this guy has a technology problem. He has a focus problem but hasn't realized it yet.
This is my defense of whiteboard interviews.

- They are aimed at identifying smart people who know the basics of coding and algorithms. They are intentionally not domain specific. In my experience, smart people can pick up all the other details over time. I've worked with many people who switched languages and within a few months were (for the purposes of their job) as good as someone with years of experience. Similarly, version control, testing etc. are things you can learn on the job.

- They have worked for major companies. Look at the share price of Google and Facebook over time, or the general feeling that they are successful in their goal of hiring the best people.

- They are fast and scalable. They only take as long as the interview, and they scale well because it's easy to compare the notes of different interviewers. The process takes about 5 hours for the interviewee, and about 10 hours combined for the interviewers.
FWIW, I just accepted an offer from Instacart (my first day is Monday). Phase 1 of the interview process was a 10 minute coding problem on Hacker Rank. Phase 2 was building a small web app in half a day on my own time from my own apartment. Phase 3 was a 10 minute face to face coding problem that I solved using my normal programming environment on my own laptop. There were also conversational interviews with several people. No whiteboards were involved at any point.

They (er, we) are still hiring: https://www.instacart.com/jobs/engineering
I believe the idea is as follows.

1. Suppose you have contributed to projects A, B, C, D, and E.

2. When someone looks at your profile, they see A, B, C, D, and E listed in a vertical list, apparently sorted by how many contributions you have made to each.

3. You decide that you want the world to know you disavow your contributions to one of these, say, B.

4. You fork the project disavow/above-repository.

5. You make a branch, make some commits, and push them, and then make a pull request. Apparently disavow/above-repository will accept your pull request.

6. disavow/above-repository then appears in your contributions list.

7. Keep making commits to move disavow/above-repository up the list until it is between B (the project you wish to disavow) and C.

8. Now when people look at your contributions list, they see:

A
B
disavow/above-repository
C
D
E

I'm not sure what you are supposed to do if you want to disavow a second repository. Maybe they need to make a disavow/below-repository project too.

The idea of disavowing contributions is an interesting one, although it is probably something best handled by convincing Github to support a mechanism for it. More generally, it could be useful to have a mechanism to explain your relationship to a repository you have contributed to. On a project page, you should be able to view the explanations from all the contributors, and on a person's profile, the list of projects they contributed to could also list their explanation.
I've never interviewed with Google, but when I interviewed at Microsoft I had a single interviewer (of five) ask me to write code on a whiteboard, and it was a total of ten lines or so.
If you feel like it, when you do, please let me know how it goes. I'm really invested in trying to make that particular leap a success.
I’m Dumping My Apple Watch
I actually don't think it's possible. If I remember my OPWACHEM course correctly, if the media you're thinking of did wash onto the yard worker he'd have been severely injured by radiation exposure, and not just quickly bumped up to his maximum lifetime allowable exposure. It is indeed extremely nasty stuff.
Stop looking for jobs in Silicon Valley.
They may have been asking you to talk about UIActivityViewController: https://developer.apple.com/library/ios/documentation/UIKit/...
I like this idea, my own outlandish suggestion has been to just drop it off at a subducting ocean trench and let it return to the mantle. It's only slightly more feasible though, and getting the casks to stay intact until they're deep enough would be a difficult engineering challenge.
+1 I'm currently dealing with this. The individual doesn't offer feedback on my code when under review, so it appears like a personal attack.
There are 2 problems these days :

1. Companies think they are hot shit.

2. The interviewers are all pretty junior and actually have no idea what they are looking for, so instead they try to grill everyone in some perceived gauntlet.

The reality is that companies need experienced people (of all ages). And that the gauntlet exercise is supposed to do 2 things - first of all, demonstrate that people know a bit about some kind of software development / CS experience. Second of all, and this one is missed a lot, its a chance to see what someone's personality is like trying to solve a problem.

Experienced interviewers know that its not about trying to throw problems at people until you exhaust them, its about determining if you want to be on the team with someone when a difficult problem arises (and uses as a proxy for this, how do they react to solving a problem right now in front of you).

Companies are about culture - there are still companies out there that do have cool engineering cultures (and some of them are hot shit).
Dart's Macro Language
The UIActivityViewController was introduced in iOS 6. That interview took place during the iOS 4 timeframe.
The watch excels at glances. Anything that can just be glanced at performs better on the Apple Watch. An example is turn by turn directions. It's much easier to get them via the Apple Watch than look down at the iPhone.

> The Apple watch has to be activated to show you the time, while the Pebble always shows the time.

If the display was always on, it would be distracting, especially in dark environments (movie theater, concert, night time in general).

> The Apple Pay integration is interesting, but that hasn’t really panned out as something people really want.

Apple Pay on the Apple Watch is the easiest and fastest method of payment I've used. Simply double-tap a button and hold your wrist next to the reader. It's even faster than Apple Pay on the iPhone (and I can't drop my Watch), which makes paying with a credit card feel as slow as writing a check.

If every retailer offered Apple Pay, I would use it every time. It's especially convenient if I happen to forget my wallet.

That said, I hope the Apple Watch will eventually track sleep. I haven't found a good replacement for sleep tracking since Wake Mate shut down.
In what way was I lying?
Another thing to check for that I didn't see addressed is debug statements. There's nothing quite like seeing console.log("shit"); during a code review :)
> I'm not sure the Apple Watch would be so useful for a single person but for couples, communication is the killer app.

That's probably because you like to be "always connected". I'm not sure if I am an exception, but I kind of like the idea to take time off from the net, the phone and things like that. Having another device attached to you is another chain that binds you.
haha! The question we ask ourself now is: How is it possible we worked so long without it? :)
Email is pretty much here to stay. It is more that users and organizations need to "learn" how to manage emails better. Furthermore, email might not be the main way of communication with your customers anymore, but still will be one of the main pillars.

This is one of the reasons, why I started my 6th company called Helpmonks (http://helpmonks.com) in this space. It simply helps organizations to collaborate on emails. My company is not the only one in this space.
I've proctored a number of interviews for $BIG_COMPANY and they wanted whiteboard coding (yuck), so I made sure that my questions involved the whiteboard but zero coding. Without revealing my own secret interviewing sauce, I take people through an area that most software engineers use but are highly unfamiliar with: the linking and loading process. It works because it's such a black box with most people. I have them figure out how they would write a linker and loader. The people who score well with me never really thought about it before, but with a bit of guidance come up with a pretty reasonable facsimile of what such a system looks like for real.

Then I interviewed at a bunch of places. Most of them were fairly small and they universally used whiteboard coding, except when I interviewed for a specific team at $OTHER_BIG_COMPANY and didn't touch a whiteboard at all. I expect that if I wasn't interviewing for a specific team, I'd have had to use the whiteboard.

So yeah, sadly IME whiteboard coding is alive and well.
HOWTO Write Software That Uses Less Electric Power

http://www.warplife.com/tips/code/power/
I've been building for the Web since 1995.

Databases for web services used to really suck back in the 1995/2000 time frame. They were either difficult to use, or very expensive. MySQL gradually killed the bottom 2/3 of the commercial database market between ~1998 and ~2005 or so.

Simple interactivity on sites is incredibly easy now. Applets and Shockwave were horrible, due to performance issues (systems and browsers), general bugginess, and lack of consistent support.

RAM and storage used to be really, really expensive. When Excite wanted to test out how well the first version of their search engine could scale, they paid $10,000 for a 10gb hard drive (purchased by Vinod Khosla).

Using, controlling and embedding media on sites is almost an afterthought now, it's so easy. Real Media was satan.

Search was really bad until Google put AltaVista & Co out of their misery. Search spam ruled the day. The notion of just punching in a problem and finding a solution on Stack Overflow, ha.

Ten years ago, 20-50kb still mattered when loading a site. Developers no longer need to obsess about the size of their site assets (rather, more on how many and latency), unless they're getting really crazy about it.

Language options are so much better today than in 1995/2000. You can now choose from numerous good options, pick whichever one works best for you, and you can be confident that so long as you use it optimally, you're unlikely to run into big problems unless you're dealing with hyper scale services.

Collaboration capabilities are... well, drastically better now. Github, Slack, really easy and cheap video conferencing, large file storage & sharing, sites like Stack Exchange, social networks, and so on.

Bandwidth is dirt cheap; that doesn't really need an elaboration.

The countless cloud services have made prototyping / testing super cheap.

The rise of the internet service API, following fairly standardized approaches, has made interfacing with vast amounts of data very easy, very precise and very cheap.
Personal experience/ Ancedote about (2). Sometimes interviewers (may be new or inexperiences) just try to prove that they are hot shit. And feels like they forget that the objective of interview is not to establish who is superior rather if the candidate has the skills what they are looking for. This happened couple of times to me.
I would expect it to be full of tritium.
Not lying per se, but if someone pulls something out of there ass in an interview I'm giving that's a red flag for me.

If I am interviewing I don't do that without explaining that I don't know exactly what they mean, and if I have some idea of what they might mean I say that. Otherwise I say I'm sorry I don't know, and list it as something to ask about at the end of the interview (typically when you're given a chance to ask the interviewer some questions).
I agree that requiring deep code reviews on every code change is ridiculous.
Unfortunately, I have never seen a team that doesn't have at least a developer that is much worse than the average member of the team. He can be bad at abstraction, at design, at naming things or anything else. This developer produces sub-optimal (or even worse, incorrect) code that is hard to understand, maintain and extend.

I have observed that naturally, the other teammates will review the code of this specific coworker while not looking at changes submitted by good and reliable teammates.

I see code reviews as a tool to provide feedbacks to someone and help him improve the quality of the code he writes.
I'm genuinely curious why engineers would prefer to work on a project for an interview? To be tasked by multiple companies (presumably by as many as you are applying to) to spend 4-8 hours doing unpaid work on a project which is probably inane and most off all - completely useless for everyone involved.

If I've got 8 hours to spend I'd much rather contribute it to something that someone else will actually benefit from.
It is important that code reviews are public enough that people see other people review each other's code - a system where the only code reviews you see are the ones you do and the ones you get leads to poor expectations of what they are for.

Having at least two very accomplished and (culturally and organisationally senior) people routinely "model" reasonable review behaviour can be stunningly effective.

Also this is an area where frequent team conversations about what good code is outside a review situation helps to build a certain culture. It helps step away from nitpicking and arguing.
Good for you. Google can get away with this garbage because so many people would sell their girlfriend to work there. It's good to hear about people not taking their crap. There are plenty of great places to work.
I was under the same impression until somewhat recently. If I'm going to buy a watch, I want it to be a watch first, and "smart" second, and I was convinced that only the Pebble did that. I tried the original Pebble for a while - but lately I've been pleasantly surprised trying Sony's Smartwatch 3.

- Its screen is always on, and always readable to me - I'm not sure about this, but I think it has a variant of the Pebble's e-paper screen. I know Sony makes Pebble's screen.

- It has the highest IP water-resistance rating out of the Android wear watches (IP68, which is supposedly suitable for swimming), although not quite as waterproof as the Pebble.

- The battery can also easily last through a full day and night, in my experience, with about ~30% remaining for the next day. That's even less of an issue given that the battery can be charged up fully fairly quickly (can't quantify that any further at the moment, but it's always been pretty quick for me).

Now, if you swim, like you mentioned you do, then the waterproofing thing might be a dealbreaker. But other than that, this Android Wear watch is almost on par with the Pebble as a "watch", and you get a bunch of added benefits (like GPS, which is great for running, better Android integration, touchscreen, polished voice interaction, etc.). IMHO, if you're just looking for a watch that's got some extra features, then the _original_ Pebble is great just because it's so cheap. But, if one's willing to spend more like $200 (Pebble Time), it's not much of a competition, unless you _really_ value the extra battery and waterproofing.

Edit: clarity.
No. It does not beg that question. http://begthequestion.info
Most new water pipes in cities are made from PVC, so it's not just what your house is made from you need to think about. I expect you could also find articles talking about metal leaching into water being bad too. Short of distilling your own water I don't know what you can really do.
If you know that your colleague is sensitive to what appears to be the overwhelmingly “negative” comments, make sure that there are positive statements. I had a code review recently for one of my guys that had a lot of comments that were style and logic problems.

When I finished the comments on the code, I made sure I added a comment to the top of the pull request (we use BitBucket) indicating that it was clear he understood the point of the code and had written a good first pass at it, but there were a few things that needed to be dealt with for idiomatic code.
"How do I quickly share pictures without having to worry to much about them sticking around"

See, to me that falls into the "problems I didn't know I had" - like for example a lack of a terra cotta animal that I can grow sprouts on.
Sounds like he told you exactly how you should deal with it. Stop focusing solely on on the bad things and mistakes: make sure to mention "hey, neat idea" or "this is pretty clever!" on parts where, you know, it is exactly that. Diplomacy is a useful skill.
Does anyone else have the feeling smart watches are a consumer created category? Meaning the public expected smart watches to be the next big thing after the smart phone so they became a self fulfilling prophecy. I mean, they really don't have much utility outside of fitness
Axe ads?
Yes. You can search Form Ds, which are public information.
Not really, unless I personally know the applicant. I'm notified when someone applies using my link and I tend to investigate the application and the person. If they seem to standout, then I'll pass my research on to the hiring manager.
The more you try to emulate reality, the farther from reality you get. That's why interviewing practices are so absurd today -- cognitive tests, personality tests, whatever work test that tries to assign a quantifiable score to an applicant.