I agree with this approach more than the common wisdom on this site that you should not name a number first. Pick a salary that you would be happy making given the desirability of the job, your current employment situation and the market. Quote that number and see if they accept. If they do--great! You have the job at the salary you want. If not, then consider their counter-offer and decide if that's something you want to accept.
The hiring managers for most jobs are not business owners. They are middle managers with multiple bosses. Most see the hiring process as an opportunity to show they are management material. If you give them a number that they know you will accept, they can pull whatever levels need to be pulled in the organization to get approval. What they don't want to happen is that they overbid for a candidate who then still rejects the offer. That makes them look incompetent in front of HR and upper management. Most managers would rather just give you a safe offer that you are more likely to reject than a politically risky one that might still get rejected.
I think Google's history of shutting down products would keep me from picking Google Cloud for a major project. If Google Cloud continues to lag behind the market, you have to think they will shut it down like Google Reader, Google Wave and a number of other products. Even if Amazon isn't perfect, I feel like AWS will be around for a long time.
I'm not convinced CIOs are thinking about Reader or Wave. Before entering a big deal, it would make sense for people to read the deprecation policy. Unfortunately, the Cloud Platform deprecation policies are unclear.
As a CIO, I would be most concerned with the ecosystem and availability of talent. Google have done a good job trying to reuse some of the same tools and ideas like reuse boto, but writing scripts for their cloud platform vs. AWS is still as different as English and Dutch.
Google has shut down much more than Reader and Wave, or drastically change the paradigm or pricing of their existing offerings in ways that can drastically increase costs. Here is a link to a comment I wrote a year and a half ago, looking at Checkout and Charts.
(Note one correction: at the time, the deprecation of OpenID had no migration path; I complained to a bunch of people at Google I/O, as did likely other developers, explaining in detail the migration problem, and sometime in 2014 Google corrected this mistake.)
As a VP Eng who has made the call on Google vs AWS on a few occasions this has certainly affected my thinking. I see Amazon's web services being a big part of Amazon's revenue and I feel comfortable they are in it for the long haul, whereas I see that Google doesn't even call out its cloud service revenue[1] which suggests it isn't notable. And services with that sort of profile from Google end up dead because Google just doesn't seem able to commit to long term strategic visions.
Amazon might be known for good support on the customer business, but I've not heard the same regarding AWS -- quite the opposite. If Google support were worse, it would have to just ignore you.
It think it varies based on your account. We were one of the companies that presented during the keynote at this year's re:Invent. We've also got an enterprise account. I'm not sure if either of these are a determining factor, but we get excellent support. Phone support is good and emails are answered in about an hour. They've also connected us with their engineers when support isn't able to resolve things.
On the whole, I think the only thing they could improve would be to reduce the siloing between different offerings. When dealing with an issue that spans, say, EC2 and Route 53, I would expect their support to talk to each other and present a unified response to the customer rather than require us to deal with two separate support reps. But this type of siloing goes beyond support and applies equally to the AWS product.
Yes the fact that you were inside the loop enough to be part of the presentation side of re:Invent means your experience is abnormal. You've got the right contacts and profile for them to brag about you.
Having said that, we pay for their 500$/mo support offering and the responses are pretty good. We're also split between AZ's etc as recommended.
As <pm> points out nearby, the GAE pricing issue was in 2011. It's now 2015.
I use GAE for http://recent.io/ (which I left CBS last year to found), and have found that prices have been gradually falling for the last few years. I can't speak to what happened in 2011, but I think it's fair to say that GAE was a much less mature product then.
My own sense is that Google would like to diversify away from being 90%+ reliant on advertising, and is highly unlikely to discontinue a paid service that serves that goal, that is profitable, that is under active development, that allows it to compete with Amazon, and that is used for its own products internally. You might as well speculate they'd discontinue search or email.
I use AWS for some smaller components of http://recent.io/, and have found both to be equally reliable. Google also has assigned me a rep who I can call or email when there's a billing issue, sign up for beta trials of new features I'd like to test, address technical problems, etc., and I've never heard from a human at Amazon.
Yes that was 2011 but it scared the hell out of me. Since then all my company's project are hosted on Heroku and other Amazon technologies (Simpledb, Dynamo etc.). If I had to have a vendor lock in in exchange of faster development process, I'd prefer to get locked in with Amazon other than Google after that GAE pricing incident.
It wasn't easy to mitigate: re-writes were needed because of the private apis. We ended up doing a lot of optimization to prevent a pet project from costing us too much money, which before the price increase stayed well under the charging threshold. The pricing incident was the only thing on my mind about Google's cloud because we left Google since then. I'm sure things are different now, but then I got too many other things to do before taking a serious look at ditching aws for google.
Seeing as I can't reply to the comment in question... the price hike article you mention is in 2011. The price hike was a change of system, and everything went up because most people were using Python 2.5 which had no threading support. Python 2.7 had proper threading support, and unsurprisingly when that was enabled, everyone's cost dropped by three-quarters. Google dropped support for 2.5 two years ago.
If were really worried about costs, you'd convert your App Engine app to Go.
Google have some pretty good deprecation policies in place with regard to sunsetting their Cloud offering. I recall when I last looked (for appengine a couple of years ago) it equated to a promise to keep the service running for about 3 years. Doing a quick check of terms now, it seems like this has been updated to:
"Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):"
https://cloud.google.com/terms/
Not great, but a year is a long enough time to migrate away. That being said, my recent experience (https://news.ycombinator.com/item?id=8784356) has prompted me to migrate away asap.
I personally wouldn't use the Google cloud because I've had the experience when interacting with Google APIs that API stability is not important to them. The Adwords api used to change every few months and old versions would break. This is not convenient for running a production system.
While a fair assessment, Google is a cloud provider to its internal teams anyways. While there is some overhead to providing it to customers, it's probably less than the overhead of Google Reader or Google Wave because much of the work is already necessary.
I am with you on this. Google needs to demonstrate enterprise awareness about needed guarantees.
However, the bigger issue is that AWS isn't "broken". There is no compelling reason to look at alternative solutions. In particular alternative solutions that have a learning curve.
If google implemented an Amazon API compatibility library that would help a lot. But right now for me to try out google cloud - I have to recode my app.
This. Google have a bad history of this. And not to mention they also have have a history of introducing new versions totally incompatible from the last (re Angular) would keep me from ever choosing their stack.
I would start looking for a new job immediately, but stay in your current job until you have something lined up. It's much easier to find a new job when you are already employed. Relax and just focus on developing your skills and learning as much as you can while you are there. What's the worst that could happen, you get fired or laid off? You are considering leaving the job off of your resume anyway. You might as well collect a paycheck while you are looking.
Learn everything you can about Java/Spring even if you never intend to write another line of Java in your career. It's always helpful to be familiar with other languages. Be polite to your employer and (when you have a new job lined up) just say you are moving on to an opportunity that is better aligned with your goals.
I once worked on a project that required refactoring classic ASP code written by a company in India. The code was a rat's nest. The site had hundreds of pages and most of them had three or four copies of the code commented out (this was their "version control system"). At the time I hated it, but looking back I learned a lot about what not to do and how to be a better programmer. I used the opportunity to create automated tools to clean up the code and experiment with new technologies.
I'm not sure if this site qualifies as "small" enough, but I think Ken Pomeroy does pretty well with his site kenpom.com. He takes college basketball box scores, runs a cron job that does some mathematical analysis and puts the results on his site. He has built the site out in the last few years, but there are still only a handful of dyanmically generated pages on his site (rankings, team stats, player stats, game stats). A subscription to his site costs $20/year and I would guess he has several thousand subscribers (myself included).
I'm just a college basketball fan that likes statistics and finds it worth $20/year for his analysis. I have season tickets to a college basketball team and I like to see information about upcoming opponents and the site's projections for the game.
I estimate the site has several thousand subscribers because I personally know quite a few people that subscribe. Many (most?) college basketball coaches also subscribe to the site[1]. There is also a page in the subscriber section that shows a breakdown of subscriber's favorite teams by percentage. Based on how small the percentage changes when you select a team, you can infer a rough number of subscribers that way too.
Another group that this helps are colleges and universities. Universities love foreign students because they pay full price and have to be able to afford tuition before they can even come over to the US. Higher education has become a major export in the US economy, so it also benefits the trade deficit to some degree.
I thought that was strange as well. Any phone or tablet app in the Play Store that uses native code will not be compatible. I'm guessing they did this to make it more attractive to game developers. PlayStation, XBox, and PC are now all x86 platforms. Makes it easier for top game studios to also target Google Player if it runs the same architecture.
actually, 99% of native apps should work flawlessly _on the condition_ that they're downloaded from the Play Store. intel has something called the Houdini for AOT binary translation: http://stackoverflow.com/a/13005569/38749
Interesting! I didn't know that Intel had such a feature. Most vanilla apps will run fine on any Android JVM, but I was wondering how Intel was going to support apps that use the native interface.
I'll bet the average wait time for the line shrinks dramatically if the court rules in the worker's favor. As it stands now, Integrity/Amazon have no incentive to adequately staff the line with security personnel since the workers being checked are off the clock.
SQLite is also used in many embedded systems. If you plug in a USB drive to my TV, it creates a SQLite database to keep track of the current position of the video files it plays.
I used to have an HSBC card that offered 2% cash back on weekend purchases. Capital One acquired HSBC's accounts a few years ago and no longer offers that deal.
I did an analysis on the accurate of Zestimates a few years ago. I took sales data for my county from the previous month (that Zillow had not imported yet) and compared it to the Zestimates Zillow computed. The mean error was almost 0, but the standard deviation was about 20%. An engineer from Zillow wrote to me and said my analysis was close to their own internal measurements. Their algorithms might have improved since then since it sounded like it was something they were continuously trying to improve.
It was on my old blog which is no longer online. I'll see if I can find the article in my backups and post it somewhere. I should probably do the analysis again since my original test was during the end of the housing bubble when prices were unstable.
The hiring managers for most jobs are not business owners. They are middle managers with multiple bosses. Most see the hiring process as an opportunity to show they are management material. If you give them a number that they know you will accept, they can pull whatever levels need to be pulled in the organization to get approval. What they don't want to happen is that they overbid for a candidate who then still rejects the offer. That makes them look incompetent in front of HR and upper management. Most managers would rather just give you a safe offer that you are more likely to reject than a politically risky one that might still get rejected.