29 karma · joined August 6, 2009
Which is exactly what blind-hiring / blind-auditions are meant to do. The problem, from my perspective having tried to implement it, is that it requires a real cognitive leap from people who are most successful for their social acumen and don't regularly make decisions based on hard evidence. Often those kinds of people have a title with Manager or Officer in it.
Additionally, don't start with big hairy audacious side-projects. If all you've ever gotten to with one project is two days. Define a project that will teach you something that you think you can finish in three days.
I get memory foam bath mats and replace them approx 1-2 times per year. I also have a yoga block and lacrosse ball at my feet so I can change my stance.
I've a 48" monitor on a stand that sits perpendicular to a window so I can look out the window and change focal length while thinking
Headphones are super important to me Massdrop x HiFiMAN HE4XX I wear them even if I'm not listening to anything.
Keyboard is an ErgoDoxEZ with a mousing mode so I never have to take my hands off the keyboard
I use the Mission Control Productivity system and sometimes the Pomodoro Technique if I'm having a hard time getting into flow
in my experience residential internet isn't any less reliable than the commercial internet I had when I went into an office
A nicer microphone is a must have for remote work so that people can hear you clearly in meetings. I use a Blue Snowball
I don't have kids but, if I need to ensure my dog will be quiet for meetings I just give her a kong. My wife is just great about not interrupting me.
Just another media company but, we punch way above our weight class. We handle 10s of millions of uniques a month with only 3.5 Back End Engineers. We also go home on time and sleep through the night without PD going off every few minutes. Our code is mostly Ruby and Rails but, we have a little Go and Clojure. Having just returned from Lambdaconf we're getting ready to start some projects in Elixir.
The job posting in the link does a good job of describing what we do and how (if I do say so myself). Short version; No heros, no assholes, do a good job, and build stuff that allows you to sleep at night under reasonably high load. We are also a remote first team and have an emphasis on learning and development.
The hiring process is mostly blind and is designed to match how we work on a day-to-day basis. There are no whiteboard sessions or brain-teasers.
We're a small team relative to the amount of traffic we handle. We value going home on time, sleeping through the night without pages, and having a profitable company
We primarily work with Rails but, also some Clojure and Go.
Check out the job description for a better idea of what working here looks like day to day.
If you're tired of commuting into an office just so you can put on headphones and try to ignore everyone.
If you want to see your work actually make it into the world and be seen by 10s of Millions
If you're tired of working with a bunch of "Heros" who think it's some kind of honor to sleep under their desk and keep chasing the next crisis
Check us out http://www.apartmenttherapy.com/were-hiring-backend-develope... We are a 100% remote Product team. Our app serves 10s of millions of uniques per month and we do whatever we know to be the best so that we can go home on time and trust the app to be stable.
We use a blind interview process until after the coding challenge.
Use Rails 4. Get things done. Sleep Soundly. Reach Millions.
We see 10s of millions of uniques a month, use the latest stable versions, go home on time, and don't get paged in the middle of the night.
Not all our tasks are very interesting but, we do them the best way we know, without ego, and while trying to always improve.
Even better our readers actually enjoy our site: "This is, hands down, the best kitchen site on the Internet. I can literally spend hours on here because I never feel like there are 'filler' articles."
"In a sea of irrelevant, droning newsletters that flood my inbox daily, Apartment Therapy's is the one I always look forward to and never delete before reading "
We also use a Blind Hiring process so please don't include identifying information in your email :-)
For more info http://www.apartmenttherapy.com/were-hiring-backend-develope...
Use Rails 4. Get things done. Sleep Soundly. Reach Millions.
Reports from a private #slack channel Here’s what people who actually work on this team have to say about working here:
"smart, action-oriented people; everyone always willing to jump in to help; flat team culture"
"working from home is obviously great"
"I feel like our priorities stay pretty solid once they’re defined and on the roadmap; I’ve definitely worked places where they shift so much nobody ever knows what’s going on - definitely a bad thing about other places"
"diverse team is really cool too - everyone comes from a very interesting background"
"coming into this team I was used to using what was easy. seems like the whole team here jumps on board with what makes the most and best sense."
"we’ve also hired people who have a “bias for action.” Like get your hands dirty from day 1 and shine."
Want to learn more?
http://www.apartmenttherapy.com/were-hiring-backend-develope...
The Manifesto values Collaboration over "Contract Negotiation" leaving off the Negotiation part is a straw-man argument.
Similarly, "Responding to Change" it is not the Change that the Manifesto values it is "Responding to Change". What it values "Responding to Change" over is "Following a Plan" not making a plan or doing any planning.
Your response is selection bias. Every project that you've seen is a ball of technical debt. There is no argument to how documentation alleviates technical debt. If you document a poorly designed and scoped piece of software it doesn't make it any easier to change.
If the software was impossible to change and that change was a requirement then the code bases you were working with did not represent "working software"
The agile manifesto says, "working software over documentation." It does not say "working software and an absence of documentation."
The fact that you needed to add features is exactly the reason agile exists. If the creators had a complete feature plan in the beginning and faithfully executed it without deviation from the plan then there would be no need to ever add features and the quality of the code in terms of "changability" would be moot.
Having worked with the Interactor gem for a little while once you break things down into small interactors that can be used by the Organizers, I have two main complaints.
1) inputs are unclear. With calling new or some custom class method you can use descriptive variable names to say what the object expects to be present to do it's job. With the Interactor gem you end up adding in comments describing what keys need be present in the context and what keys will be added to the context so the next programmer can use the interactor you've created without having to go through and grok everything.
2) You end up having to (re)create a failure protocol to communicate with the controller and display to the user. We take the AR errors functionality for granted in our controllers/views with interactors you have to come up with a similar system.
2.5) as a result you end up writing a lot of boilerplate fail! and rollback code
2.5.2) and a non-atomic operation like notifying the payment gateway can break the whole model of rolling back and you have to end up raising so your user doesn't end up in a invalid state or get charged twice.
Learned Ruby in 2002 and started working with Rails professionally in 2006.