- Add your project logo.
- Write a short introduction to the project.
- If you are using badges, add them here.
The traditional technical interview process is designed to ferret out a candidate's weaknesses whereas the process should be designed to find a candidate's strengths.
No one can possibly master all of the arcana of today's technology landscape, let alone bring that mastery to bear on a problem under pressure and with no tools other than a whiteboard.
Under those circumstances, everyone can make anyone look like an idiot.
The fundamental problem with the traditional technical interview process is that it is based on a chain of inference that seems reasonable but is in fact deeply flawed. That chain goes something like this:
Moved to Shopify/graphql-design-tutorial
If you'd like to experiment with Terraform on macOS locally, a great provider for doing so is the Docker provider. You can get set up in a few simple steps, like so:
Install Docker for Mac if you have not already.
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
<?php | |
$mysqlCommandPath = 'to be filled'; | |
$mysqldumptCommandPath = 'to be filled'; | |
$remoteDbUnsername = 'to be filled'; | |
$remoteDbPassword = 'to be filled'; | |
$remotePort = 'to be filled'; | |
$remotHost = 'to be filled'; | |
$remoteDb = 'to be filled'; |
#!/usr/bin/env bash | |
### | |
# A CMD or ENTRYPOINT script for a Dockerfile to use to start a Nginx/PHP-FPM | |
# | |
# For more details, see 🐳 https://shippingdocker.com | |
## | |
if [ ! "production" == "$APP_ENV" ] && [ ! "prod" == "$APP_ENV" ]; then | |
# Enable xdebug |
The question was asked why I (as a programmer who prefers dynamic languages) don't consider static types "worth it". Here | |
is a short list of what I would need from a type system for it to be truely useful to me: | |
1) Full type inference. I would really prefer to be able to write: | |
(defn concat-names [person] | |
(assoc person :full-name (str (:first-name person) | |
(:second-name person)))) | |
And have the compiler know that whatever type required and produced from this function was acceptible as long as the |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
#!/bin/sh | |
command="${*}" | |
printf "Initialized REPL for `%s`\n" "$command" | |
printf "%s> " "$command" | |
read -r input | |
while [ "$input" != "" ]; | |
do | |
eval "$command $input" | |
printf "%s> " "$command" |