TrueCar | Santa Monica, CA | ONSITE or REMOTE | Full-Time | https://truecar.com
TrueCar is hiring engineers to help us improve the car buying experience. We're on the verge of finishing up our replatforming initiative, and we're getting ready to re-accelerate our product development and further improve our infrastructure.
A good chunk of our engineering team, including leadership, came from CarWoo (YC S08). We value moving fast, structuring things so that we can keep moving fast, and not being afraid to do hard things. (This is sounds so obvious on HN, but it can be a hard sell sometimes when you're in the automotive industry.)
The core development frameworks we use are Rails and React. Our data stores include PostgreSQL, Redshift, Elasticsearch, and HBase. For infrastructure management, we use Terraform and Ansible. All of this runs on AWS.
Our core consumer- and dealer-facing application is a Rails application with a React frontend, backed by PostgreSQL and Redis. It's an intentionally monolithic Rails API. We also have other Rails apps for data curation, infrastructure management, and data movement to facilitate a lot of the workflows around data that add value and speed up our development.
We've also built internal tooling whenever it helps us move faster or drastically reduce the amount of manual work for our teammates. One of our tools, Spacepods, is a Rails app that churns out identical, isolated development environments (complete with data sets) so there's a mini-TrueCar that each engineer can start developing against immediately, without having to worry about breaking a shared integration environment that other developers depend on. Spacepods also powers our deployments and coordinates our CI/CD pipeline.
Openings:
- Senior Rails Engineer. You've run Rails at scale and know Ruby and Rails really, really well. "Convention over configuration" is always nice to get started, but you've had to roll up your sleeves and configure things, ranging from Ruby VM internals to caching layers to connection pooling. You'd be working on the Rails app that powers our consumer-facing experience.
- Senior Rails Engineer (Platform). You've run Rails at scale, maybe in a smaller company, and have thought to yourself at some point, "If only we had the resources to build developer tools to make our processes better and more repeatable." You'll probably have a lot of fun in this role if you like working on the tooling that gets used by other engineers and get a kick out of enabling others to be 10x/100x more productive.
- Site Reliability Engineer. You know Linux systems, networking, and/or AWS really well. Each team member has a slightly different emphasis but everyone on the team has in common is that we value reliability, observability, and performance.
- Site Reliability Engineer (Data). Measure, monitor, and understand YARN/HDFS/HBase performance in production. Design/architect deployment and verification procedures for data pipelines. One of the overarching and continuing challenges here is to take everything great that everyone loves about DevOps and CI/CD, and apply it to our data pipelines. Inherent statefulness and the size of the data make this a challenge.
- Data Warehouse Engineer. Write ETL to efficiently bring in data from various data sources, enrich it, and make it available to everyone in the company so our decisions are backed by good data. We make use of Postgres and Redshift.
Even if you're not sure you fit in any one of the above, please reach out if any of this sounds interesting to you. (If you read all the way down here, it's a good sign that we should talk!) At the end of the day, we're just looking for smart, determined, pragmatic people who love building things and solving problems. We care less about hitting all the bullet points in a job description.
Still interested, or just want to talk? Reach out to me at jgo AT truecar.com
TrueCar | Santa Monica, CA - San Francisco, CA - Austin, TX | Full Time
TrueCar is hiring Rails, Python, mobile (iOS and Android), and devops engineers in Santa Monica, San Francisco, and Austin. We're also hiring designers.
We acquired the talent of quite a few Carwoo (YCS09) alums a little over a year ago.
We've been around for 10 years and went public 1 year ago. The company has big plans for the coming years and is looking for good developers to help us grow.
We're using Rails and Python (Flask) to serve out all kinds of APIs as well as consumer-facing web experiences and internal tools.
Let's see; what else?
* We prefer you work with us in-person in Santa Monica, San Francisco, or Austin. Remote definitely considered for the right candidates, but you must be based in the United States. We'll handle most visa situations.
* Benefits are exceptional: health premiums are 100% paid for (not only for you, but your whole family), we match your 401k (up to 3% of your contributions), and give stock options and performance bonuses. We also pay for your gym membership (up to $50/month) and have catered lunches every Wednesday.
* Our Santa Monica HQ is right by the beach and Third Street Promenade, so expect fresh air and plenty of food options. Our SF office is right off the Montgomery BART station with 360 degree views of downtown and the bay.
* A meaningful subset of some of the technologies we use: Ruby on Rails, Python, Flask, Redis, MySQL, Hadoop, and Elasticsearch (the whole ELK stack).
* VISAS are handled and REMOTE options are available under the right circumstances.
Send an email to me (Josh) (jgo AT truecar.com) with your resume and/or GitHub profile. Even if you're not applying but just have questions, drop me a line.
We're using Rails and Python (Flask) to serve out all kinds of APIs as well as consumer-facing web experiences and internal tools.
Let's see; what else?
* We're remote-friendly.
* Benefits are exceptional: health premiums are 100% paid for (not only for you, but your whole family), we match your 401k (up to 3% of your contributions), and give stock options and performance bonuses.
* Our Santa Monica HQ is right by the beach and Third Street Promenade, so expect fresh air and plenty of food options.
* A meaningful subset of some of the technologies we use: Ruby on Rails, Python, Flask, Redis, MySQL, Hadoop, and Elasticsearch.
Send an email to me (jgo AT truecar.com) and I'll personally see to it that your resume and/or GitHub profile get looked at. Or heck, even if you're not applying but just have questions, drop me a line.
That's why, in many countries in Southeast Asia (Thailand, Malaysia, Burma, the Philippines), you eat your meal with a spoon and a fork; the spoon goes in the right hand and the fork goes in the left. You push food onto the spoon and shove it into your mouth. Try it sometime. It's the most efficient way to eat rice. I find it even more efficient than the East Asian way of picking up the bowl and using the chopsticks to move the rice into your mouth.
If you've ever eaten at a nice sit-down Thai restaurant, that's why they'll give you a spoon and a fork. I've had this confirmed by friends whose families were from Malaysia and Burma. If you're looking for the most efficient way to eat rice, this is it.
For a "few extra hours," this is excellent. And I like the route that you're taking by trying to produce as faithful of a reproduction as you can. It's set to basically be a drop-in replacement. Keep doing what you're doing. I love it.
This is a legitimate concern, but the subject of this article concerns issues that directly affect the interests of the HN community. It's clear to many of us that political grandstanding, personal drama, and he-said-she-said do not belong on HN.
At the same time, many current and aspiring startup founders have embraced the cultural shift to learning about traditionally non-technical areas such as sales and marketing. And rightfully so; this is after the previous shift (or "great opening up") to learning about design and a good user experience.
We've done all this because there's no escaping the cold, hard reality that the success of our companies depends on getting the word out and selling people on our ideas. Good code is not enough.
The skyrocketing cost of public pensions in California affects the solvency of the state government. When the state government is desperate and must make ends meet, tax hikes are the first and most obvious options, and are always taken into consideration. When you're thinking about starting a company and setting up shop in Silicon Valley, the tax burden is a huge factor to take into account.
As things stand today, the benefits of the personal network, concentration of talent, and the established tech ecosystem in Silicon Valley are still more than enough to outweigh the comparatively high tax burden for those who wish to start and operate a successful company. "Political" articles like this are of interest to us because they tell us about important future changes in the formula we use to calculate where we want to set up shop.
It _was_ originally just a place to post links, but I think it's clear by now that it's grown into something much more. Many of us value HN for the quality of the conversations -- there are so many other places (like our personal Twitter feeds) where we can find links of interest.
Much of the value we get is from the content we all generate through these comments. It's clear to me that there's room for improvement when it comes to giving structure to all the great stuff that's discussed here. My gut feeling is that a wiki isn't the right way to go about it either, but there is certainly a lot of quality content being generated here.
I agree, but unlike the early US, a startup country would stop once a while to see what has organically grown and proliferated, then unify the hodge-podge that results by refactoring. This would lay a proper foundation for further incremental growth.
I'm going to second this, and flesh it out with my own angle.
Although you're asking for the advice of VCs or entrepreneurs and there's definitely a personal aspect to the problem, what I'm getting here is a sense that the major hurdle being faced is technical: the code sucks, there's a lot of it, and nobody understands it.
I have found from personal experience that fixing a big, complicated code base is possible. What it will take is some smarts and determination, both of which I'm sure the author of the original post has plenty of. And if you want to end up with a good design, keep it centralized by owning it as the architect with the final say, but leverage your team because they provide invaluable feedback that you can incorporate into the design or disregard as you see fit.
Involving the team in the design also means that you're not the only person who understands the general architecture of the newly designed, refactored system. But you having final say means that someone's responsible for it, someone's on the hook for it, the design is coherent, and that it gets done.
In my case, it was our entire payments system, which was (and continues to be) critical to our business. At the time, the site was live and was taking payments so it was working -- but only like it had been held together with duct tape. Querying our data for insight was maddening, because database tables weren't even named according to what they contained! The guy who was in charge of it before had just been fired, and nobody really understood his code.
Which left us in a precarious situation, like the one you describe. More so, because we were already live. I started off by fixing small bugs here and there, which was a pain at first since I had to learn the inner workings of this deeply flawed system. I took the risk of slowly going insane as I slowly built up a mental map of these poorly named, poorly organized data tables until I could navigate around them as if I had written it myself.
After a while, even a jacked-up architecture starts to make sense in its own crazy way.
But it's dangerous to stay in that place mentally for long, because then you get used to thinking that way.
So I volunteered myself for the task of refactoring it.
Everyone thought I was a psycho for taking it upon myself -- which made it much easier to get everyone to agree to give me final say. The thinking was, "Hey, if you really want to hurt yourself like this, go ahead." But since the messed-up payments data model was affecting the ability of the team to do their jobs, I knew I could count on their input to be as helpful as they knew how.
So, I hit ArgoUML and LaTeX hard as I planned out the redesign. (Those are my preferred tools for architecting and planning. Unusual combination when a Rails project is involved, I know.)
I went through several drafts and ran it by our DBA, who also wears the business intelligence hat, and he told me about really basic metrics he wanted to measure, but couldn't with the old data model. My immediate supervisor, also experienced in architecting, offered suggestions but made it clear that I had final say. Another roll-up-your-sleeves Rails engineer also threw in a few suggestions for how we'd represent the various payment schedules we offered our customers.
This input was crucial and several times pulled me out of the thinking that I had become accustomed to with the old data model. It was scary how willing I had become to keep certain messed-up aspects of the old data model, but that's where exposing the design to the fires of peer review came in. I could have just disregarded everyone's suggestions, but having to give an explanation for why I wanted something to be a certain way forced me to really think about everything.
As for your situation, it sounds like you've got at least some semblance of a good team there to email around these samples of bad code; they can be invaluable in reviewing any proposed design. I know that my team was.
In some way, you'll have even less of a burden should you choose to redesign or refactor. Since you're not live yet, you don't have to worry about data migrations for older data. About half my time on this project was spent thinking about how to move existing live data to the new data model. If you can avoid that, count yourself lucky so that you can focus more of your effort towards building a really clean data model, knowing what you know now.
For those of you who work in Rails, there are a couple of rake tasks that do this already. I just found out myself while mucking around a couple of days ago.
I use Amazon EC2 for several reasons. They basically boil down to having everything I want with little hassle.
- I can hold my own as far as basic sysadmin functions go, and I like having control over the entire software stack. A lot of Amazon EC2 machine images can be stripped bare to give me only what I need.
- I don't have a lot of money to blow on a dedicated machine each month, so it's nice to at least have a running environment even if it's virtualized (and therefore slower). At least I can know if my code works out in the wild.
- I pay only for what I use. There's also the option to leave it on and pay in advance (Reserved Instances). So whether my projects end up being just small diversions or whether they gain traction, there's a pricing plan I can go with. It was meant for companies to scale up and down, but I've actually found it useful for scaling my personal projects up and down.
- The management tools are pretty good. ElasticFox is clunky at times but it has everything I need without a whole lot of hassle.
- Elastic IPs. I can claim a static IP if I wish, or just choose not to use it.
Amazon has exposed a lot of stuff over their APIs, but don't be fooled into thinking that this means they added layers and layers of cruft akin to all the useless software that comes on new PCs. The APIs just work on a meta level -- useful if you want to package up machines and that kind of stuff -- but if all you need is a Linux box with good bandwidth for your personal projects, give Amazon a shot.
There's also the added bonus that they're, well, Amazon. And they're not going away anytime soon.
> “Most of the emphasis within the company is on the next couple of years, and we tend not to think about longer than that,” says Peter Norvig, Google’s director of research.
Does anyone else, after having read this article, find that it isn't really about what the title suggests? There's no direct admission or direct quote from anyone at Google about what scares them.
The closest this article comes to telling us what scares Google is extrapolating that Google's slightly different method of developing products (fail fast, fail often) is a sign that they're scared. It's quite a stretch.
The Atlantic may be a venerable publication, but the title on this one sure looks like linkbait to me.
TrueCar is hiring engineers to help us improve the car buying experience. We're on the verge of finishing up our replatforming initiative, and we're getting ready to re-accelerate our product development and further improve our infrastructure.
A good chunk of our engineering team, including leadership, came from CarWoo (YC S08). We value moving fast, structuring things so that we can keep moving fast, and not being afraid to do hard things. (This is sounds so obvious on HN, but it can be a hard sell sometimes when you're in the automotive industry.)
The core development frameworks we use are Rails and React. Our data stores include PostgreSQL, Redshift, Elasticsearch, and HBase. For infrastructure management, we use Terraform and Ansible. All of this runs on AWS.
Our core consumer- and dealer-facing application is a Rails application with a React frontend, backed by PostgreSQL and Redis. It's an intentionally monolithic Rails API. We also have other Rails apps for data curation, infrastructure management, and data movement to facilitate a lot of the workflows around data that add value and speed up our development.
We've also built internal tooling whenever it helps us move faster or drastically reduce the amount of manual work for our teammates. One of our tools, Spacepods, is a Rails app that churns out identical, isolated development environments (complete with data sets) so there's a mini-TrueCar that each engineer can start developing against immediately, without having to worry about breaking a shared integration environment that other developers depend on. Spacepods also powers our deployments and coordinates our CI/CD pipeline.
Openings:
- Senior Rails Engineer. You've run Rails at scale and know Ruby and Rails really, really well. "Convention over configuration" is always nice to get started, but you've had to roll up your sleeves and configure things, ranging from Ruby VM internals to caching layers to connection pooling. You'd be working on the Rails app that powers our consumer-facing experience.
- Senior Rails Engineer (Platform). You've run Rails at scale, maybe in a smaller company, and have thought to yourself at some point, "If only we had the resources to build developer tools to make our processes better and more repeatable." You'll probably have a lot of fun in this role if you like working on the tooling that gets used by other engineers and get a kick out of enabling others to be 10x/100x more productive.
- Site Reliability Engineer. You know Linux systems, networking, and/or AWS really well. Each team member has a slightly different emphasis but everyone on the team has in common is that we value reliability, observability, and performance.
- Site Reliability Engineer (Data). Measure, monitor, and understand YARN/HDFS/HBase performance in production. Design/architect deployment and verification procedures for data pipelines. One of the overarching and continuing challenges here is to take everything great that everyone loves about DevOps and CI/CD, and apply it to our data pipelines. Inherent statefulness and the size of the data make this a challenge.
- Data Warehouse Engineer. Write ETL to efficiently bring in data from various data sources, enrich it, and make it available to everyone in the company so our decisions are backed by good data. We make use of Postgres and Redshift.
Even if you're not sure you fit in any one of the above, please reach out if any of this sounds interesting to you. (If you read all the way down here, it's a good sign that we should talk!) At the end of the day, we're just looking for smart, determined, pragmatic people who love building things and solving problems. We care less about hitting all the bullet points in a job description.
Still interested, or just want to talk? Reach out to me at jgo AT truecar.com