spaghetti
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.
- 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.
- 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.
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.
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?
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.
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.
I'd imagine Google wants to acquire them. However I doubt Drew Houston would go that route.
The point is to assess the person's "people skills." I think "people skills" or in general "emotional maturity" is by far the most important factor in someone you need to work with on an intense level. Be that co-founder, SO etc.
I'm under the impression that algorithms and data structures knowledge is very important. But do software engineers in finance really deal with this on a day-to-day basis?
The vast majority of people who don't know programming basics like loops and conditionals won't make it to the phone screen stage. Someone might look up the solution to the programming quiz but they'll immediately fail the first interview question. And this can be partially mitigated by rotating puzzles or even changing numbers in the puzzles.
The code sample filtering step should have both a sufficiently tricky puzzle and a bank of at least 20 common corner cases. Just run the test cases automatically. The vast majority of candidates will be eliminated without wasting any engineers' time.
Seems like there's some "low hanging fruit" problems that this app ecosystem could attempt to solve. First is search and discovery. Just do it better than Apple. Then there's the review process. Just scratch that entirely and use collaborative filtering to let the best apps bubble up to the top of the list. Of course have some flag for offensive, hate related etc apps.
How about partnering with Stripe and having an in-app-purchase system where developers get 100% of the revenue? Or perhaps 90%. Just being better than Apple is a great start.
One more thought: Apple's app ecosystem had the benefit of users' CC info pre-entered. Seems like app.net could benefit from the CC or other payment info already supplied by users when signing up.
There are certainly corner cases. For example a company developing a particular technology might need some savant for a while to build the proof-of-concept product. However once that's done this employee's abrasive nature can have a negative impact on other employees and company culture. In this rare case I'd choose compassion for the employee. This could involve working with them, giving them projects they enjoy that don't involve working with others or even recommending them to another company with a note about their talent and people skills trade-off.
There's also the case where an employee is regarded as brilliant but lacking people skills and is just plain dysfunctional. The technical skills are lacking but people are afraid to confront the person because they will yell or become angry. In this case the person should be fired ASAP.
YMMV to say the least. You can find yourself working with the friendliest person who teaches you something useful every time you look over code. Or you can end up working with someone who's emotional maturity level can only go up to put it nicely. Combine the latter case with someone who isn't quite old enough to "know what they know and know what they don't know" and you have a recipe for disaster.