This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
@catalinmpit offered some great answers to What are the hardest parts about working from home?. On that last point, check out this "How to turn off at the end of the day" discussion thread from way back:
Comment Not Found
@spoike pointed out a gotcha in response to a truly wonderful post: ⭐️🎀 JavaScript Visualized: Promises & Async/Await:
Loving the article and the visualizations!
There is a gotcha however, setTimeout(..., 0) will not immediately put the task to the macrotask queue because of browser throttling. While the result will be the same, the reason why setTimeout fires last is because it is queued up in the macro task queue "a lot" later (4ms) rather than it being a macro task.
That setTimeout is throttled is why Node environment has setImmediate. For more information about browser throttling: developer.mozilla.org/en-US/docs/W...
@jwp talked about the ongoing battle to continue learning in Dear Junior Web Developer...:
Aren't we all Juniors at this? I mean there's too much to know right? I spent 15 years in C# and still don't know it all. My 7 years in Typescript makes me know it but not yet a master. Rxjs is a career to itself, not to mention HttpClient work. Angular could be a full career as well as CSS. Oh and what about database work and webserver work. Don't forget Security, and now the cloud... There's just too much to know so we just have to keep at it.
Look at IDEs, I use Visual Studio Code every day but am no expert in all it does. I've been using Visual Studio for 20 years and still don't know it all.
What about desktop applications, we have multiple choices, including Electron... How many people really know electron? Things we knew about just 5 years ago are dead now, killed by technical debt caused by other things being better.....
We're all in same boat, as Juniors just trying to survive, through consistent hard work.
@gergelyorosz added on to a wonderful article: I Passed The Google Technical Interviews; You Can Too. with some thoughts of their own:
This is a nice overview of the Google interview process - thanks a lot, Emma!
As a hiring manager now at Uber including for frontend, and talking with several other hiring manager friends at other larger tech companies (Amazon, Facebook, Netflix etc) the frontend interview process is not too different for larger tech companies and the tips shared here would apply at those places as well.
Some places - like Amazon or Uber - also have a Bar Raiser round onsite, that is similar to the "Teamwork, Process & Culture Fit Interview" described here.
The main suggestion I have for anyone preparing for interviews is to go back to basics on web development basics (like the topics Emma listed very well on the Front-End Interviews) and to spend time to prepare for data structures interviews and solving simple - not necessarily tricky - algorithms questions. Most places don't ask this to test if you have advanced algorithm knowledge. They do this, to see how you can map a problem, turn it into code with a simple solution (the brute force solution), test it, and potentially optimize it. This, second part is something that most people would fail without preparation upfront - preparation that will be useful for the rest of your career, I would add. I would not go deeper than the topics Emma listed: but, I would go deep into them and master these tools. So e.g. being able to implement a BFS or DFS (breadth-first-search or depth-first-search) is something almost all places will expect people to be able to write working code for, if asked. BFS and DFS is especially true for Google, where trees and graphs are a bit of the DNA of the company.
Thanks again for this great overview!
@ekafyi talked about their reasons for using Tailwind in Looking for a CSS framework that I don't have to fight against it (also Vue Framework):
I'm going to be unoriginal and be the nth person to recommend Tailwind!!
I used to refuse Tailwind's approach because I found it messy, and I was adamant about "separation of concern" (ie. CSS class names should describe content not presentation) etc. I tried as much as possible to stick to BEM. But as I work in a large web app where features are added, removed, and modified regularly, and I have to create quick prototypes (add to that, I also struggle with the visual side of UI design). Things get messy, I couldn't be as disciplined as I'd ideally be about sticking to the CSS methodology, and vaguely presentational class names like .card, .sidebar and .dropdown start to get thrown to the mix. Then I thought what the heck, might as well go the Tailwind route. And I never looked back! Tailwind is soo helpful for my use case.
I also happen to use Laravel, which has built-in postcss support so I can use the Purgecss feature by literally copy-pasting some 3 lines of code. Slimmer minified build css, more productive & happier dev!
See you next week for more great comments ✌
Top comments (1)
Congrats to @catalinmpit , @spoike , @jwp , @gergelyorosz , and @ekafyi for making the list this week!