kevinoconnor7

Not really. If you're in the very rare situation where you need to diagnose a bug in long-since dead code, you can just view repository synced to where the version was cut.

Thanks for calling this out: you're right. I don't think I highlighted properly what I actually wanted to highlight.

I more wanted to emphasize my view as a bystander at a very hectic point of their growth, not actually complain about the experience. It was an interesting experience to me, not a negative one.

I have no hard feelings about it and I'm sure things got sorted out. I certainly have no negative views of any individual I dealt with.

oops! I rotated my private key a couple years back and never updated that. Fixed!

Overall I don't think the total amount was excessive, or maybe just slightly. My experience has always been been technical phone screen or homework problem before onsite, but not both.

The real issue was how chaotic the process was. I had started out talking to an engineer that had picked up my application, but was handed off to recruiter only after the homework portion was done (said recruiter even mentioned that they had just been hired). The two technical phone screens also were two discrete steps (i.e. the second was only scheduled after the success of the first).

That was really the issue: neither I nor them knew how many more steps there were. It wasn't helped by having long periods of radio silence between each step either. But it was painfully obvious that they were scrambling to figure out how to scale their processes, so much so that it still stands out to me 6+ years later.

> How much time does it typically take (or should take) to complete a 'homework' project?

I was still in college at the time but I maybe spent 5-10 hours over the course of a week or so. I do remember it took a very long time for them to respond after I had sent it in though. I believe the project was to implement a basic web crawler in Go.

> Now yes I do understand programming is not the same but my point still stands why so many chefs in the kitchen?

After the homework problem I think that's where they were defining the process as they went. They seemed to be growing quite a bit at the time (IIRC when I was onsite they had just rented two more floors of office space) and I had bounced between a few contacts that were brand new to the company. The real struggle is that I never knew how many more steps were to come, and I'm not sure they knew either.

Though after the onsite they e-mailed me almost immediately to setup the call with Ben so I think everything had gone well up to that point. I don't think the call with Ben went poorly so my best guess is that they went with someone that had experience rather than a new grad.

FWIW I'm not actually bitter about this. I just found it to be an interesting snapshot of a particularly chaotic point in the company's history.

I remember interviewing with DO back in late 2014 and it was nuts! The entire interview process took ~3 months and it was clear that they were defining the process as they went. The entire process was basically:

  1. initial call with recruiter
  2. homework project
  3. call with engineer to discuss said homework project
  4. two phone screens with engineers
  5. onsite interview with 6 engineers

Finally I had was at the final step which was a call with Ben who was really interesting to talking to as we shared the sysadmin background.

They we going through some pretty crazy growth at the time so I forgave a lot of disorganization in the interview process. Unfortunately I didn't end up getting the role but I'm glad to have had that experience; it was definitely an interesting point in DigitalOcean's history.

Usually application fees are separate. Non-refundable deposits are fairly common for taking an apartment off the market while the application and lease are processed.

Here's my take, there's two parts of this story:

1) Their experience trying to rent a unit. 2) Their outline of the scam.

I'm going to take all of (1) as facts, albeit it's only one side of the story. So maybe parts are missing and it might be biased, but I'll assume the core points are true.

(2) is where things become less factual. A large part of their support for it being a scam comes from two parts: it could be profitable, and it appears they didn't sell any units that week. The problem is just because a scam is profitable doesn't mean it actually took place. If I get shorted change at the deli I can't call it scam simply because it was profitable for them to short me. I would need to show that the problem is systemic to prove that.

The other supporting evidence was that they didn't rent any units that week. The problem is that they don't actually know that. Maybe the website inventory is stale? Maybe they just happened to not lease any units that week or they're still pending lease signing.

So I would say they absolutely got rejected for an apartment due to the report from CoreLogic. Everything beyond that is unsubstantiated and merely circumstantial.

Given what's in the Medium post, there's zero evidence for that. The author is assuming that a scam took place, but another plausible explanation is that the author had a missed rent payment on their record and the management company auto rejects those applicants. Sure, that record might be wrong, but it's still not a scam. Everything else they mentioned is pure speculation.

I think the author, if they feel strongly about this, should reach out to the local community to try to see how common rejections might be. They would also need to establish that CoreLogic is in cahoots with the management company.

That only works if you store your vault yourself.

When I tried it out I wanted 1password family so I could share some accounts with my partner. 1password 4 doesn't support their cloud datastore; the version that does will not run on Wine.

However, I could use the webapp on linux. It was a bit annoying but I could have dealt with it. The other complaint I had was the UX for Android. Having to switch my keyboard every time I wanted to enter a password was very annoying. Hopefully that gets better with the recently announced Autofill API for Android O.

But no linux support.

The blog post contains more details: https://youtube.googleblog.com/2017/02/finally-live-tv-made-...

> Its approximately 200 employees were made aware of the decision early on January 27, and the company said that it will compensate the employees through to the end of the month.

So they notified their employees that same day as they shutdown. To make it right they offered them a severance of two whole days.

Maybe they ping the card with a $1 charge every so often to ensure it's at least not cancelled. It could be maxed out in which case they'll likely just give you a negative balance and a time period to pay it. If you don't they can just sell it collections and potentially ban you from the store (it looks like you need to scan your phone to get into the store).

Yes, the paper JS Nice is based on calls out that they use the Closure Compiler as a backend: http://www.srl.inf.ethz.ch/papers/jsnice15.pdf

I believe only Apple includes the DoD root ca by default.

Why is that an issue? Owning the domain is the correct thing to do. They just screwed up by losing ownership of it.

You were correct, I have a TP-Link router:

$ nslookup tplinklogin.net

Server: 192.168.1.1

Address: 192.168.1.1#53

Non-authoritative answer:

Name: tplinklogin.net

Address: 192.168.1.1

---

An external request:

$ nslookup tplinklogin.net

Server: 2001:4860:4860::8844

Address: 2001:4860:4860::8844#53

Non-authoritative answer:

Name: tplinklogin.net

Address: 103.224.212.249

I'm not sure I understand you. TP Link givens the domains an A record using the DNS server running on their routers by default. Publicly it probably either had a default record of 192.168.1.1 or it just didn't have one at all.

Either way, the domain only makes sense locally. This is also why the domains still work even though they no longer own them. Therefore, if there were a local TLD, this would be the proper use-case for it.

Just to play devil's advocate, maintaining a CRL is quite expensive. Cloudflare detailed those costs here: https://blog.cloudflare.com/the-hard-costs-of-heartbleed/

Let's Encrypt avoided this by partnering with Akamai. Though StartCom really should have made an exception for Heartbleed.

For all the new gTLDs you can go to nic.tld to find WHOIS info and usually a list of registrars. In this case nic.foo goes to Google's registry, which doesn't seem to offer the TLD for sale yet (or if it ever will).

Isn't that the exact purpose Divshot aims to fill?

Doesn't the Chromecast have that capability?

It's included with Google. Thus if it's something you use (and most people do), then Google's pricing is very competitive for domains.

According to the USPTO, his patent is abandoned after he failed to respond to a non-final rejection back in 2011.

I respectfully disagree with the Daniel's blog post. Changing a password should not inherently reset all application-specific passwords, and though he doesn't mention it, it shouldn't revoke all OAuth associations either.

Perhaps I look at it in a different view point. Application-specific passwords, username/password combo, and OAuth are all separate authentication methods. The compromise of one shouldn't necessarily compromise the others (though additions/modifications subsequent to a compromise should be suspect). When the protocol for disabling a user is that you use the reset password functionality, that's using the wrong tool for the job. This is especially true when a disable user button is quite prominent on the Google Apps admin dashboard.

I worked in a K-12 school district for a while and password resets were a fairly frequent event. We also had many other web services that used Google OAuth. I'm not sure I would be keen on having to reset all of their accounts every time they forgot their password. At least 95% of password resets I did were because of forgotten passwords (remember, Google Apps doesn't have a forgot password system) and not due to a compromise or suspected compromise.

Finally, I'm not really sure what the point of changing a user's password to disable an account is. The argument could be made that you might want access to some of their data, but there's other tools in Google Apps admin dashboard for that. Want an e-mail audit? That's there (well, it was an API when I last used the dashboard extensively). There's also tools to migrate all their Google Drive data to another user. If you have the higher end Google Apps account, then you'll have Google Apps Vault which will give admins access to almost all of the user's data even once the account is suspended.

Yes, but they would already have your e-mail address anyway. Lookup by hash precludes the case where you're giving them information they didn't already have.

They should really accept a hash of your email/username to lookup. Then we can an idea of if we've been pwned without giving additional information if we haven't been.

I just found my winning bid e-mail: I got Quel'Thalas for $212.50 on 2011-10-24. I remember that freak Halloween snow storm.. somehow it managed to avoid hitting me the capital region.

I'll probably sell the server at some point but I have no idea what a fair price for it is. Perhaps I'll sell it using a double-blind auction.

Oh man, my first year of college I was in a freshman seminar and idly bid on one of these with a fairly low offer (~$200). Twenty minutes later I was the proud owner of a WoW server.

My lack of foresight has led to it being stuck, still in the original shipping box, in my parent's basement.