I don't know how prevalent it is (it's not been part of any startup I've been part of - but obviously small sample size and all that).

I think we're talking past each other though. I don't disagree with what you're saying about the valuation in a private round for some form of preferred shares vs common shares at IPO. I just don't think it's an important point in terms of what the article was talking about.

I think Sam Altman said it right recently when he said to the extent of "if none of these unicorns fail it is more a sign of a bubble."

I don't think we are in a bubble at all, I think founders have become more savvy to the fact they can take private money for longer and not have to lead these super fast growing, unorganized, and chaotic companies in the public market.

Why would you ever raise $200mm in an IPO when you can get $200mm from a huge fund and just add 2 people to your quarterly meetings?

The ZeroHedge schtick seemingly is basically the financial markets are always overvaluing just about everything. In my view the markets are much more efficient than 10 years ago. Typically, institutions allocate investment funds according to their particular asset allocation models and some of that money finds its way into IPOs. High risk, high reward but smaller amounts, spread around to diversify away individual company risk. Valuations are based on future earnings and in these cases the value put on IP. Valuing IP in lots of these companies is difficult and of course there is a lot of risk. Getting the big picture of where a market is headed is part of the process in valuations. In the case of Uber, I would read it as the ride share market is going to grow a lot and Uber is the clear leader. So scale investment money accordingly into ride share companies.

In the case of Dropbox I would read it as their business model is at risk. Look at what Google, Microsoft, etc. are doing in cloud storage. Dropbox would seem to be a play on, at some point, being bought out possibly. I mean to me it makes total sense that something like a Dropbox IPO would not raise as much money as originally thought. FWIW.

I don't really have any strong opinions if we're in a tech bubble or not (mostly through ignorance). But I'd argue that something like this could be exactly why it is (or has been up to now) a bubble. It's a lot easier to build a house of cards getting your money from a couple of private organizations than it is to get it from the scrutiny of an IPO.

And like Blackize was saying its not even necessarily a bad investment for the last investors. In many cases they can view it as almost a no lose situation. If the crazy valuations last they can make a chunk of money on the IPO with an increased valuation. If the crazy valuations don't last they've probably protected themselves with favorable terms on getting at least their investment worth at IPO or in a future down round.

There's a bunch of reasons. The private equity investors are going to get much better terms than you have to give up in an IPO w/ common stock. It provides liquidity to a bunch of early employees/investors. There's definitely a prestige aspect. And so on.

I'm a JS amateur so not sure what answer you're looking for?
I think that's actually a pretty specific problem, not sure if many people can answer that without googling, I needed it a bit back and only remember because of that but had to check in the REPL.
It's a tricky question...on the one hand yeah you kind of need it and it can come up quite a bit otoh it's somewhat specific and stuff that is in my memory as "one quick check on SO and I know it". I'd probably stick to prototype related questions for that question slot.

I think that any interview question that can by answered with a 15 second googling sucks. Its reminiscent of history tests in gradeschool that focused on what year something happened instead of asking the 'why' and the 'how'.

Granted, I've never hired people myself but I think the person hiring should try to do two things:
1. Find out if the person you're interviewing can do the job.
2. Find out if you can stand being with the person you're interviewing 8 hours a day 5 days a week (or whatever schedule is socially acceptable at your company).

If the job is to program, then give them an assignment and review the results. Or ask for examples of earlier work. I don't think asking trivia questions is going to expose programming proficiency.

I tihnk that's mostly due to the communication overhead involved in offshoring. I'm very much pro "keep everything inhouse" mostly because I think if software is your business it's very smart strategically to care about having access to you developers and making their job easy and not treating them as cost to be optimized.

That being said if you can handle the overhead there's very good offshore developers, specifically in eastern Europe. The problem is most companies that offshore try to look for the "bargain bin" and that's what they get. The best screen is language, if they speak English well and fluently that's already a great step.

tl;dr; don't offshore, if you must make sure the language barrier is a 100% non issue (+watch timezones) and if you have some position in mind in the 50-70$/h range look in the 30-40$ range and not the 5-20$ range (numbers made up)
tl;dr2: developers are assets not costs

I think recursion is a good way of thinking about problems but in practice I default to loops for most algorithmic work (which I do close to 0 these days). The lone case were recursion is always great is any problem that remotely looks like quicksort...so anything that feels like divide and conquer -> recursion in my mind. It's probably very helpful to work through a bunch of quicksort-esque problems, I should do that again soon, it's a pretty great moment when you're able to say..."wait a second if I twist and tweak this problem a bit it kind of reduces to quicksort...yay"

I agree with this but stress the bolded. Even in a software shop there's usually some work that needs to be done that isn't really core business. In those cases it can make a lot of sense to offshore, imo.

Agreed with what you're saying about language and time zones. I think those are huge. If you're working with someone that only overlaps for an hour or so a day (or not at all) and who you can only communicate with on a very high level - you're going to have almost no influence on the design decisions being made. And that generally leads to crappy software regardless of the skill of the developers.

I would bet good money that Palantir is extremly profitable and will be raking in more money in the future.
I also think it's sort of an evil company and wouldn't work there (unless convinced otherwise that's basically my default stance on any companies involved in government contracting, specifically intelligence and military)

Palantir was a close job prospect for me at one point - and I was pretty torn about working for them. They do a lot of really cool stuff that I think is necessary for modern policing/national security work. But man, its such a thin blurry line between necessary/good work and evil work.

these are exactly my priorities. and since each one is rare, the union is even rarer -- hence why hiring is so hard.

how far off are we from a Johnny Depp Transcendence/Futurama old people planet/brains in jars situation?

Saw an article about a two-year old girl being frozen just after death. The parents thought we were anywhere up to 500 years away from having the tech to unfreeze and give new life to their child. (This assumes the company freezing their child doesn't go out of business and have to pull the plug on the fridges)

Curious at what point we can either move our consciousness onto a computer (maybe part cyborg), or just go full brain-in-a-jar and have a virtual reality pumped into our senses.

Personally, I'm rather fond of consciousness, and don't understand the idea of accepting an eternity of non-existence. Can't google throw several billion dollars at this problem and get it fixed?

Don't know how far away we are, but if you can track down a copy, Dennis Potter's Cold Lazarus has an interesting perspective on the process.

Node aficionados and websocket lovers,

What are your recommendations for setting up a scalable websocked-based backend? Here are a few ideas so far, keeping in mind I'm not knowledgeable in this space:

1. Use pusher.com to handle the websockets. They have a webhooks feature. So basically, I write my backend however I want (an ruby http api on heroku, something on aws lambda, whatever), and pusher.com acts as proxy between the "normal" backend server, providing a websocket based interface to it. The additional latency between pusher.com and my server may destroy some or all of the speed benefit of websockets, though -- not sure.
2. I can't figure out if aws lambda supports websockets, but I'm guessing no.
3. Host an existing solution like socket.io (or something else?) on heroku (or somewhere else)? This solves the latency problem, but would there be any other gotchas with this approach? If not, what specific recommendation do you have?
4. Something awesome I'm not even thinking of?

Digitalocean? Don't see any reason to do anything beyond that and whatever you come up with (socket.io) on the dev side. Socket.io is fulfilling my use case really well and I don't see any need to go anywhere else. I don't see any reason to go heroku > digitalocean.

In theory you're right, but it's a production system used by thousands of people and needs to be secure, and given that i'm not a professional sysadmin, it wouldn't be responsible. Also the difference in cost is not even a blip on the radar compared to other company expenses, so saving that amount money is irrelevant. if this were a personal project i'd feel differently.

Question about frontend caching objects to prevent requests:

Say user goes to "website.com/objects/1"

My JS logic is basically (we use Angular, so this'd be in service.js):

If cache[obj_1_key] doesn't exist, make request to "/api/objects/1", put the JSON response into cache.

Otherwise just serve from cache and avoid the request altogether.

Assuming the object doesn't change often (say once every week), is there a downside to this approach?

This request takes ~200 ms and I think is pretty optimized in the backend.

If you're using Angular, this functionality is built into $http. Look into the caching section here:

https://docs.angularjs.org/api/ng/service/$http

Even if you're not using $http's built-in caching functionality, you may want to use this:

https://docs.angularjs.org/api/ng/service/$cacheFactory

If not, you may want to create the cache object with Object.create(null) as to create an object with no built-in properties that can clash with keys. This is normally not an issue but it can be. The only other functionality that $cacheFactory provides is that it allows you to limit the number of entries in a cache.

Beyond that, you do have to worry about application-level coherence issues. Aside from the more typical cache coherence issues where different clients have different views of the model and cause conflicts, I've also seen quite a few bugs where, within a single client, one object is cached thus an older version is used, while the newer version of another object is returned from the service and the combination of the two violates some rule/invariant that the application relies on. For example, one object may contain references that need to be resolved in another, but because you're looking at an old version, that may not be there.

Thanks so much for this! For some reason didn't think to see if caching is built-in.

Definitely will need to talk w/ team about cache coherence/invalidation

candybar, we've got a new project at work which basically involves serving up the guts of a page to 3 different web-container clients (web page, salesforce/crm client, POS client). I can probably push for angular 2 since this is just a POC and won't be starting real dev for at least 6 months.

Questions:

1. Will angular 2 be stable enough to use in production in 6 months?
2. How stable is the developer preview now?
3. Can you think of any big bullet selling points besides moving more towards a web components world?

Angular 2 beta will be out very shortly, not sure about dev preview stability but I'd be surprised if it wasn't rock solid in 6 months.

Not sure if this is relevant for what you're doing but the two big enterprise selling points over Angular 1.x are:

- Rendering speed. MUCH faster, significantly faster than React even.
- Server-side rendering, helps with SEO etc.

1. I don't know about production readiness in 6 months but it should be good enough for development in 6 months and assuming ~ 6 months development cycle on top of that, should be good enough for production at that point as well. I think their actual timeline is something like beta in late 2016 and stable release sometime in mid 2016.
2. Should be fine for POC but you should expect some API changes and whatever tutorials and other documentation you're going to rely on are either already out of date or going to go out of date as time goes on.
3. Like ChrisV said, potentially much better performance in some use cases and support for isomorphic js apps. Angular 2 is also conceptually simpler than Angular 1 and it should be easier to interoperate with the future non-Angular world Mobile support should also be better - it's not an add-on like in Angular 1 anymore.

It's not always good to be this early of an adopter for large, complex production apps because the ecosystem is probably not fully fleshed out, which means you will be implementing things yourself that would you'd eventually want to replace with 3rd party components or even features of the framework; best practices, tutorials and documentation are going to be lacking, which means you do have to figure your way out of things, sometimes by debugging through the source code; all of which add up to having to reverse decisions and retrain people over the course of the development cycle. But Angular 2 is in much better shape than most frameworks (including Angular 1) would be at this stage because of the hype and the popularity and the massive amounts of resources and planning that went into it. And nothing's all that stable in the front end world these days anyhow.

Are there any good technical podcasts you guys listen to for both entertainment or learning purposes? I'm having trouble finding any. Would be nice to learn some stuff while I'm driving around.