Gregg

Screencasting Framework

The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.

Why you should care about screencasting?

You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.

1. Communicating more effectively - At Envy Labs we produce screencasts for our clients all the time. Whether it's demoing a new feature or for a presentation for an invester, they're often much more effective and pleasent than a phone call or screen sharing.

datchley

React/Redux Style Guide

Table of Contents:

• React/Redux Style Guide
  • React Guidelines
    • Organization
    • Components
• Container Components

rttomlinson

{
  "development": {
    "database": "demo_exploring_mongoose_development",
    "host": "localhost"
  },
  "test": {
    "database": "demo_exploring_mongoose_test",
    "host": "localhost"
  },
  "production": {

eashish93

vs Questions

---

1. http://stackoverflow.com/questions/804115 (rebase vs merge).
2. https://www.atlassian.com/git/tutorials/merging-vs-rebasing (rebase vs merge)
3. https://www.atlassian.com/git/tutorials/undoing-changes/ (reset vs checkout vs revert)
4. http://stackoverflow.com/questions/2221658 (HEAD^ vs HEAD~) (See git rev-parse)
5. http://stackoverflow.com/questions/292357 (pull vs fetch)
6. http://stackoverflow.com/questions/39651 (stash vs branch)
7. http://stackoverflow.com/questions/8358035 (reset vs checkout vs revert)

getify

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.