345tw4erfd

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.

IMHO a better way would be:

- 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?

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.

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

- DOM APIs, DOM Performance

- UX/UI methodologies

- Accessibility, ARIA

- Module bundlers, transpilers, build tools (webpack.js, rollup.js, etc.)

- Various frameworks and libraries and knowing why and when to use them (e.g. Lodash, React, Ember, jQuery, etc.)

- Programming design patterns, methodologies, and best practices

- Object oriented programming

- Functional programming (.map(), .reduce() and knowing about immutability)

- Test driven development and various testing frameworks/libraries

- Command Line (Bash, and/or other Unix/Linux shells)

- Version control (GIT)

- Data Structures and Algorithms (arrays, trees, DFS, BFS, and more)

- High or deep level knowledge of how Browsers work (the event loop, reflow/relayout, etc.)

- A server side language (NodeJS, Ruby, Python, PHP)

- Databases (MySQL, NoSQL)

- A server side web framework (ExpressJS, Ruby on Rails, Django, Laravel, etc.)

- Security (authentication, authorization, XSS, SQL injections, cookies, and more)

- Ability to deploy a product in a production environment (e.g. AWS)

- Development workflows (GIT, code reviews, continuous integration, and more)

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)