Perhaps another way of thinking about it is in terms of being a market maker versus a speculator. I think of Opendoor as more like the former, where traditionally a flipper refers to the latter.
Can you please write an email to your Marketing Department and pass along a note?
Here's the text:
"While effective in your goal of creating Brand Recognition of 'Open Door' please be informed that the blitz campaign with the radio ad featuring the sound of a doorbell ringing, followed by the company name, 'Open Door,' was one of the most unabashedly Pavlovian ear-worm manipulation techniques I can recall. It almost makes 'Head On - apply directly to the forehead' look like high art. DING DONG - OPEN DOOR! DING DONG - OPEN DOOR!
Because of this tactic, I will never, ever reflect upon the brand of Open Door with anything but disgust. Yeah, you got market share, good for you. How you did it, however, makes me want to puke."
It might sound extreme, but I have a sensitive brain. That goddamn commercial was everywhere. And terrible.
Yeah it was really bad and hurt the brand. Subsequent ones are a lot more appealing and, not kidding, very high quality and effective.
Glad you've decided to take a more mature tack in advertising, but as we all may well know, you only get one chance at a first impression. As such, I don't intend to brow-beat you or your team, just let you know that certain choices have consequences. That commercial was essentially a landmine and if shrapnel happened to take off a limb or two of yours in the process, I hope it's a good learning experience.
Like most companies, we used an agency and gave them a brief containing benefits we want to convey, which they turn into a script and produce. We learned that getting closer to the ads is quite important. We don't work with that agency anymore.
I like that you do code reviews of every commit, do you have any issues with getting people to spend time reviewing? Also, it looks like you have a very broad code base (backend, frontend, mobile, machine learning...), do all of your engineers review code for all of those areas? I've found that in small teams sometimes only one person really understands a particular section of code, which can result in poor quality code reviews. I'm interested to hear if you've experienced that, or if you've managed to work around it.
FYI, the title of https://www.opendoor.com is: "Opendoorflexible-dateno-repairopen-houseonline-processfair-inspectionfast-closinghome-readycustomer-supportfair-offertransparency | Sell your home the minute you're ready.", which looks like a mistake to me. Probably need to add another test ;)
I think everyone on the team understands that helping unblock other engineers is as valuable as writing some code yourself. It generally hasn't been an issue getting timely review, though we have discussed tracking the average size of the PR queue as a metric if review times did worsen.
Most of the time other engineers on your team will review your code, but often engineers will pop across teams and doing code reviews if they have the time and the context. One change we've made is moving towards tagging a few engineers who might have the right context when you submit the PR.
Thanks for the tip about the title; will take a look!
It's mentioned that the "projected cost" logic outgrew Rails, but there's no mention of what that microservice eventually wound up running. I'm curious what you had success with.
The cost structure service is actually what I've been working on recently. We spun up a fairly lightweight flask service (on our kubernetes cluster) that is capable of serving the cost structure to the rails app and for analysis. At its core, it uses a small DAG library we wrote, and on top of that has a migration framework that can represent cost structure changes over time as distinct versions that can be served simultaneously.
I love code reviews, and the code review pipeline, but one issue I keep running into is handling a bottleneck'd review process, and I'm wondering if you have any tips or advice.
How do you stay productive while blocked on a review request?
If you stay productive by swapping to a different task, how do you avoid merge, dependency, and task switching headaches between what's under review and the "back-up" tasks?
I'm not sure if that question is clear, but I'm betting on you having encountered similar enough situations to know what I'm getting at.
We started in 2014 with a Ruby on Rails monolith and Angular frontend, both of which were good ways to move fast while we were very small. We use Webpack to build our frontend apps, and serve them using the Rails Asset Pipeline.
Within your MVP how did you handle authentication between your Angular apps and your Rails backend? I know you implemented Paladin to handle auth between your new microservices but I'm curious what auth looked like in your MVP.
When we first started we used a pretty vanilla version of Devise. The angular application just used session based auth. The easiest way to get the MVP happening was to have Rails generate the landing page of the SPA so we got sessions for 'free'. As we started to add more options for authenticating to the application to handle micro-services and our mobile application we took advantage of Warden/Devise and implemented a custom strategy for handling JWT authentication in addition to the regular session based strategy that comes out of the box.
The JWT authentication is Guardian compatible since we use Guardian to drive Paladin. It was a relatively straight forward addition with Warden/Devise to provide authentication based on either strategy which allows us to take advantage of these different schemes with minimal updates to our core application.
I use Devise most of my Rails apps, so in my ApplicationController I have `before_action :authenticate_user!`.
Did any of your frontend Angular apps send/request data to a Rails controller? If so, did you have to configure your Angular requests to send the session cookie so it would pass the Devise auth? This is the part that I don't quite understand yet.
In my next side-project I want to continue using Rails for the backend and scaffolding for most pages but I have a small React app that I want to include as well (keeping track of stats for a basketball game). But I'm not really sure what's the best way to go about authorizing whether or not the user has the permissions to upload data to a specific profile. I've only ever used Rails/Devise and all user input occurs through a form.
If you could point me in the direction of what I should be Googling for I'd appreciate it. Best of luck with Opendoor!
If you're generating the page from your rails server then the cookie that is set for sessions would be already available and you can make calls without worrying too much about authentication. If you want to use tokens or OAuth strategies there's a bit more to it but you should be able to find lots of information on it with a bit of googling. Here's an article that seems to cover the basics. https://technpol.wordpress.com/2013/09/23/angularjs-and-devi...
I'd usually google for a collection of the tools I'm looking at. To find that article I searched for "spa authentication with rails and devise"
What make and model door knobs do you use? I manage some rental houses and have wanted to automate showings go some time. Do you add a cellular Wi-Fi hotspot temoparily too?
It would have to be Core_kernel, the subset of Core that doesn't interact with the runtime or OS. I'm very curious about this and would like to know, too.
Indeed, js_of_ocaml is kind of shocking in its fidelity. It can compile even highly complex libraries that do lots of runtime tricks. Async_kernel and Incremental_kernel both compiled and worked without any issues whatsoever.
We've even built some support for making incrementally rendered web-apps in OCaml, using Async and Incremental. Here's a link:
It sounds like Bucklescript is doing something quite different, which is to aim for pretty JavaScript output, while compromising and maintaining semantic consistency with OCaml. I don't fully understand the use-case, but for us, js-of-ocaml is clearly the thing we want.
Uh, given that you don't respect ocaml's memory model and force -safe-string, that's just not true. Any Obj.magic that is correct in OCaml is probably not going to be correct in bucklescript.
`-safe-string` is the future. Any compiler can not guarantee its correctness if you write crazy code , `Obj.magic` here.
I am not interested in core personally, but I don't see any reason why it will not work if it is vanilla OCaml
To me this seems like the right approach - either you start with some massive amount of data that's not quite adapted to the problem (think Google), you start with full automation and have to basically write the decision tree yourself, or you generate the appropriate labeled training data like this.
However, it seems like there are some scale issues if you start upmarket like Clara Labs has been. I wonder if there's benefit in having a cheaper more mass-market version as well that can be used to generate larger amounts of data and test algorithms better?
It's certainly possible. One advantage of our setup is that rather than getting ok -to- noisy labels from customers, our CRAs understand the end-goal of the application and generate pretty great data. We are also able to incentivize them to produce fewer errors.
Lynk Messenger | Full Time | Interns | Software Engineers
Lynk is a fast, powerful, and free messaging app that enhances your interactions with friends and the people you meet. Lynk enables off-line chatting via low-energy Bluetooth (no WiFi/data required), and other exciting and unique features. Find us in the app store or head to lynkmessenger.com.
We are seeking full-time engineers (and select interns) to help on all aspects of our iOS, Android, and Erlang backend development. The job is based out of our San Francisco office and includes competitive salary and benefits. Essential to our consideration are intelligence, the ability to work hard and on a team, and a demonstrated passion for coding.
Interested candidates please send your resume, along with a brief email, to [email protected].
Lynk Messenger | Full Time | Interns | Software Engineers
Lynk is a fast, powerful, and free messaging app that enhances your interactions with friends and the people you meet. Lynk enables off-line chatting via low-energy Bluetooth (no WiFi/data required), and other exciting and unique features. Find us in the app store or head to lynkmessenger.com.
We are seeking full-time engineers (and select interns) to help on all aspects of our iOS, Android, and Erlang backend development. The job is based out of our San Francisco office and includes competitive salary and benefits. Essential to our consideration are intelligence, the ability to work hard and on a team, and a demonstrated passion for coding.
Interested candidates please send your resume, along with a brief email, to [email protected].
Lynk Messenger | Full Time | Interns | Software Engineers
Lynk is a fast, powerful, and free messaging solution that enhances your interactions with friends and the people you meet. Lynk enables off-line chatting via low-energy Bluetooth (no WiFi/data required), and other exciting and unique features. Find us in the app store or head to lynkmessenger.com.
We are seeking full-time engineers (and select interns) to help on all aspects of our iOS, Android, and Erlang backend development. The job is based out of our San Francisco office and includes competitive salary and benefits. Essential to our consideration are intelligence, the ability to work hard and on a team, and a demonstrated passion for coding.
Interested candidates please send your resume, along with a brief email, to [email protected].
The student hackathon movement has definitely evolved super quickly in the last five years (as Swift says, 5 -> 150, or more than 100% growth year over year). I'd be curious to hear more stats about how hackathons in general have grown in the same time period.
Given that as far as I know, roads must be extensively mapped in advance of a self-driving car going on them, there is a nice bonus of doing self-driving cars exclusively through Uber at first. Uber can know the exact route the passenger wants to take in advance, and only send cars to passengers whose routes are already mapped. Furthermore, they can choose to only send them out when the conditions are good (no snow, etc. assuming conditions are still a problem when these go into fuller production). A nice way to roll the cars out incrementally without some of the problems they might otherwise have...
