Upsolve (YC W19) | Senior Software Engineer | Remote US | Full Time | https://upsolve.org
Upsolve is a nonprofit that helps low-income and working-class families improve their financial situation through free online education, tools, and community.
We have helped 16,000 families erase $700 million in debt, increased the average user’s net worth by $118,000 over 10 years, and average 4.9 stars out of 5 in over 1700 google reviews.
We're looking for a Senior Software Engineer to help build new AI-driven customer support experiences, improve the success rates of our existing flows, and enhance automation to make our users lives easier using typescript/node/react.
We review the web presence of a business as our core product offering for payment processors, etc. as they look to onboard ecomm merchants. This (and techniques like it) make a great way to find scummy actors and have a proveable piece of evidence as opposed to a 'yea, this looks off' or 'this doesn't fit the profile of what an established business looks like'. We leverage a lot of subtle signals like this.
I've found rapidfuzz to be a good, digestable C/Python integration. It's especially nice as the algorithms implemented in C frequently have good pseudocode or other language representations, so you can reference really well. The docs are in reasonable shape as well:
Seriously. As an engineer and engineering leader, I cannot maintain focus to code, sit in meetings, and a variety of other tasks for more than 2-3 hours without a break. It is good to get up, move around, catch up on the news, etc. Taking appropriate breaks and conducting self care gives my mind an opportunity to decompress, allowing me to come back to work more focused and productive. Very long sessions (5+ hours) without a break tend to run into a wall - I may still be doing work, but the quality drops precipitously. Sometimes, I can raise my productivity by distracting myself with home chores (e.g. laundry). Sometimes, I find a quick dip into the news or a catchup on our friend group's discord server productive. This may not be the same for all of us, but studies have repeatedly shown breaks improve productivity for most individuals. Being outside the office, I find it much more convenient to take a productive break without having other coworkers distracting me. Looking over studies and suggestions, it seems interesting to me that tasks like meditation, power naps, small chores, snacks, listening to music, and interacting with pets are much more easily conducted in the comfort of our homes.
ZoomInfo is in the same general area on quality and the price per record is competitive, but they have historically required a high minimum annual spend and have a reputation for litigiousness. There are a few other large players (e.g. apollo), a few medium sized players (e.g. coresignal, mixrank), and some smaller players (e.g. thecompanies, bigpicture). There are also a lot of other folks who are not as api-oriented and are more focused around the sales/marketing experience (e.g. seamless.ai)
For a typical db.t3.xlarge instance, you're talking about 29c/hour vs 27.2c per hour. That's $157.68 as the total difference for one year's runtime, when the whole instance cost for postgres would be $2540.4 for the year, or about 6%. The larger the machine, the closer to parity. Given the absolutely small difference, I hope this isn't the dividing line in any commercial project.
Generally speaking, it's inadvisable to 'discard' migrations with django. If the migration set is getting too large, the general practice is to 'squash' migrations, which is a django-supported function for merging the migrations down to a single app. You can do the less blessed, but more simple function of nuking the migrations, updating the migrations table, and remaking your migrations... but you have to coordinate that in every environment.
For an existing database, you can easily create django models for each table, etc. There's a --fake option to update the migration table to make it think you've applied these migrations, but not actually apply them. This convinces django you've brought the database in sync. May your deity or deities help you if you did not actually bring it in sync. I've used this quite a bit in some java ee->python migrations I've done in the past.
I think this is a really naive idea, I think you're seriously underestimating the level of complexity in a real estate transaction. You're dealing with what is for many people is the most impactful and expensive purchase of their life. In that transaction, they have imperfect, limited knowledge of the market and acquisition process. Further, there are varying levels of dishonest actors within the process - with an extreme range of dishonesty present. Top that off with the fact that you're actually negotiating with imperfect information as well... :exploding_head: Having an actual expert present who can enable you to be successful is extremely empowering and much more likely to result in a positive outcome.
Now, all that being said, it's obvious there's a deficit of actual SME's who are extremely helpful in the process. I've purchased two homes... one with an agent who I feel would fit right in with the culture of the used car salesman stereotype and another who actually was that SME. She knew the market inside and out, knew what to look for in the neighborhoods, and found the problems in each house we looked at. She had connections that got us through a weird mortgage issue (multiunit home converted into one with... sloppy paperwork), helped with specialized inspections (radon issues), and provided great advice when dealing with a cantankerous negotiator. I certainly didn't find my money wasted there and actively recommend her for anyone in the NW Columbus, OH area. There's a lot that could be done to improve the situation - higher requirements for education and qualification of realtors, prohibiting companies from being the buyers and sellers agents, etc. There's a lot to automate as well. But when there's serious complexity and life changing quantities of dollars floating around, an expert should be strongly valued.
Our latest release should have more clear language on airports and 'All London Area Airports' as opposed to 'City of London Airports'. The point about multiple airlines should also be addressed.
Your point about at a glance determination of the departure/arrival airport is really good. I expect to have a UX enhancement for that next week. Currency and manually selecting multiple airports are still a fair ways off.
Thanks. Our roadmap isn't currently public, but this is on it. That being said, this is a medium-term priority, so definitely not something coming in the next couple weeks.
As a simple example, United probably isn't going to offer a flight where one leg is on United and another is on American. Yet, it might be substantially cheaper or less painful to take that flight. Certain codeshares may be more profitable for them to hawk, to the point where they will only show certain legs when the more profitable flight is booked. They may also choose not to show flights that are already profitable based on bookings (e.g. takes 75 economy seats to make flight with legs A->B and B->C profitable) when a similar flight (A->D, D->C) is underbooked and could use some more folks aboard. There are probably a thousand other reasons...
Your gut reaction is not wrong. That being said, I think it's wise to pick the right time to leverage this capability. Our resources are extremely limited at the moment in comparison to one of the most aggressively litigious entities in our space.
I don't know which is the biggest, there are a lot of known unknowns still floating around. Will we run out of money before we monetize? Will we have to deal with constant lawsuits? Will other innovators in the space attempt to move in our direction? Are there enough travelers willing to install an extension? Will google be google and shut us down? The ever present bus factor. All of these are legit concerns that are going into our crowdfunding risks disclosures. All are things to manage.
I don't think this is a big city thing. I live in a medium sized city in the states and I hate going to the airport. 20-30m commute there, parking, walk, wait in line, go through the scanner, inevitable pat downs, cinch back up the belt, etc. Not what I look forward to. On our long term feature list is adding commute time and time to get through the airport to the timeline view as an optional setting, as well as potentially factoring that into our pain algorithm. This is really handy when you're flying to/from a big city like London or NYC, where airport choice my matter at a particular day/time. A similar long term add is factoring in having to go through customs on a layover. This is another awful part of the flight experience we can track and influence decision making through.
Re: codes: yup, that's a bug and will be fixed (or at least the obvious one will be...)
Re: performance - this is on our radar, and we'll keep chipping away at making things a little better as we go. We do have some limits based on system characteristics, but the primitives available to chrome extensions for system information are limited (praise WECG - there's a lot of bad that can be done with too much info).
Re: ballpark dates - This is on our radar, but is both a thorny interaction and below the priority of a few other things users commonly request. No firm commitments on dates as such... but yes, it's a useful tool when you know you want a "May" vacation, and you want a reasonably priced flight that is comfortable.
We don't handle the booking, we redirect you to the travel site that we found the best price on. Many online travel search agencies and metasearch sites can put together itineraries the airlines don't offer directly.
1.) When a user reports an issue to us, it is much easier to find any issues in our error reporting stack. if we have their name and email address attached to the issue as opposed to asking them for all the search terms, time of issue, etc. and then hunting through to see if we've already found (and hopefully fixed) the issue. This practice started when we were a paid subscription, and I've found it useful to continue, especially with a very small team supporting a set of highly asynchronous interactions with scripts running across multiple websites and pushing data back to a common source.
2.) There are contractual requirements for some of the data that we've purchased to be protected from copies of those databases being made. Placing it behind an auth wall and leveraging account based rate limiting for API endpoints met our partners' needs.
Candidly, the Firefox extension framework is significantly nicer. Blam'ing chrome.runtime.lastError.
There's a lot of small amounts of work to get everything working right using the webext module. We're slowly chipping away, we've eliminated all our dependencies on chrome specific modules in the last month while working on other functionality, but we're a really small team right now with competing priorities, so this will get more priority as we get more people on the team.
Upsolve is a nonprofit that helps low-income and working-class families improve their financial situation through free online education, tools, and community. We have helped 16,000 families erase $700 million in debt, increased the average user’s net worth by $118,000 over 10 years, and average 4.9 stars out of 5 in over 1700 google reviews.
We're looking for a Senior Software Engineer to help build new AI-driven customer support experiences, improve the success rates of our existing flows, and enhance automation to make our users lives easier using typescript/node/react.
link: https://jobs.gusto.com/postings/upsolve-inc-senior-software-...