Skip to content

Instantly share code, notes, and snippets.

Keybase proof

I hereby claim:

  • I am dragon-lex on github.
  • I am matsko (https://keybase.io/matsko) on keybase.
  • I have a public key ASA9wsZ6vhKvs99DTMAoonVS_JC0VR9kiXcAA6uiY_yLpgo

To claim this, I am signing this object:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Created on Mon Aug 12 13:40:38 2019
@author: jacob
"""
import cv2
import numpy as np
@dragon-lex
dragon-lex / System Design.md
Created April 18, 2016 19:16 — forked from vasanthk/System Design.md
System Design Cheatsheet

#System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

##Basic Steps

  1. Clarify and agree on the scope of the system
  • User cases (description of sequences of events that, taken together, lead to a system doing something useful)
    • Who is going to use it?
    • How are they going to use it?
@dragon-lex
dragon-lex / preprocessor_fun.h
Last active August 29, 2015 14:27 — forked from aras-p/preprocessor_fun.h
Things to commit just before leaving your job
// Just before switching jobs:
// Add one of these.
// Preferably into the same commit where you do a large merge.
//
// This started as a tweet with a joke of "C++ pro-tip: #define private public",
// and then it quickly escalated into more and more evil suggestions.
// I've tried to capture interesting suggestions here.
//
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_,
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant,

A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.

I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.

I'd love comments and suggestions about any of these.

I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.

I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".