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.
Pretty sure someone like Guido is, at this point, not motivated by money. If there was a challenge he wanted to undertake at Google, I'm sure they'd give it to him already.
He probably wanted to participate in growing another new tech company that has a lot of potential. That's an opportunity Google would find hard to counter.
Sorry, my statement was more generic. I wasn't trying to say that Guido is motivated by money, just that these are common ways to get someone to stay if that is indeed the issue that makes them want to leave.
On the issue of challenges, maybe Guido has more pull on this, but there were recently some articles/discussion on HN about Google's hiring practices. They might hire you based on your PhD in databases, and then have you writing shell scripts for work because some randomized 'sorting hat' tells you what group you end up in. It's possible that even Guido doesn't have enough pull at Google to overcome this. :-\
If you want to move to another team at Google, it's really up to that team if they want you. As long as they have budget for you, and they want you working with them, then you're free to move.
The problem with new hires is that no other team has any idea whether you're any good, so it take a bit of tenure to prove yourself and make yourself known to others.
I'm quite sure Guido would be doing whatever he wanted at Google
The discussion I'm referring to represented ending up somewhere that you don't want to be as a bit of a trap.
E.g. if Guido ends up writing shell scripts, but his real skill-set/passion is for databases. It's quite possible for him to under-perform, and then that performance used as a reason for the 'database team' to not take him.
Yeah but the problem is, reasons for a career change are highly personal, and by the time the employee wants to leave, it's usually already too late to keep them by sweetening the deal. The only way to know is to ask Guido himself.
In any company there could be changes that are simply imposible to fulfil. Let's say that there is something on the company culture he don't like. You can't call upper management and say "I can't stand the level of politics on this company". Or the way we hire. Or the kind of products we are doing. Or the impact I have on the company (no single person is going to have a big impact at Google, no matter how great he is)...
There are also things related to company size. I am more confortable working for small companies than big ones, there are other people that is the other way around...
It's not as simple as saying: "please stay, whatever you want"
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 was just thinking about this today. To interview a potential co-founder I'd have a meal with the person and their SO. Then I'd observe the dynamic between them. Does the potential co-founder treat the SO poorly? Or is it reversed? Ideally they treat each other well. But there's more subtle hints to observe. Do they interrupt each other? If so what's the fallout?
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.
The whole idea some people have of meeting a cofounder a few times (especially in an artificial environment like a hackathon) and then making an all-of-nothing decision is flawed, IMO. The best process is to spend a LOT of time with the person, and work with him on progressively larger projects. Yes, how they interact with people is an important factor, but I'd try to spend many months (or years) on the process, not a few meals.
Or how they treat the staff at a dinner. Many other routes vs making some people uncomfortable that you may "require" a dinner with a SO. If they don't have a SO, what, invite a friend to an interview?
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).
Airbnb should have a phone number that people who are renting out their homes can call 24/7 for help, advice etc. If they do have this why didn't the author use it?
This astronomical user-base begs the question: why aren't you the most profitable company on the planet right now? You have the users, the money, the connections and the engineering talent. So what's the problem?
>You have the users, the money, the connections and the engineering talent. So what's the problem?
Assuming you're looking beyond the simple answer (because they 're not selling a product/service the majority of their user-base will purchase), I'd say they suffer from the lack of agility. Facebook's size increases their effort to implement even the simplest of changes. We've seen how fickle those users are about little changes and future ones could affect the group in negative and unintended ways. I'm sure every change is examined to death before implementation. In contrast, a start-up making changes might lose their early adopters, but could gain orders of magnitude more users because of that change. Facebook, however, already has the user-base. Facebook needs to keep them happy and drastically changing things in the name of profit would probably send people running. Of course not everyone will run and profit might increase, but those changes would have to be time consuming just from an implementation standpoint given their size and now being publicly traded the desire to keep the investors happy.
Good point about the lack of agility. Internal politics probably have a negative impact as well. I could see some team's feature going live for 1% of users then managers and other internal stake holders endlessly arguing about the measurements, data etc.
I'm wondering about the two-year or similar contracts people signed when they purchased or obtained for free a 3GS? Perhaps there's a corner case when someone got a 3GS + 2 year contract just five months ago. Might be some backlash if the device they planned to use for the next 19 months couldn't be upgraded to the latest iOS. Note this isn't an issue with iPod Touch or iPad due to lack of contracts (except perhaps an iPad data contract? But I'm under the impression those are more flexible, month-to-month etc).
What's a typical day like for a software engineer working in finance? I've worked in a variety of environments so I know that arrival times, perks, leaving time, meetings etc can all vary a lot. However I've never worked in finance or known anyone that has.
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?
I think it really depends on which part of 'finance' you end up in. I knew one guy who was 'just' a programmer and worked on maintaining some backend infrastructure code and he had a pretty miserable time. Sure the pay was decent, but it was a thankless job, with a shitty legacy code base, incredibly conservative about trying anything new and he basically had no say about anything.
One the other hand I have friends with degrees in mathematics and serious finance backgrounds whom are working in a more R&D style environment and they have an entirely different situation. They work a lot more with hard algorithmic and math based problems and given more freedom to pick their own tools and define their own work.
You nailed it. The work quality you get if you're in the R&D world you discussed is quite high. It's like being a data scientist at a startup, but with more money and an environment that is less political.
You have to convince people you're more than "just a programmer" to get good work. A quant, a crack low-latency guy, a data scientist, possibly an "architect". By age 30, if you're not some X (as in: "X Who Programs") along with being a good programmer, you start losing.
By age 30, if you're not some X (as in: "X Who Programs") along with being a good programmer, you start losing.
Or, you could work in an industry where software engineers are respected and valued because what they do is part of the core business. If you work at a company whose core business is X and you don't do X, then of course you are going to feel peripheral-- because you are. In computational finance, if you're not a quant, then you're just a member of the support staff and should expect to be treated as such. I fully believe that those firms would contract out this work if they could, but because of confidentiality reasons, they can't.
Right. To be fair to finance, there are a lot of companies (and groups within large institutions) that do value technology. Arbitrageurs, for example, rely on technology. (Financial risk in arbitrage is extremely low; but the danger is that, if your technology sucks, you'll be running at a high burn rate and making few trades.) People are starting to get it, even if it takes a long time.
The across-the-board startups = good / finance = bad mentality makes no sense to me. It may be true in the aggregate, but I haven't seen enough data and what I have seen shows no correlation. If you're in the back office of a huge bank, you're probably not in the best environment for an engineer. On the other hand, high-frequency trading requires a certain technical acumen that's fairly rare and that people will pay a lot for... and if you're really good at that stuff, a lot of the politics works itself out.
I think it's essential to become an XWP ("X Who Programs") even in mainstream software shops. Unless you have a national reputation as a great software engineer, you need some credibility that's independent of your performance as an engineer. Why? Because if the architecture's bad or nonsensical, good engineers won't perform well because they don't think in FactoryFactories and inheritance hierarchies. You need control of the architectural landscape in addition to engineering ability to perform at a 1.5+ level. Otherwise, if you take a typical software job, you're at the risk that you perform at a mediocre level because of architectural decisions made by other (less competent, but more powerful) people and never be able to convince people that you can take the architectural reins. You need that X (data science, project management, quant finance) to convince people that you're substantial regardless of your performance in the particular environment that's given to you.
I am doubling down on data science, machine learning, and statistics right now. (I was a math major in college, and had a couple of 50+ Putnam scores, but I've been away from math for too long and have to review linear algebra to make sense of a grad-level textbook these days.) What I learned in my last startup (where the unambiguously best engineer was demoted and an overpromising mid-20s bullshitter became unofficial VP/Eng, and threw the company into a "rearchitecture" that nearly killed it and ruined the culture) is that architectural issues get political fast. Very fast. Like, tachyon fast. To perform well as an engineer, you need to influence (and, one hopes, to improve) the architectural landscape, and you need some "hook" that is independent of said landscape in order to convince people that you're smart enough to change it as you need.
I think it's essential to become an XWP ("X Who Programs") even in mainstream software shops.
Well, it wasn't essential to Linus Torvalds, or Doug Cutting, or Joel Sposky.
If you enjoy data science and machine learning, do data science and machine learning. There's a lot of cool stuff going on in that field. But don't use it as an excuse to look down on people in different fields. There's too much of that going on already (and yes, developers do it sometimes too.)
I can't speak for Doug Cutting, but is my understanding that both Torvalds and Spolsky are XWP for values of X=Really good at managing projects and programmers, and in the case of Spolsky also pretty good at the whole running a business thing.
Certainly in Spolsky's case I don't think he writes much if any code at Fog Creek or Stack Exchange. Torvalds probably still codes a fair amount, but certainly when it comes to Linux most of his value comes from the architecture and management side of things rather than the lines of code he writes.
Everyone is an "X who Ys" for some value of X and Y. The question is what's your main job? If the answer is writing, reviewing, designing, or philosophizing about code, then your main job is software engineer. All three of the folks I mentioned fall in that category.
I had a friend in college who was extremely proud of his double major in biology and computer science. He went on to get a PhD in bioinformatics. He was fond of telling me that being "just a software engineer" would never be as exciting as the work he was doing in his specialized field (not going to go into details, but it was related to pharmaceuticals.)
A few years later, the pharmaceutical industry is in a slump and he can't find a job in his specialized field. So he's working on web design for a while, hacking PHP etc. I'm doing the same thing I've always been doing, working on distributed systems, and it's been very rewarding. (Before you ask, I did try to find a job for him, but he didn't want to move to the west coast.)
The moral of the story is to do what you really like and are good at, and don't worry about people telling you that you absolutely MUST shift your focus to X to succeed (where X = being a manager, being a quant, learning biology, etc).
But don't use it as an excuse to look down on people in different fields.
Oh, I don't look down on "pure" developers (as opposed to XWP) at all. I just think that it's hard to establish a reliable stream of good work on engineering cred alone, because the people who make decisions in most businesses can't tell the real deal from the charlatans in software engineering. The X is the "hook" that gets you enough clout to ensure you get interesting work and continue to get better as an engineer.
There's a big spread, and it depends on which institution and where in the institution you are.
the closer you are to the money (front office vs back) the more money you make, but the more stress you get
the smaller the firm, the more freedom/autonomy, the bigger the firm, the more beauracracy you have to deal with. Imagine working at microsoft vs your own startup.
Other than that, it's not much different than any other technology job
Bottom line: everything about financial software is what Joel Spolsky warned you about. If you want to work on software, go to a software firm. If you want to just pay the bills and are not passionate about software, finance software is..well, read below.
I've worked in finance as a software engineer at several large investment banks for many years. The software consists of a mash-up of legacy stuff incorporated into generally very "safe" architecture choices. Unless you work in some highly specialized (and very rare) type of group, you won't be making any decisions as to what language to use, database, environment or any other project specific choices. They do not value the product. Expect no documentation of anything and consider it a gift if you ever see an internal wiki. While documentation may be the exception in some circles, any developer worth his salt knows the true value of writing stuff down, or at least commenting code, so you can come back to it at a later date. This isn't the type of software environment where they're going to appreciate the years you spent in school, learning how to measure time-complexity of various algorithms. For the most part, those algorithms are already written and those data structures have been decided upon for you. I literally have conceived maybe a handful of algorithms over the years.
You will spend your time maintaining hacked together code that was assembled by literally 30 other people who came and left before you. There will be little to no testing before software is deployed into production. You will likely not have an adequate test environment. If you are lucky enough to have a test environment, chances are that it won't resemble production in any meaningful way. This test environment may be called "your development environment." You will work with many people who do not understand, nor respect, the art of writing good software. You answer to "the business," ie: traders. Traders for the most part, will not appreciate what you do. Its too nebulous for them, and most people not in tech at the IB, for that matter. I'll never forget when we rolled out our new auto-trading system and the IBank laid off several dozen traders that day.
Depending on how your group is organized, you may be on call 24/7. Some groups have coverage structures, with people covering production software in shifts. Expect to be interrupted on holidays. Expect to work on at least one of the following holidays every year: Xmas, New Years, Thanksgiving, Easter, any other national holiday. Projects will be scheduled poorly. Timelines will exceed aggressive-scheduling and wander into "insane" territory. This may be the norm, depending where you work. The quality of the software you write will suffer for it. Your lifestyle, health, social-life, family-life, interests, hobbies and life will all suffer for it as well.
Politics will rule everything. Politics will stifle your productivity, unless you have a great manager who keeps you away from all of it. Unfortunately, I've never met a great software manager in finance. I'm sure they exist, but I've never had one. There will be many meetings. The meetings will run on and on and many topics will be discussed that concern none of you, which could have easily been hashed out in minutes over email. But you will spend hours in meetings because thats the corporate attitude, and finance is as corporate as it gets. The excessive meetings will impact your productivity and result in regular 12-14 hour days, year-round. You'll have far less resources than you require to do the job even adequately, because the people making the decisions about funding view tech as a cost-center. You'll frequently realize, when you read hacker news, that there's a great many exciting things happening in software outside of the world of finance software. You will see none of these exciting things.
I know this seems like a long, negative entry, but I assure you - my experience was not unusual. I strongly caution anyone passionate about software against going into finance software. I've worked as a software engineer and (unusually) in the front-office on the trading side.
You'll also be exposed to: near-stupendous degrees of waste, inefficiency, and general head-in-the-sand-i-tude.
Like: signing up for a $140k/year "consulting" gig, but having a secretary pick your sole "workstation", a 12-inch, low-memory Lenovo model normally given to sales people.
Or: going through an grueling process ostensibly designed to assure that you have truly l33t skills in analytic and quantitative thinking skills... only to be herded into a dungeon-like cubicle farm with crass overhead lightin, poor ventilation, non-stop chatter and blaring overhead TVs, making it impossible to think straight for more than 5 seconds... where you end up plugging away for 10-, 12-, 14-hour days.
Or: being hired ostensibly for your senior-level experience in platform X, only to have every decision "vetted" by utterly inexperienced H1-Bs, whose personal coding style reminds you, without irony, of something you last flinched at seeing on The Daily WTF (http://thedailywtf.com/).
Not to mention: not infrequent episodes of not just hot-headness, but outright bullying and borderline psychological violence.
And generally: a stifling atmosphere which makes it basically impossible to have an honest conversation with anyone in upper management about the day-to-day realities of the environment they ostensibly expect you to be delivering this supposedly highly valuable, mission-critical software under.
Granted, this was at "mid-tier" companies, and I (thought) I knew what I was getting into. Still, the reality was far ruder -- and far more weird and just plain absurd, at times-- than any of my worst expectations.
I think this is a little too cynical. I've seen elements of what you describe in previous jobs, but never all at the same time, and never to the same extent.
Then again, the culture and the work varies in different cities and in different roles. In London we tend to get excellent developers joining the industry (traditionally there hasn't been much else for good developers locally) so you can typically expect to have skilled colleagues. And the closer you get to the front office, the more money there is for IT projects, and the more remit you have for writing good software.
It's funny you should mention London - our London counterparts always did speak differently of their hours, managers, and opportunity for growth. So I agree with you!
I worked exclusively on front-office systems nearly for the entirety of my time as a developer for an investment bank. I didn't even get into how there are very few opportunities for growth and other, more HR-related/culture aspects of the job.
I'm glad you have good things to say about your work! I just wish I could describe the time that I and my colleagues spent at those banks in a better light. It was utterly life-altering when I left. I felt like I was living for the first time since college.
I think most finance jobs are somewhat better than what he described-- it sounds like he's taken some crappy jobs-- but I don't doubt what he is saying. Code quality issues in finance are well-known and seem to be systemic. Hours are widely variable; there are 9-to-6 IT jobs and there are others that involve more stereotypical (read: awful) finance hours.
I think finance is a great place to work (yes, even as a full-time programmer) if you have a strategic reason for being there (VCs like financial experience, there are some interesting machine learning problems) but I would say that, in general, you're best off if you know you have the social and political skills to get the best work and, if you don't, finance is not likely to treat you well.
Hedge funds tend to be a lot more blue chip and technology-driven than IBs. IBs are usually filled with a lot of legacy crud -- some of it well-written, a lot of it.. not so much -- and a completely different culture as the earlier poster cynically talked about at length. I don't agree with everything he says and it sounds like he's in NYC and not London where things are generally of a higher calibre as Finance generally pays above and beyond what you can get in other industries.
Right on - London vs. US is very different. I envied my UK friends who left work at 4pm on Fridays to have a drink with their colleagues, when I'd regularly be working till 8 or 9pm.
I currently work in finance in London and have experienced very different! I was nervous, expecting to be working with MIT gods who would make me feel like an embarrassment of a human being. The reality is I am working with borderline retards from Utah who do no work whatsoever and when I explain in detail, they don't listen one bit. I'm the one left working 50-60hours to cover their lack of work.
Holy hell, this brings back awful memories of back when I was a software engineer working for a large consulting firm.
The biggest problem with working in non-software companies is that, software engineer salaries are treated as overhead, not investments. This means that they aren't going to spend tons of money to hire the best and brightest talent, they are going to hire the cheapest labour that can get the job "done".
I've been out of it for quite a while. It was somewhat unsettling to reflect back upon my experiences. Usually time softens the edges of a harsh experience, and you recall the "good times" far more frequently than the bad. Usually.
I work at a top (some might say the top) financial services firm as a Software Engineer. I joined relatively recently, so I still haven't formed a full, well-grounded opinion about the environment and my employer, but I will try to go over the main points concerning your question.
A typical day goes like this:
8.55am I arrive at my desk. Login and start checking email.
9.15am Head off to the cafeteria to buy breakfast (yep, no free food!)
9.20am Eat at my desk whilst reading clicking through my inbox. We get a lot of email. Some people on my team are already on conference calls with Bangalore.
9.40am I open up Eclipse and start working on my assigned project. This goes on till about 6pm. The coding is actually the easiest part. It takes a lot of effort to go through the rest of the process - code reviews, testing (all kinds of testing), UAT, sign off. The PM constantly comes to ask for your ETA (oh, you need to fix this threading issue? How long will that take you? Like an hour?)
12.30-1pm Lunch at my desk. Although sometimes when I have less things to do, I get to go out and spend 45 mins enjoying a burrito.
1pm - The New York team comes in. The 'serious' conference calls and meetings begin. Over the rest of the afternoon, about 2.5 hours are spent on conference calls.
6pm - The contractors leave on the dot. I can leave on the dot, too, but then everybody hates me. It's considered acceptable to stay at least till 6.15pm. Sometimes when I have issues (e.g. I have the fortune of doing production support that they) I might not leave till 8pm.
This is my typical non-support day. A support day is similar, except you have to add a couple of hours of nightmare in the middle.
About the work:
Varies team by team. Some teams make iPad apps for bankers. We work on large-scale distributed systems. We have hundreds of processes that exchange and persist information with a few dozen external systems, as well as internal systems to the firm. The biggest challenge is the complexity of the flows and scaling this architecture to peaks.
I'm sad to say, but you will rarely implement fancy algorithms. A good knowledge of messaging protocols, data structures, databases and concurrency is very important though. And the thing that is essential is business knowledge.
So, if you had to make a good old Pros & Cons list, it would go something like this:
Pros:
1) Excellent compensation for the average developer.
2) You get to work with smart and dedicated people.
3) You'll rarely have time to kill.
4) Looks good on your CV, provided you work for a top firm.
5) The work can be interesting, if you're inin distributed systems and architectures.
Cons:
1) Stressful when doing support. A lot of money is on the line.
2) Compensation is very highly correlated with firm performance, which, in turn, is very highly correlated with market performance.
3) You can earn more and work less elsewhere, if you know your stuff. Not really much recognition for "star developers".
4) You'll be using only tried and tested technologies. Good luck getting permission to use any of that RoR you picked up on the weekends.
5) There is A LOT of process.
6) Promotions seem to be based around people's perceptions of you, rather than the quality of your work.
7) Combining (5) and (6) leads to a lot of office politics.
and, finally, (8) If you get unlucky and hired into a shitty team, you're going to have a bad time.
But the best part for me so far is that every once in a while something truly bizarre happens. This makes the rest of my week.
My advice, to survive in that industry as a software engineer, one needs a healthy dose of distrust towards management and a good sense of humor.
I see you're in London; the only way to fly as a developer in Finance not on a profit share or massive front office bonus scheme with the trading desks is to be a contractor.
I had to break it to you, but a lot of these cons apply to 99% of all software jobs, especially promotions being based on perceptions rather than skill or talent, stressful support, and bad luck if you're hired into the wrong team.
Programming is awesome, but 99% of the software industry is a toilet. Finance at least pays for your suffering in cash you can spend rather than lottery tickets.
I don't think engineers should ever spend their time asking Fizzbuzz. Engineers' time is valuable. And blocking off an hour for a phone screen can interrupt the day. If a preliminary code sample filtering step is used then engineers can jump straight into the meaty interview questions.
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.
IMO phone screen (if it really is a "screen" and not a full "interview") should be fifteen minutes or less. I usually ask a few very specifically CS101 type questions to see if they remember any of it, and if they don't, they don't come in for an interview.
I agree about the phone screen length. Whether you call it an interview or a screen it can probably be much shorter than hour with almost all of the benefits.
Just want to point out that back-end improvements alone aren't sufficient to have Apple's Maps be on par with Google Maps. Adding something like Street View to Maps will require non-trivial updates to the iOS app (not to mention the colossal task of gathering and processing the street view data).
There's no indication they'll ever have something like Street View -- or rather, what's "like" it is the 3D flyover mode.
In practice the back end is really the main thing that they need to worry about. I'd argue, in fact, that the first order of business is straightening out the point of interest database, which seems to be where the majority of genuine problems are coming from. The second order of business is ensuring cartographic completeness and correctness, i.e., making sure that roads (and even the occasional town) are actually present and in the right place. Things like fuzzy terrain tiles or bad 3D meshes may be the most fun to take screen captures of for point-and-laugh purposes, but it's far more important to me that the maps application can tell me how to get to the Brooklyn Bridge than whether it can render a pretty 3D model of it.
