vaibhav da-vaibhav

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

Everything I Know About UI Routing

Definitions

Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
1. pathname - The "file/directory" portion of the URL, like invoices/123
2. search - The stuff after ? in a URL like /assignments?showGrades=1.
3. query - A parsed version of search, usually an object but not a standard browser feature.
4. hash - The # portion of the URL. This is not available to servers in request.url so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things.
5. state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.

Why I use web components

This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.

Let's start by defining what we are talking about.

The Web Components Umbrella

As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.

Error Tracking https://sentry.io
Error Tracking https://logrocket.com
Localisation https://crowdin.com
Localisation https://poeditor.com
Auth https://auth0.com
Continuous Integration https://travis-ci.org/
E2E Testing https://www.cypress.io
Cross Browser Testing https://www.browserstack.com
Code Coverage https://codecov.io
Serverless https://zeit.co/

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.

@broros

otherwise why would he hand over a popular package to a stranger?

If it's not fun anymore, you get literally nothing from maintaining a popular package.

One time, I was working as a dishwasher in a restu

Meownica's packing list

I travel a lot so I'm down to like 30 minutes of packing per any kind of trip. I always bring one carry-on suitcase for any trips up to 2 weeks (that I never check in unless forced) -- I have an Away suitcase because it's got a built-in (removable) battery, and amazing wheels.

🚨

🆔Wallet & Passport
💧Travel water bottle
💳Travel credit cards (don't pay foreign currency fees!)
💳Insurance cards
💵Local currency you have
🚎Local public transport cards

	<div id="canvas"></div>
	<style>
	#canvas {
	width: 500px;
	height: 300px;
	border: 5px solid black;
	position: relative;
	box-sizing: content-box;
	}

	const assert = require('assert');

	//========== Helper functions

	/**
	* Resolves after `ms` milliseconds
	*/
	function delay(ms) {
	return new Promise((resolve, _reject) => {
	setTimeout(resolve, ms);

	#!/bin/bash

	# Invoke like this:
	# ./watch.sh my command here
	# And it will run 'my command here' once, and then when it detects changes.

	# TODO: Don't just search in the last second. Search for updates since the last
	# completed build. Otherwise for big directories, midway through your search
	# you've already taken 1s and you will miss updates.