Andre The Giant andre-the-giant

## what-hiring-should-look-like.md

      
              1 file
            
          
              28 forks
            
          
              21 comments
            
          
              229 stars
            
          
                getify
                / what-hiring-should-look-like.md
            
            
              Created
              August 14, 2020 21:01
            
          
    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.

  
## code-review.md

      
              1 file
            
          
              0 forks
            
          
              2 comments
            
          
              7 stars
            
          
                smably
                / code-review.md
            
            
              Last active
              February 10, 2022 14:14
            
              
                How to Give a Great Code Review
              
          
    How to Give a Great Code Review


Claim: A great code review is thorough, constructive, kind, and prompt.


Thorough


Effective code review requires that you understand what the PR is trying to accomplish. If there is a ticket or issue associated with the PR, start by opening it and reading the acceptance criteria. Then read through the PR description. Think about how you might approach the problem if you had written the code yourself. What are the constraints? What are some edge cases you would want to watch out for? If you are unclear about any aspect of the problem the PR is solving, talk to the author to clarify before you start looking at their code.
If the author has deployed their code to a QA environment, take some time to try out the new functionality. See whether the actual behaviour matches your assumptions. If not, go back and check the acceptance criteria. If you have any questions or you think you’ve found


## ChromeExtensionGulp.js
'use strict';

//npm install gulp gulp-minify-css gulp-uglify gulp-clean gulp-cleanhtml gulp-jshint gulp-strip-debug gulp-zip --save-dev

var gulp = require('gulp'),
	clean = require('gulp-clean'),
	cleanhtml = require('gulp-cleanhtml'),
	minifycss = require('gulp-minify-css'),
	jshint = require('gulp-jshint'),
	stripdebug = require('gulp-strip-debug'),
	'use strict';

	//npm install gulp gulp-minify-css gulp-uglify gulp-clean gulp-cleanhtml gulp-jshint gulp-strip-debug gulp-zip --save-dev

	var gulp = require('gulp'),
	clean = require('gulp-clean'),
	cleanhtml = require('gulp-cleanhtml'),
	minifycss = require('gulp-minify-css'),
	jshint = require('gulp-jshint'),
	stripdebug = require('gulp-strip-debug'),