I used to work at another BigCorp (around $150,000/yr) and really thought Google pays competitively, but boy was I wrong. Here are two offers that I received recently:
1. Small company: around $160,000/yr + equity
2. Google: no exact number but I was told that for the level I was approved, the base is around $120,000/yr. Apparently my coding skills on a Google doc were equivalent to that of a new grad and they are really trying to low-ball me. Somehow they are under the assumption that I'm "dying" to work there.
If you interview at Google make sure to have other competing offers, otherwise you'll be up for a surprise. Also remember that although they'll tell you that the hiring committee looks at a candidate holistically, only the onsite interviews will dictate your level and the compensation. They don't seem to care what products you've built previously, years of experience, or education. How you code in a Google doc is what seems to matter.
Is there a better way of making sure someone can actually code? It’s easy to take credit for past projects when it’s unclear how much help you had or what part you played. Isn’t the best way to judge a candidate asking them to create/produce something for you?
- A non-trivial take-home exercise and give them a week or two to complete. This should have higher weight on the decision instead of the "Google doc coding" as most likely that's the type of code they'll be shipping to production.
- Use the onsite interviews to improve upon the exercise and/or to get into the nitty gritty details, and also to make sure this is the type of person people would enjoy working with.
- Allow candidates to run the code and to look things up (even Einstein didn't remember how to do long division, he looked it up).
- Give people the benefit of the doubt and assume they are not liars or thieves. If you end up having certain doubts, ask yourself why you have those doubts and take appropriate steps to remove doubts.
And let's be real. Do you think someone with X years of experience having worked at multiple companies (small and big corps) was hired because they couldn't code?
> even Einstein didn't remember how to do long division, he looked it up
Nitpick: the idea that Einstein struggled with school-level mathematics is a myth[1]. I would be very surprised if he ever had to look up the procedure for long division.
I personally hate take home tests that you aren’t compensated for, but I see your point. As to your last point, depends on your definition of “couldn’t code”. I think we tend to give the hiring and HR at companies like google too much credit. Things still slip through the cracks, especially at an organization of that size.
One thing I do with take-home exercises after I'm done interviewing with a company is adapting them and then open-sourcing them (obviously removing identifying information about the company). This has really helped me and I have more side projects to show later on. With that said, I've gone above and beyond with the implementation of these exercises so typically many of them are worth open-sourcing.
People can cheat on take home exercises. At the scale of google, a nontrivial number of people will.
If you'll end up having to do a face to face analysis to make sure someone didn't cheat on a big take home assignment like that, why not just skip to the face to face analysis?
I've used Quill for a large production app and generally it works well, so I appreciate the work that has gone into it. With that said, it falls a bit short on in-depth documentation and the source code is a bit hard to digest.
The Web isn't going anywhere as society today heavily depends on it for all kinds of solutions. Just think how many things we do these days on the Web. So with that said, gaining the knowledge to build useful applications on the Web will lead to a career in Software Engineering. Because a Web Developer's knowledge spans across many different technologies, we typically use titles like Software Engineer, Front End Engineer, Full Stack Engineer, etc.
For example, here is what a Front End Engineer might have knowledge in:
- HTML (semantic markup)
- CSS (layout, animations, responsive, mobile-first, media queries, SASS, etc.)
- JavaScript (the language itself)
- HTTP, AJAX, Promise API, RESTful APIs, async VS parallel
Calling this "nefarious-linkedin" when it's obvious that LinkedIn is trying to protect itself from unauthorized data collection shows that the developer is either seeking for attention or didn't really look into the purpose of those extensions (https://github.com/dandrews/nefarious-linkedin/pull/1)
But how is this data accessible to the extension? I ‘m not an expert, but it seems that this data has to publicly available for an extension to find and parse it. Extensions don’t have magic Auth rights or credentials.
Extensions have the same auth rights as your logged-in account (the ability to see people who are out of network, for example). It’s against LinkedIn’s ToS to scrape data.
True, and I accept this is a potentially good legal refutation of this kind of argument. However, I do consider ToS-es untenable and unjust because of this power asymmetry.
If my computing node is interacting with your computing node, we should either both be able to put restrictions on the use of obtainable information or neither.
And they can avoid me storing their data by not offering it to me. Both are rather lazy arguments.
This is besides the fact that many sites (LinkedIn included) aren't very upfront about what exactly they collect. Also, after a certain point, it gets impractical to have to make this decision for each and every site you visit.
Yes, I get that the extension operates within the user's auth realm. But still it should not be able to access data you as a user cannot access. Maybe this is already enough to do damage though.
1. Small company: around $160,000/yr + equity
2. Google: no exact number but I was told that for the level I was approved, the base is around $120,000/yr. Apparently my coding skills on a Google doc were equivalent to that of a new grad and they are really trying to low-ball me. Somehow they are under the assumption that I'm "dying" to work there.
If you interview at Google make sure to have other competing offers, otherwise you'll be up for a surprise. Also remember that although they'll tell you that the hiring committee looks at a candidate holistically, only the onsite interviews will dictate your level and the compensation. They don't seem to care what products you've built previously, years of experience, or education. How you code in a Google doc is what seems to matter.