Vinay M rmdort

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'm enjoying doing these raw, barely edited writeups; I hope they're useful to you too)

Feature flags

This is my own writeup on feature flags; for a deep dive I'd recommend something like Martin Fowler's article (https://martinfowler.com/articles/feature-toggles.html).

So. Feature flags. The basic idea that you'll store configuration/values on a database/service somewhere, and by changing those values, you can change the user experience/features for a user on the fly.

Let's say that you're building a new feature, called 'new-button' which changes the color of buttons, which is currently red, to blue. Then you'd change code that looks like this -

It's 2024. You should use tsup instead of this.

Features

🔥 Blazing fast builds
😇 CommonJS bundle
🌲 .mjs bundle
✨ .d.ts bundle + type-checking

This API was removed in React 17

Interaction tracing with React

React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".

With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.

Libraries and Tools for React

If you're developing an application based on React it can be helpful if you don't need to develop all the basic UI components yourself. Here you can find a list with various components, component libraries and complete design systems developed with and for React.

As the list got longer and longer I thought it would be better to have a "real" site for it.

	<!--
	When an input element gets focused, iOS Safari tries to put it in the center by scrolling (and zooming.)
	Zooming can be easily disabled using a meta tag, but the scrolling hasn't been quite easy.

	The main quirk (I think) is that iOS Safari changes viewport when scrolling; i.e., toolbars shrink.
	Since the viewport _should_ change, it thinks the input _will_ move, so it _should_ scroll, always.
	Even times when it doesn't need to scroll—the input is fixed, all we need is the keyboard—
	the window always scrolls _up and down_ resulting in some janky animation.

	However, iOS Safari doesn't scroll when the input has opacity of 0 or is completely clipped.

	interface Person {
	readonly name: string;
	age?: number;
	}

	type WellFormedMutable<T> = {
	-readonly[K in keyof T]-?: T[K];
	};

	const p: WellFormedMutable<Person> = {

	from keras.layers import *
	from keras.activations import softmax
	from keras.models import Model

	"""

	References
	----------
	[1]. Parikh, Ankur P., et al. "A decomposable attention model for natural language inference." arXiv preprint arXiv:1606.01933 (2016).

	from keras import backend as K
	from keras.layers import Input, Dense, merge, Dropout, Lambda, LSTM, Masking
	from keras.models import Model, Sequential
	from keras.optimizers import SGD, RMSprop, Adam, Nadam
	from sys import argv
	import argparse
	import csv
	import json
	import numpy as np
	import pickle

	# -- coding: utf-8 --
	'''Trains an LSTM on the IMDB sentiment classification task with soft attention.

	Experiments with max_features=10000, max_len=80
	1) MLP-dropout-tanh attention: 83.59 at epoch 4
	2) MLP-dropout-relu attention: 83.26 at epoch 3
	3) MLP-tanh attention: 82.91 at epoch 4
	4) GlobalMaxPooling1D attention: 82.44 at epoch 7
	'''
	from __future__ import print_function