Great article in the WSJ yesterday outlining the desire that hiring organizations have around identifying candidates better. At the least, in a way better than a resume would provide.
read more here:
http://online.wsj.com/article/SB10001424052970203750404577173031991814896.html
A lot of you have asked for a way to include text-only questions, and now you can! We’re now letting you mix text and video questions into one interview questionnaire. The default is still video, so you just have to specify which questions should only allow text answers. See screenshots below.
First, expand the Options link under each question and check the box to make the question only accept text answers.
When the candidate reaches this question, they will only see a text box – no video required. In the candidate management dashboard, there’s now an icon specifying the type of answer (top is text answer, bottom is video answer):
This feature is already deployed and ready for use today – give it a try! If you’re not yet a customer, get started today for free and stay tuned for more great features coming soon!
How To Fail A Job Interview – Watch more Funny Videos
We often hear our customers ask “What if my candidates don’t have a webcam”? Our standard reply used to be that since Active Interview is a video based interviewing tool, they must have a webcam to participate. Not anymore.
We’re happy to introduce a feature that many customers have asked for: automated phone interviews. Now, if a candidate doesn’t have a web-cam or are experiencing problems configuring their machine, they have the option of continuing with a phone-based interview (a text-only option is also available).
In the phone-based interview, candidates call in to our toll free number, where the questionnaire will be read to them one question at a time. The candidates’ answers are recorded and uploaded to our servers. The recruiting team can then listen to the answers right from their Active Interview management console, just like they would with video answers.
Click through to hear the results of an example phone interview:
http://cglee.activeinterview.com/share/3218caa05965512061cb3d8b85
For our existing customers, no action is necessary to activate this – it’s available immediately to all your candidates. This is just one of many features in the pipeline, so stay tuned to this blog or our Twitter for updates!
Marco Arment, founder of Instapaper, recently wrote about the backup method he uses for that service.
First of all, props to Marco for writing that post. It’s a selfless act to blog about your technical processes and methods, and especially when it opens you up to “armchair hacker” criticism. Sharing of these kinds of different methods is really valuable to us DIY-ers / lean start-up guys and gals. It’s in that context, and in the context of horror stories like Mag.no.lia (total data loss) and Github (testing vs production db wires crossed) and CodingHorror.com (images lost) that ActiveInterview just audited our data protection & backup methods. These are smart people running awesome sites – if it can happen to them, it’s worth stepping back for a few days to review what we’re doing to prevent a similar scenario from happening to us.
Our service at Active Interview does require an additional layer of backup that (I think) is different from Instapaper, since our application works around not just data stored in a DB, but also a large amount of files associated to candidate interviews (videos, video thumbnails, resumes) as well as our customers file data (company logos, etc).
1. We outsource our storage and server infrastructure to Amazon (read our AWS Case Study).
2. We’re a lean start-up. Backup are managed by developers (and we like it that way).
3. We use mostly open-source / commodity technologies.
1. All user generated file data should live in at-least two secure places at once.
Even though we use S3 for our user generated content data store, and S3 has data redundancy baked-in, we go a step further and backup data “off-site” from Amazon with another vendor at a non-Amazon data center. We’re hedging against not just our vendor’s technical issues, but also operator error on our end. Whenever we move data between servers, all transfers occur over SSH (password-less) with scp/Rsync. Rsync has a variety of friendly option to help you from overwriting/deleting files on your target server, which is a nice precaution. We regularly ping our backup server and use a Webmin system check to test that it’s there and healthy.
2. Database data should live in two secure places at once.
At the simplest level, this can be solved via Master/Slave replication. This works great for if the master dies, but isn’t going to help if erroneous code deletes data on Master, as that DELETE will quickly replicate over to the Slave. Binlogging as Marco describes can solve this problem in simple cases, as you can rewind/edit/replay the binlog. Just in-case we can’t restore properly from a rewind/replay-ing of the binlog, we also do aggressive (hourly) snapshots of the database. Note that you should Flush/Lock the database before you do a SQL dump, to ensure data consistency. With MySQLdump you can use mysqldump with –flush-logs and –lock-all-tables. It’s also important to recognize that mysqldump is only a realistic option when your database is fairly small. Dumping data is fairly quick with large DBs, but it’s the import time that will kill you. For backing up and restoring sizable databases, look into using a binary snapshot tool like InnoDB hotbackup.
As we take our hourly db sql dumps, we copy them over to a S3 bucket dedicated to backup files. And then we Rsync the same db backup file to the offsite (non-Amazon) server.
3. In-case of disaster, be able to restore everything to a running state in less than 3 hours.
There are several ways we can do this, depending on the nature of the disaster.
4. Document & audit the recovery process at least once a month.
We document everything needed to recover any part of our data or infrastructure in a Google doc that is shared among the dev team. The responsibility to audit the backup/restore process rotates each month across team members. We run through the restore process every month… cost of firing up a new EC2 instance for that afternoon ~$3. Cheaper if you use spot prices 
5. Database permission should be as granular as possible.
This mean the primary webapp does NOT use root access. This is a pretty common development practice that frighteningly seems to creep into production setups. Spend the extra 60 seconds setting up a non-root account w/ appropriate ACLs. Since we use DB backup scripts, those scripts have their own users with read-only (SELECT only) rights. Remote access from the office to the production DB is allowed, but only through password-less SSH, and again only with a SELECT only db account. Basically if you are going to insert/delete/edit anything in the production DB, you’re going to have to go through root access from the shell. We logwatch all server activity to monitor any suspicious behavior.
6. File level/S3 permissions should be granular as possible.
Pretty obvious, but you don’t want to have write or execute access to any part of the application or data directories on the web-server for system users that don’t need that access. You’re playing with fire if you “chmod 777″. Similarly, when files are copied over to S3 buckets, the appropriate API call is made to set the correct ACLs on that S3 object.
7. Prevent production data leakage.
As a part of Marcos posted method, backups are also sent to his home computer. I strongly disagree with that process. As mentioned by many comments on HN, this is a direct vector for data loss. Even if your service doesn’t appear to store anything confidential, IMO there is a reasonable and implicit expectation from consumers that their data is not residing on a home or laptop computer. Since people re-use password all the time, all it takes is a lost/stolen table of passwords mapped to web-mail email addresses to create some real havoc, despite the application not seeming to store anything confidential. Even many encrypted passwords are vunerable given enough time.
Unrelated to backups: It’s reasonable that developers may want production data on their development boxes to play with, which may be laptops they take home with them. In this case, we’re thinking of writing a script that either scrubs or randomizes the data when it gets pulled down from production into a dev environment.
So there you have it – 7 simple rules for data protection. Here is a corresponding diagram of our described backup architecture:
Active Interview and one of our customer, OLPC, are featured in today’s edition of The Globe and Mail.
Read the full article here: The video job interview: When your face precedes the face-to-face.
“
The virtual interview was the only way Bryan Stuart could keep his non-profit organization’s budget in check when he hired 35 people for One Laptop Per Child’s internship program. It also was much easier to get candidates to submit recorded videos, which he could review at his home office in Wilmington, Ind. whenever he had spare time.
With plans to deploy interns around the world to co-ordinate laptop distribution programs, language skills were critical. While many cited proficiency in multiple languages on their resumes, Mr. Stuart knew there was one way to test those claims: one of the interview questions required applicants to answer in a second language.
That question startled applicant Federico Volio, a student in Atlanta, Ga. who was visiting his family in Costa Rica at the time, but it also impressed him.
“It really just gives you a good impression of how much they care about who you are,” he says.
He rattled off an answer in Spanish with ease which, in part, won him the internship.
”
Even back then, they could have used Active Interview.
“It’s going to be a long day people.”
Hot off the internet press is the newest Amazon Web Services (AWS) case study… and it’s Active Interview!
We’re big fans of Amazon’s amazing cloud services. And like some other exceptional webapps, we use them for much of the underlying infrastructure that powers Active Interview. In our case, AWS is the building block of our video capture, storage and serving features. We were more than happy to participate in a case study for them and are really happy with the final writeup:
Read the full report here: http://aws.amazon.com/solutions/case-studies/active-interview/
We’re big fans of 37signals and of Jason Fried, especially their philosophy on product development, customer service and branding. So we were naturally very pleasantly surprised to see Jason’s latest article in Inc magazine talk about hiring, and specifically, the problem with resumes.
We built Active Interview precisely because we hated dealing with resumes. The pain of sifting through stacks of similar looking resumes and then coordinating follow up phone or face to face interviews leaves much to be desired. This process takes up so much time, and in the end, we can’t even be sure whether we are interviewing the most outstanding candidates, or the ones who only looked best on paper.
Jason proposes several other factors to focus on instead of examining resumes:
All the points listed are great, but I think they are all getting at an underlying issue: get a better feel for the candidate. Again, this is precisely why we built Active Interview – to allow decision makers to quickly get a solid feel about many candidates in the shortest amount of time. With recorded video screenings, hiring managers can quickly determine all the candidates’:
Jason also goes on to say hire the best, regardless of geography. Again, we couldn’t agree more. Active Interview gives you the ability to quickly get a feel for candidates worldwide. Just ask our beta customer, One Laptop Per Child, who processed over 150 candidates worldwide, from Austin to Africa.
So we agree with Jason – forget about resumes!
Facebook
Twitter
