Anton Nikolenko nikolenkoanton92

Frontend Technical Interview Prep

EDIT: Well this has been linked now so just an FYI this is still TBD. Feel free to comment if you have suggestions for improvements. Also here is an unrolled Twitter thread of a lot of the tips I talk about on here.

I've been doing frontend for a while now and one thing that really gripes me is the interview. I think the breadth of knowledge of a "Frontend Engineer" has been so poorly defined that people really just expected you to know everything. Many companies have made this a hybrid role. The Web is massive and there are many MANY things to know. Some of these things are just facts that you learn and others are things you really have to understand.

Every time I interview, I go over the same stuff. I wanted to create a gist of the TL;DR things that would jog my memory and hopefully yours too.

Lots of these things are real things I've been asked that caught me off guard. It's nice to have something you ca

Note:

When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.

A Gentle Introduction to Prepack (Part 1)

If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:

Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.

Idiomatic React Testing Patterns

Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.

Setup

I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern that gives great defaults for each test example but allows every example to override props when needed:

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

Example: Moving up to a few commits to another branch

Branch A has commits (X,Y) that also need to be in Branch B. The cherry-pick operations should be done in the same chronological order that the commits appear in Branch A.

cherry-pick does support a range of commits, but if you have merge commits in that range, it gets really complicated

git checkout branch-B
git cherry-pick X
git cherry-pick Y

Git Cheat Sheet

Commands

Getting Started

git init

or

Font Face

A mixin for writing @font-face rules in SASS.

Usage

Create a font face rule. Embedded OpenType, WOFF2, WOFF, TrueType, and SVG files are automatically sourced.

@include font-face(Samplino, fonts/Samplino);

	package main

	import (
	"v/utils"

	"os"

	"github.com/go-playground/validator/v10"
	)

	(function()
	{
	"use strict";

	function test(label, co)
	{
	let times = 3000;
	function * g1(){ return 1; }
	function * g2()
	{

	var Router = require('ampersand-router');
	var app = require('ampersand-app');


	function auth(authLevel, fn) {
	return function () {
	if (authLevel === 'required' && !app.me.loggedIn) {
	this.redirectTo('/login');
	return;
	}