Monthly Archives: January 2015

We are still hiring!

Today when I met with one of our new hires, he mentioned that he read my database blog even before he joined Enova. These are great news for me, because now I hope that may be more people are silently reading my blog, and may be, some of them will be interested to know, that we are still hiring!

Our recruiters ask us to post this link to our blogs, which I am doing with great pleasure.

Job Description
Database Developers report to one of our Engineering Managers, and work with production databases and software that serve thousands of customers per day around the world.

Our Database Development Team:
Each member constructs our core data repository for the business, feeding all other functions, and directly supporting Enova’s web applications. Projects can vary greatly, be it simply improving our databases, frameworks, and applications; or designing new subsystems to support 3rd party integration. We have a passion for data and quality and are seeking others who share our enthusiasm.

We are constantly driven to work harder and learn new things not from some top-down initiative, but from the feeling that we owe it to our peers to keep up with their growth. We have passionate debates about technology with consensus in solutions, flexible team structures, an irrelevance of title in problem solving, and a desire to Do The Right Thing.

As a Database Developer you will quickly have your code in our production databases and applications and be responsible for significant projects impacting the business, while designing and implementing significant database subsystems. To get ramped up in a timely fashion, you’ll go through a 30-day intensive training program where you are paired with a mentor to learn through interaction, lecture, and literature. No one grows as fast as the teacher, so once you’re settled in you can expect to be called upon to mentor others, including future new hires.

We speak this language:
We work with the absolute cutting edge of database technology. Our tools include PostgreSQL, psql, pgAdmin, bash, your favorite editor, and custom in house frameworks—plus . As a solid performer and contributor to the team, you can expect to attend national conferences, networking with core contributors to the PostgreSQL database community and further enhancing your skill set.

This is where YOU come in:
As a Database Developer you will:
Work in a full-stack team on business-critical projects.
Challenge decisions about the data we need to collect and leverage.
Work with Stakeholders and other teams on building the right solution.
Create schema, data structure, and design components for storage of critical assets.
Build tools that others use to keep ahead of the industry and competition.

You’re right for this job if you:

Have a Bachelor’s Degree in Electrical Engineering or Masters Degree in Computer Science or equivalent
Are a self-starter with a passion for databases
Have 1-5 years experience in a PostgreSQL, Oracle, or Sybase database environment
Have a solid understanding of SQL and database design
Have proven experience designing a transactional database in 3rd normal form
Have experience in a production database environment
Have experience with a stored procedure language
Have UNIX or Linux experience

Kudos to you if you:
Have experience working with PostgreSQL
Know Ruby on Rails
Know Perl, Python, or C
Have experience leading a team

Are you there? I need you!

Leave a comment

Filed under Companies

How to decide, what’s worth optimization

I want to talk about one optimization I did on Friday, and about why I’ve spent literally half a day on this optimization.

We all know, that we can’t “optimize the whole world”, and that each time we want to optimize something, we should first try to estimate, whether the optimization effort is worth the gains we’ll get.

When we have a long report, which runs for 2 hours and eats up all server resources, we know we should optimize this report.

When we have an application controller action which is executed for 30 seconds, because the screen rendering requires 500 database calls, we know that we need to optimize the Ruby code and reduce the number of calls by executing “smarter” SQL statement.

But what if a background job is slow? Most of the time we want to optimize a batch job, if it is executed often and effects other jobs, for example, if a job runs every 15 min, and it takes 5 min per execution. If a batch is only executed once a day, most of the time we say “it’s OK if it’s slow”, unless it’s really slow.

Now, guess what I was doing on Friday: I’ve spent more than three hours to optimize the background job, which only runs once a day with the execution time about 2.5 min.

Why this job absolutely needed to be optimized? Because of the way it was written: the first statement reads virtually all payments for all loans which exist in the system. It was taking “only” 2.5 min, because currently we have a very small number of loans in the system. If we plan to increase this number a thousand times within the next year (which we plan), the execution time would increase proportionally.

So the most important thing in my optimization was not the fact, that I’ve improved the execution time from 2.5 min to 6 seconds, but the fact that now this execution time will increase very insignificantly, when the number of loans in the system will increase. Besides, the new job is using way less resources (the original job was creating three huge temporary tables, which almost blocked the possibility to test it in the development environment).

And I am really glad I caught this situation early enough it didn’t cause us serious problems!

Leave a comment

Filed under SQL