If you're looking for something dead simple, I'd suggest Mithril. The API is tiny, but powerful, and will give you the tools you need to create reactive views that update to state changes.
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.
This is a tough question to answer. What constitutes "back end" has changed significantly over the last 5-10 years - an Amazon AWS infrastructure engineer does vastly different day to day work from a small startup engineer.
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.
Is Sublime Text already uncool? I'll open another editor if I feel like I need a power feature that's not available, but for general everyday coding it's still my go-to.
Beyond that, any Unix environment is fine with me.
I generally don't recommend EPI for interview prep. I've found that the questions are overtuned in difficulty, and don't resemble anything I've seen at even my Google, Facebook, etc. interviews.
I echo what the other poster said - Interview Cake, LeetCode, and CTCI.
I've never had to pay for transportation to an interview - even rideshare/cabs are typically paid for. I would outright reject any company that tried to make me pay for my own airfare and lodging for an onsite interview.
This reminds me of a court case a decade ago when Blizzard sued the creator of a popular World of Warcraft botting program called MMOGlider on the grounds of copyright infringement. Blizzard won and was awarded $6m. Not a lawyer, but maybe there's some legal precedent?
Hmmm, I suppose I objectively agree with some of the points the author made, but as someone who works with protocol buffers daily, those issues never actually come to be problematic in practice. In fact, I have nothing but positive things to say about protocol buffers and find them pleasant to work with. Definitely a step up from sending raw JSON down the wire.
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.
1. Yes. Microsoft is still well respected, so having it on your resume will likely open doors for you in the future.
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.
My main question is how this offering differs from a UI framework. At first glance, this looks similar to Ionic, Flutter, Cordova, Xamarin, React Native, etc. You're fighting an uphill battle because people these days either want to write native applications or use a JavaScript-to-native framework, so you have to be extremely clear on how your tool is superior or different.
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.
You're absolutely right - SPA bloat isn't directly due to the weight of the underlying frameworks.
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.
The "website obesity crisis" is related to the rise of single page applications and the growing popularity of frameworks like React, Vue, and Angular.
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 think the excitement around using JavaScript as a server runtime has peaked. If you search for node/express on Google Trends, you'll notice the interest leveled off about a year ago. This matches up with my own personal experience - engineers seem more willing to weigh the tradeoffs associated with using JavaScript on the server vs. using other frameworks like Flask, Ruby on Rails, Django, or SAAS offerings like Firebase and Google App Engine. There's a lot more maturity there than there was a few years ago.
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.
It really depends on what kind of development you're doing.
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.
I understand that place of employment is a big part of one's identity, but remember that you're a single Googler, not speaking on behalf of 50,000 of us. You should not be using the word "we" the way you are - it's in poor taste.
I think the "right to be forgotten" law has larger scope than that actually, although I'm definitely not a lawyer.
> 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.
It's even worse than that. Assuming a modest 5% stock market yield, you'll be at ~160k after a decade. At 8% you would have roughly doubled your 100k to 200k.
The average person doesn't need Bitcoin. They need Vanguard.
Less than 7 hours (6 or less) is typically considered a part time arrangement. If you're a high performer, you can try to negotiate for this kind of situation, but it's rare to start a job with that type of benefit. You should expect to lose a proportionate amount of your salary, (keep in mind that depending on your tax bracket, the percentage hit to your take home will be less affected.)
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.
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.