621 karma · joined January 13, 2015
The major downside to using highly unopinionated frameworks like Mithril is that the burden of project organization is on you. But since this is a personal project that you can use to learn FE development, I think it would be a good fit.
For you specifically, I'd recommend picking up a web development framework like Ruby on Rails. It will teach you every aspect of building websites: Interacting with databases, writing server endpoints, creating front end web pages, user authentication, deployment, and probably version control. I would consider all of these things to be the bread and butter of typical "back end" engineers (except for maybe the front end stuff.)
From there, you can broaden your knowledge in any direction that interests you. If you like building interactive applications, you can look into front end frameworks like React or Vue. If you want to focus more on back end, you can learn more about relational databases (Head First SQL is a great beginner resource.) Lots of directions you can go.
This line should do the trick:
for (const node of document.querySelectorAll('.commtext')) {node.className = 'commtext c00'}
Beyond that, any Unix environment is fine with me.
I echo what the other poster said - Interview Cake, LeetCode, and CTCI.
Granted, the application I'm working on is fairly boring/vanilla so maybe I don't feel the pain points that come from going off the beaten path.
2. No. Microsoft's compensation is generally below Facebook/Google's compensation packages. Be sure to keep cost of living differences in mind though.
3. I personally value options at $0. Unlike RSUs, which are actual stocks, options' value is derived from the difference between the value at strike and the value at liquidation. You'd have to be extremely lucky for your options to be worth more than the money you could be making at a tech giant.
4. It depends on the climate of the place you're working at. If you think it wouldn't be received negatively, go for it. You're the best judge here.
5. You can try to negotiate (it's always worth trying,) but you'll likely fail. Standard negotiating tactics don't work at tech giants due to the large volume of applications received and number of offers being extended. This is doubly true because you're early in your career, so you don't really have the experience needed to leverage a better offer out of thin air.
One piece of criticism is that while the technology looks neat, the UI doesn't look professional. You're competing with frameworks that have exceptionally polished UI elements out of the box. If design isn't one of your core competencies, I'd highly recommend hiring (or contracting) a designer to help you build a good looking set of UI components, or at least a good looking demo.
I think what I was touching on more was the fact that SPAs generally encourage engineering practices which lead to more complexity and page bloat, and that many teams don't think about these maintenance difficulties when initially picking their tech stack (as proven by the number of bloated, slow SPAs on the internet.)
A well engineered SPA won't suffer from the issues I outlined in the original post, but getting to that point has a non-trivial cost which has to be considered. As usual, it's all about picking the right tool for the job - teams need to make sure they're getting a net benefit from using this sort of application architecture vs. a server oriented one.
Having worked on many SPAs in my career, I've noticed a similar pattern which has happened on essentially every project I've worked on. I call it the SPA descent into madness.
Initially, a SPA is probably the fastest way to start prototyping a UI. You don't even need a server - just throw some HTML, CSS, and JS onto the page, add some mock data, ReactDOM.render, and you're off to the races. All of the UI logic is handled by your frontend framework, and the backend exposes an API the frontend interacts with. Peachy.
But every non-trivial project hits an inflection point where things start to get tricky. In a classic server rendered website (e.g. Ruby on Rails, Django, etc.) you can add as many features as you want because the size of the server binary doesn't really matter. This isn't the case for SPAs - every feature and every additional dependency bloats the size of the JavaScript bundle.
To combat this, developers do route-based code splitting, but oftentimes this isn't sufficient - critical pages usually have the most features stuffed into them, which means they can't be reduced in size enough. Server side rendering can be effective, but now your data model needs to exist on both the client and server, so hopefully you took this into consideration. If not, it's common to run into situations where your application's model layer is partially duplicated across your client and server.
Are all of these problems solvable? Sure. There are great, performant SPAs with millions of lines of code. But let's be real - most organizations wont solve these problems due to lack of engineering ability, time, or politics. The path of least resistance with SPAs is to shoot yourself in the foot on performance, so that's what tends to happen. It's the reason you see these insane 3MB bundles on text based webpages. They started with good intentions, but never got the love necessary to make a large SPAs work well.
All this to say: Make sure you're picking the right tool for the job. SPAs have a low upfront cost, but can have unexpectedly high long term costs. A sprinkle of JavaScript on top of a server rendered page, with a few tricky components backed by a light framework like Inferno, Mithril, or HyperHTML, is oftentimes all that's needed.
I doubt that JavaScript on the web client is going anywhere. While wasm is interesting, it's still not really ready for prime time. These days if you're a frontend web engineer, you're forced to use JavaScript or a transpiles-to-JavaScript language.
The interest in JavaScript as a mobile runtime is still exploding. Searches for React Native have only been increasing over the years and shows no signs of slowing down. Compare this to iOS swift, which is trending down in popularity.
If you're wondering whether the JavaScript ecosystem is still a useful one to learn, I wholeheartedly believe it's not going anywhere for the foreseeable future.
The majority of software engineers are application developers making CRUD websites or mobile apps, so that perspective is the one to come up most often. I also happen to be one of those developers.
The challenges of application development are related to transforming data, handling asynchronous operations, managing state, and picking elegant abstractions that solve your problems. The intuition for these things is mostly picked up through hours of professional development, seeing good code, and shooting yourself in the foot a couple of times.
While there are some harder problems in app dev which do require deeper computer science understanding, they're extremely rare. I suspect this is different for people doing things like video game development, although I don't have any experience there so I can't speak to that.
> After a request is filled, their removals team reviews the request, weighing "the individual's right to privacy against the public's right to know", deciding if the website is "inadequate, irrelevant or no longer relevant, or excessive in relation to the purposes for which they were processed".
While any individual might personally engage in risky behavior, it's not correct to make a blanket recommendation. As the number of people who follow risky advice increases, the chance of someone being negatively impacted approaches 100%.
This is why we have public policy to force seatbelts in cars, and why everybody should vote in elections - behaviors adopted on a wide scale can have significant societal impact even though the benefit to the individual is insignificant.
The average person doesn't need Bitcoin. They need Vanguard.
The benefit of being officially on part time is that it sets everyone's expectations and shouldn't negatively impact your promotion trajectory, especially if you're able to fulfill your duties on a part time schedule.
Interview Cake should be your first stop - the questions are the closest to what you'll actually see in a tech giant interview, so the effort to reward ratio is good.
LeetCode is your bread and butter. With any remaining time, grind these problems.
Cracking the Coding Interview is both too easy and too difficult, very few questions hit the sweet spot. Read the section on behavioral questions though. Elements of Programming Interviews is too challenging, I'd skip it.
Optimize for number of problems solved, which means coding in the site's online text editor. I wouldn't code in your own personal text editor because you do want to avoid autocomplete. If you feel like you need practice actually writing on a whiteboard, you can do that a few days before the onsite.
Pretty much every company you've heard of uses a similar technical phone screen -> onsite with whiteboarding process. If you're not somewhat proficient at them, you're greatly limiting yourself.
Most banks also have a mandatory security question, which makes it marginally more difficult to get brute forced.
Source: Used to work at a bank. Would not recommend.
In college I had 12+ hours/day I could spend doing anything I wanted, even accounting for classes, studying for midterms, etc. Multiply that across 4 years and you have 17,000 hours to spend all of your energy on. Some people do choose to go down that rabbit hole, and out of those people some will be successful.
Now that I've been working in tech for a few years, I feel lucky if I can find the mental energy to work on something for 4 hours/day outside of work.
I'm still annoyed by this entire debacle but I'm not sure what the correct solution for a lost PIN should be.
At Google, the "frontend" work also usually includes the server which serves the frontend code - this means engineers need to be not only capable at UI development, but also be familiar with the Java systems that exist at Google.
From this perspective, frontend at Google is indeed similar to a full stack role at most startups running on AWS or GCP. Backend at Google is more like working on AWS itself.
http://www.tylervigen.com/spurious-correlations
With today's headline driven media, it's especially important to guard yourself against correlational relationships being implied as causative. It's not about saying whether something is true or false, it's about being skeptical and using the correlation as a starting point for further investigation.