spaghetti

Convincing yourself that future success isn't predictable is actually pretty easy. Regardless of how technically awesome someone is, there's a random variable that can dramatically affect one's future success: the candidate's co-workers.

Anyone with a few months experience at a big company knows that a new hire's coworkers are, for the most part, selected randomly. When the co-workers match, everything can work out, even if the candidate isn't technically strong. If the co-workers don't match, for whatever reason, the working relationship can easily fall apart.

I don't know what the ultimate solution is. Even work trials aren't perfect since company and team structure change. Accepting the unpredictability of future co-worker relationships makes it easy to see there's no magical solution. Understanding this might help things move in the right direction.

I have a few thoughts on this in no particular order:

- It would be interesting if the top list gaming mentioned in the article was eliminated by replacing download or install count with something more meaningful like "frequency of app open" or "average time spent in the app per day". These can still be gamed but it's harder than just gaming a metric that relies only on download or install count.

- There should still be some sort of collaborative filtering. I favor improving the top list's ranking algorithm over getting rid of the top list.

- Giving new apps more chance to succeed or exposure could be implemented similar to how HN includes job postings. Namely the listing is put in the top spot of "the list" for a bit and slowly falls down. In the app store the new app should probably fall rapidly unless user-engagement is high. How to measure that? Download count is too easy to game so other metrics would need to be used.

- I think developers should be mindful that they're selling to (in general) everyone and not just other developers. When Marco mentions "high-quality" apps he's speaking from a developer's perspective. And developers often care a lot about details that the general public doesn't notice or doesn't care about if they do notice.

- The app store should be faster. The iTunes load time feels too long these days.

My experience participating in TopCoder SRMs (quick algorithm development competitions) has payed off quite a bit when it comes to white board coding style interviews (both as the interviewee and the interviewer). Just thought I'd share a few pointers:

- participating in SRMs is great practice for interviews because you're forced to learn to think clearly while under intense time pressure.

- The TopCoder tutorials are a great resource. In addition to review of useful mathematics, data structures and algorithms they'll give you an introduction into how to participate well. For example time management between the easy, medium and hard problems.

- You have four language choices for SRMs. My preference is C#. I like using Visual Studio because the auto-complete/intellisense comes in handy when you have to write a bit of boilerplate code (like "new Dictionary<int, int>();". I've also used MonoDevelop on OS X. It worked well. iirc almost all problems are solveable using C# except a few where, to my knowledge, C++ was necessary. Read-up on Petr's advice. I believe he's a fan of C#.

- My knowledge of C# isn't particularly deep so don't let learning a new language scare you away. imo you just have to effectively use dynamic arrays (List<T>), hashtables (Dictionary<Tkey, TValue>), static arrays and strings. Also a sorted key-value store like SortedDictionary comes in handy once in a while.

- Last bit of advice: solve lots of problems and have fun! You can access a vast archive of problems from previous competitions and match editorials which usually have decent explanations for the problem solutions.

One option is essentially a programming test framed as a first quick milestone. Say the app is for taking and sharing photos and has a $10k budget. Start with a milestone for an app with a single button. When the button is tapped the user can take a photo using the built-in, default camera view. Price this milestone at $300 or some other small fraction of the total cost.

If the contractor quickly sends you something simple that works without too many lines of code then you have a decent signal that the skill level is sufficient. Anything else (slow response time, app doesn't work, below expectations code quality etc) and you have a decent signal that the skill level is insufficient. In this case just pay out the first small milestone, thank the contractor, cancel the project and try someone else.

Yes there are great developers and other professionals on Elance. Think about it from a developer's perspective: I can work at one company, on a relatively small variety of projects, probably maintaining some legacy code, with the same people at the same place everyday for years on end and earn $X/year. Or I can work for a few clients that I choose, on a wide variety of products, rarely/never maintaining legacy code other than my own, and work from almost anywhere in the world while earning something close to $X/year (probably +/- 20%).

Milestones are great. However I like to have reasonably consistent prices. For a $4000 project you can have, say, four milestones with prices $500, $1000, $1000, $1500. This way the client can bail out after the first milestone if things aren't going well. And they won't lose too much money. Also the client gets the "carrot on a stick" with the hefty fourth milestone without being obnoxious (with a $3200 fourth milestone for example).

Do salary deltas of even 100k make a substantial difference to the bottom line for large tech companies like FB and GOOG? Of course the difference is greater than zero but as a percentage of operating cost I imagine it's relatively small.

My guess is large tech companies are eager to import foreign talent primarily because of cultural and socioeconomic differences. Who would you rather hire to maintain your legacy code bases? A skilled immigrant that's thankful for the six figure salary and will obediently complete their tasks without much fuss? Or the native-English-speaking citizen who can find a six figure salary at any of his friends' companies and will walk as soon as the legacy codebase's tech stack starts to reveal itself as less-than-inspiring?

I like to partition companies with products that gain traction into two groups. In the first group are technically mediodcre founders who cobbled together a product that's almost unmaintainable. The second group consists of relatively experienced founders who cobbled together a product that's maintainable.

The two groups use distinct interview styles. Since the group with nearly unmaintainable code has many more members than the latter we see their interview style far more often. This is the familiar all-day brain teaser and relentless quizzing interview style. This interview style makes sense for these companies because they need warm bodies to throw at legacy codebases. The quality to seek in employees is perseverance and obedience. And this familiar interview style tests for just that.

The second group of companies uses the more thoughtful interview style. The founders value insight, creativity, and experience more than obedience. Hence their interview style focuses on these qualities.

I've never designed large-scale systems however I'm still fascinated. I wonder if LBs could learn over time which requests will probably take a while and which have large probability of being fast? Then the requests could be uniformly distributed amongst the servers.

A system like this could have all sorts of knobs to turn. Requests could be partitioned into two groups: "probably fast" and "probably slow". Or three, four, n groups etc. Then the way in which the LBs distribute the requests could be tweaked. For example a ratio of 1/5 slow/fast requests per server.

This does require some feedback from the servers to the LBs. However it doesn't have to be fast. The servers could push some (request, time) pairs to some aggregating system at their leisure. Then the response time prediction algorithms used by the LBs are updated at some point. Probably doesn't have to be immediate.

Probably nothing. I just find it interesting that an organization like Google with practically unlimited resources can't keep someone (who can probably get anything they want in terms of perks) around.

I agree this is true for small companies. However Dropbox is not a small company by most measures. Also pg's remarks about how you couldn't acquire Dropbox or Airbnb for (some large dollar amount I forget) lead me to believe Google won't be acquiring them.

I'd imagine Google wants to acquire them. However I doubt Drew Houston would go that route.

Wow if he really did contribute a lot (which I don't doubt at all) then how did Google let him get away? I'd imagine his lifestyle there was pretty nice.

Perhaps companies that have existed for less than n years?

This is great Dropbox PR. Also I'd imagine DB Python developers are excited!

Good point. I wouldn't formally require the SO. I'd just phrase the invite to make it clear that my SO and I would like to have dinner. If they have an SO but don't bring them that's another potential signal (could be good or bad).