Anywhere.re | REMOTE (US) | Full-time | https://myjob.io/Taairww
==================
The Anywhere Real Estate Core Capabilities API Engineering team develops reusable, enterprise capability APIs which are leveraged by both internal & external product development teams use to rapidly build and release real estate software.
Our tech stack is: Node.js / Mongo / AWS shop.
We're looking for:
* Strong backend experience
* Strong REST API experience
* Some project/team leadership
* Mongo / NoSQL data modeling experience
* Node.js on the backend specifically. You've worked on and contributed Node.js-based APIs
* Infra / Cloud experience. Ideally AWS
The interview process is fairly straightforward:
* 30-minute experience screen
* 1-hour pair-programming to build an API endpoint in Node.js and JavaScript
* 1-hour system-design
* 30-minute culture fit
I've been using the following to pick up a new hobby (wood working [surprise]) and start learning about potential business ideas (data/ML space and pet industry):
I'm sure there are topics you're curious about or sound interesting to you. Maybe there's a hobby you wanted to try out? Spend a little bit of time watching YouTube, listening to podcasts, reading blogs or joining discord/slack communities for that topic.
This doesn't have to be some huge investment. Spend an hour or two looking at a topic. This can be in 5-minute increments or a 2-hour block, w/e.
Are you still interested? Do you want to learn more about the topic? Do you want to try your hand at it? Go for it. Go as deep as you want on it, actually make your own version of w/e you're interested in.
Now go talk to people in various communities online. There are so many slack and discord groups out there, you'll find something you connect with. Ask questions. Engage in conversations. If you're feeling up to it, reach out to people to setup video calls. Some meetups are starting to offer in-person events, if you're comfortable doing that.
Still interested, still want to turn it into something more? Check out The Mom Test by Rob Fitzpatrick. It's fantastic guide on how to actually do customer development. Doesn't have to be about making something into a business. He's got great tactical advice on how to get info from people in a regular conversation and learn about stuff.
Been working with Rails close to a decade now. I've built several, non-trivial products using Rails for the API, by myself. What I and my coworkers dislike about Rails is the sheer amount of magic. Oh and concerns, let's not forget that pattern.
Rails is amazing at standing up a CRUD app (really API) in a matter of minutes. I can have a basic CRUD app with authentication, authorization, API, caching, background jobs, local development (docker compose), production in any cloud / k8s and CI/CD done within a day. Adding business logic that's well tested is simple.
Once the app starts to get serious usage, needs to integrate with complex enterprise systems, handle huge loads of data, etc. it becomes necessary to step away from Rails-way of doing things. All of a sudden you can't push more into Sidekiq cause of how much it impacts the DB via ORM loading. Now you're writing custom SQL. It's not all that hard to do in Rails, but at that point, you're writing Ruby and not using Rails magic any more.
Your dismissive comment does not address the realities of building a solution that goes beyond CRUD. It ignores the many levels of experience present on a team or the amount of technical debt one accrues while building a non-trivial production system.
While it doesn't take much experience to get started with Rails or to get a good amount of progress on a product, it takes skill to keep the technical debt under control. Or to make good decisions about architecture. Or to understand which parts of the system to optimize. It requires actual experience building web solutions without the crutch of a framework to know when to ignore Rails and when to double-down on it.
And your dismissive comment attempts to imply that I haven't done "real" work with Rails, but I can assure you that, with 25 years of professional development experience, 13 of which using Rails as my primary stack, I have integrated with many legacy systems, and I find Rails works really well for that, actually. And, while I admit there's usually a place or two in an application to have to "shell out" to hand-coded SQL -- and even more tellingly -- that's usually some of the most-important functions of the application, it's hardly a reason to throw the baby out with the bathwater.
Making good architectural choices for complex problems/solutions is difficult with any framework or language though. What I like with rails is that it's easy to work on the easy parts, but it doesn't stop you to make more complex choices on the difficult parts.
I'm with @greazy on this one. The assumption made is that a set of labeled images is enough. Was the training set validated against a diagnosis based on biopsy of some kind? I.e. the images that were trained on, marked by some radiologist (more likely multiple radiologists), how were they validated to contain cancer or be cancer free? Did someone follow up a few years later and confirm the diagnosis was correct?
Also, different modalities will produce different quality images, how was that accounted for in training models? Did they use all the images for a single scan or a subset of the images of a single scan?
The problem is you're trying to train a model where you have many images for a single scan, like slices. Depending on the modality, you'll get different resolutions, different "visual" inclusions, etc. etc. So labeling the individual images and labeling the entire collection is really hard.
Can this be done using existing PostgreSQL functionality around replicas? I think there's a plugin for PostgreSQL that supports master-master replication as well.
