RUBY ON RAILS END ENGINEER
Position title: Ruby On Rails End Engineer
Reports to: CTO
ou would be working on the backend component of new features from start to finish which would include everything from early prototypes to getting the production server ready to checking for security concerns.
If you want to see some examples of our Design Templates, visit the Placeit website.
Who are we?
We started as an agency, called Freshout in 2008. We developed new products for companies such Linkedin, Telefonica, eBay. When we realized we couldn’t control the products we built through our clients, we started to invest in our own products. We bootstrapped our way to a product company in late 2014. We were acquired by Envato in late 2017!
We currently have 180 employees in our GDL office. Between our products, we serve over 8m users.
This is not some satellite office where we send some of the “special” work. We invest heavily in the education and progress of each member of our team. We have full autonomy over what we build and there are no clients forcing our hand to build unnecessary features.
Placeit is used by everyone from Adobe to Yelp to Facebook to Google to Salesforce to IBM to Netflix. We’ve doubled in size over the past year and have thousands of paid subscribers.
The answers below are meant to address the most frequently asked questions. If we missed any, please don’t hesitate to let us know.
Video → Learn about our engineering culture here ←
What general skills do I need to perform well in this position?
You need to know how to:
Be clever about how to approach problems
Be technically curious (learning on your own)
Have a serious interest in understanding the goal behind your workPush for doing things the right way the first time around
Have empathy for our users
Know the basics of Photoshop
Any background in programming graphics or video games
What technical skills do I need to perform well in this position?
You need to be familiar with the following:
Ruby on Rails
Web sockets and web workers.
Unix: bash, piping, SSH, tools (cat, awk, sed), basics of standard input/output
Basic principles of database design
What are the required baseline technical skills for all levels of engineers there?
Here is a list of what we consider baseline fundamentals that you need to be familiar with no matter what area of the platform you work on:
Basic experience with ORM
Software Design Patterns
Functional Programming Principles
Even Oriented (including asynchronous) Programming
Object Oriented Programming
Prototype Based Programming
Coding Best Practices
Refactoring Best Practices
Test Driven Development
Possess a good understanding of the syntax of Ruby and its nuances
Solid understanding of object-oriented programming
Experience designing, building large-scale Ruby on Rails applications
Experience with common libraries such as RSpec and Resque
Proficient understanding of code versioning tools (e.g. Git, or SVN)
Proficient in bash shell
Familiarity with continuous integration and delivery
Basic familiarity with networking systems, load balancers, and TCP/IP network constructs.
Knowledge of performance and reliability monitoring strategies
A knack for writing clean, readable Ruby code
Able to create database schemas that represent and support business processes
What’s the salary like?
Your offer will generally be above the market rate in the local market.
We’ve listed the salary range on the job position but once we learn a bit more about your specific skills, we can give you an exact offer.
We take into account quite a lot of things when determining the offer. You’ll want to take a look at this document to get an idea of what we value.
If you can provide value, your offer will reflect that.
What’s the management style?
Video → Learn about our engineering culture here ←
Honest, truthful and always focused on improving.
Your manager will most probably talk you very straight. We don’t sugarcoat things. We like to communicate clearly so we can focus on improving rather than covering things up.
Our incentive structure and alignment values are all around trying to -> try to set up an environment for you to be as productive as possible with the assumption that you have the will and intention to do so.
That means everything from setting clear product goals to a great office environment to autonomy when you've earned it.
If your goal is to do great work and deliver value, you’ll have a great relationship with your manager.
What does it look like to work there?
Please see the videos posted in this job listing.
How quickly can I get a promotion?
Depending on where you started and how quickly you’ve been improving, as quickly as 2 months.
In order to create a transparent and fair process for raises, we worked on creating a framework we call Value Alignment. It’s made up of many factors from user empathy to pure technical skill to collaboration.
It’s meant to provide a really easy way for you to know how to provide value to the company so you can ask for some of that value in a form of raise.
You can read the documentation here.
What are the benefits you provide?
We provide private health insurance of your choice, IMSS, paid trips around Mexico, free lunches on Wed/Fridays, paid educational courses and unlimited kindle books.
What does your engineering process look like?
We do believe that most people have a planning bias so most would think that we spend quite a bit of time in trying to clear and organize our minds before starting any task. We call it “X Workflow”. You can read about X Workflow here.
We’ve also documented our process for bug fixing. You can find it here.
We also set aside 1 week every 8 weeks for any code improvements each engineer would like to focus on. This allows you to have time set aside for any refactoring you’d like to do without asking for the time.
We try to automate testing as much as possible. With 3 products out there, we don’t have a single dedicated QA person. We try to optimize our team such that a QA team should be unnecessary. Every person inside the company acts as decentralized QA departments (from customer service to CEO to engineers).
What does the flow look from the beginning to deploy for a particular feature?
You get a feature request from product manager
You make sure you understand the goals clearly and collect basic information
Assuming it’s time to work on it, you’d start with the specifications (detailed in X Workflow document).
The document generally starts with describing the problem, a bit of background and your hypothesis for the approach you’re going to take.
Then you would work on the high level solution proposal
And lastly would be your Blackbox (if needed), Theory of operations and functional specs.
Once those are approved, you can start coding!
Once your code is ready, you would deploy to staging to test your work.
If ready, you would then send your code for final review.
If ready, then it would be deployed to production after OK from CTO.
Lastly, you would go back to update your specification with any future work that you believe this feature needs.
The specification document and our general process for approaching new feature development is documented here called X Workflow.
How much autonomy do I have? Will I be micromanaged?
You’ll have a quite a bit of autonomy as long as you follow two basic rules. One is to be objective and the other is to be transparent. As long you’re following those two guidelines, you have full autonomy on how approach your work.
We always want to see that you have a proper line of logic when you’re approaching problems so you don’t tax the product and the company later down the line where it’s much more expensive to fix.
Our optimal method of working is to be openly and proactively sharing your progress, metrics and thought process behind your approach. Through this method, we keep each other in the loop so that we don’t have disasters happen.
The CTO and a peer is usually involved in approving specifications and deploys.
What are your plans for growth for long term?
We've added 30 people in the past 2 months and have doubled in revenue over the past year. We're planning on growing our Design Templates category in many ways but the general idea being to -> be able to design whatever you'd like within the browser but through a form-based interface.
How’s the work/life balance there?
Most engineers are here between 10am to 6pm although some come earlier and leave a bit earlier. Some days they stay later and some days they leave earlier.
We generally keep an “adult policy” over these things. The idea is that you’re responsible and we’re not going to babysit you. We don’t really focus on the hours you spend the office. Our focus is mostly on how efficient you are.
We’re flexible for people that want to start work earlier and leave earlier as well.
Can I work remotely?
If you want to work remotely for the first month or two before committing to move, that’s ok with us but we’re generally not considering remote workers at this point but if you want to send in your info, we can take a look.
We ideally want you to be here in our GDL office.
I like the position but what if I’m wrapping up a freelance project currently?
That’s ok. We can work on a part time basis (has to be at least half time) for the first month or two. This approach works out well so you can see if this is a good fit for you before committing 100%.
Will you pay for my relocation?
Do you guys help with my paperwork if I’m not a Mexican citizen?
What language do you guys use inside the office?
We tend to go between Spanish and English quite a bit but if you only speak English, that’s ok too.
Life at Placeit
Our engineering team is fairly small given our company size. We only have 9 total engineers that work on our image processing engine, main app that handles listing and selling our products, and our video engine.
Within our ecosystem of services, we currently serve more than 8 million customers worldwide. We have projects ranging from working on our frontend Canvas/WebGL engine to working on scaling to video processing servers to our resdesign to a new AI-based design tool we're releasing soon.
Our engineering culture is highly collaborative environment that's heavy on getting clarity on problem approach before "starting" your work. That includes lots of tiny protos and once the clarity is there, technical spec'ing.