Hiring new innovative rock-star talent with a self-starter personality is something we constantly think about every day at QGenda in order to provide the best customer experience during high growth. Although now with 30+ employees I’m a bit removed from the hiring process, but it was not that long ago when I personally interviewed each and every candidate along the way.
Here are some hiring tips we use at QGenda:
- Attract candidates by asking fellow employees to recommend people they know, attend college career fairs, and post job listings on linkedin.
- After casting a wide net and gathering hundreds of resumes, filter them down by looking for certain key indicators about their technology prowess. For example, are they using a modern tech savvy email interface like GMail or are they still sporting a comcast or bellsouth email address.
- Once the candidate passes the key indicator filter, a quick 10 to 15 minute phone interview can tell you a lot about a person. We like to break the ice with one of the most important questions during a phone interview by asking “Tell us something/anything about yourself that is NOT on your resume.”
- If the candidate passes the phone interview, the next step is to bring them in for an in-person interview where they will take a tour of the office, meet as many existing employees as possible for a corporate culture fit, take a written test with subjective & logic portions, and lastly work with 3 others to solve logic problems on a white-board.
The process above ultimately helps us hire candidates that are motivated to do whatever it takes to succeed, make unequivocal eye contact, and speak logically with conviction. Hiring new employees is one of the most exciting parts about growing a business and is far from a science, but using some basic guidelines can help streamline the process.
What are some other key indicators or guidelines you use when hiring new employees?
Over the last two months our development team has been migrating QGenda’s automated physician on-call scheduling application from our own fully owned geographically separated cabinets of servers, switches, firewalls, and load-balancers to Amazon Web Services (AWS) Elastic Compute Cloud (EC2). We set out with a plan to replicate our current production environment using AWS, and along the way have experienced certain glitches worth mentioning for others planning to utilize AWS EC2.
Here are some main tips and gotchas learned in our AWS migration:
- The Elastic Load Balancer (ELB) has a default timeout of 60 seconds and drops any long running HTTP(s) requests exceeding this limit (such as generating a downloadable data intensive report on the fly). Solution: Submit an AWS support ticket asking them to extend the timeout to their maximum of 17 minutes.
- If your application requires SSL, it’s usually always best (performance wise) to decrypt the SSL on the server instead of offloading the decryption to the load balancer. This is especially important when using AWS because decrypting on the ELB would mean your data would travel in plain text within Amazon’s network from the ELB to your server(s) which other AWS customers could potentially intercept.
- AWS Elastic IPs (EIP) provide a static public facing IP address that can be assigned to any EC2 instance, however the EIP does not have a static internal private IP. If he EC2 associated with the EIP is rebooted, then the internal private IP changes, which can cause troubles when mirroring a database. Solution: Write a script to monitor the internal private IP or use Amazon’s VPC.
- The AWS Developer support for $49/month is worth every penny. It provides you with email support where they will respond within 12 hours. Another great support resource is the AWS community forums.
Switching from fully owned geographically separated hardware to AWS is definitely something each business should consider. It does not always make sense for every cloud application, but for QGenda’s needs it works perfectly. Just make sure to test, test, and test extensively when moving your production environment to the cloud.
Have you migrated your application to AWS, if so, what tips/gotchas did you run into?