Transcript: PathAI - Robby Grodin

I'm Will Vincent.

This week I'm joined by Robbie Groden of Path AI to talk about how they're using Django at scale.

Hi Robbie.

Why don't we start there?

So I grew up in New Jersey and I went to school at Northeastern here in Boston for music technology, which is electronic music composition and synthesis and you know, all kinds of, you know, just focusing on using technology to make and analyze music.

Um so different background than you're typically, you know, gonna hear in these types of cases.

But um while I was working with those tools and also I gotten a really cool part-time job at a company nearby called Cakewalk that makes music technology uh software, I was able to get really close to the tools that I was using to make music, and I thought, wow, this is really cool.

How do people make this stuff?

And um I took a summer class in Super Collider, which is a Lisp derivative that you use to generate music, and I kind of just picked it up really quickly and was like, oh, cool, I want to learn more about this.

Added in another major, and I just kind of took off from there, was immediately um getting involved in projects like the um Java music specification language, adding XML parsers to that, and started working.

Um, I did a co-op.

Um, the N Northeastern has a great co op system.

I got to work at Blackberry for six months, and um you know back

And nowadays I have to say Blackberry because everyone's like, what's RIM?

But this was actually when everything exploded.

This is when all the layoffs happened and

Yeah.

So you just finally and was this up in Canada, right?

It's about like 30, 40 people.

So it was Andover Mass.

Yeah, Andover Mass.

It's a random team to be located there.

I I didn't so I didn't really learn a whole lot of positive things, I would say.

I learned a lot of things that I want to avoid and and mistakes that can be made.

But um, it was it was definitely um a cool anecdote to have early on in my career that has followed me.

But I think you've also worked in a number a couple other really interesting companies.

I think Box as well.

I went to a music tech startup that literally a month after I got there folded, uh, which was a weird situation for me as a new college grad whose girlfriend moved out with him as well.

Um, and then I ended up at Visa for a short period of time.

Um, you know, corporate environments don't I don't last long there.

Um so I did go to Box for a year, which was really cool.

This was my first experience of um getting to work on APIs at scale.

And uh it was great though.

I got to learn a lot of really cool things about uh reliability.

I was a code reliability engineer on their um content API team.

So I got to learn what happens when things fail catastrophically.

So to this day, every time I'm kicking off a project with someone, I always ask them, well, but what happens when this fails catastrophically?

Exactly.

That's what you know we're gonna focus on today.

There's so many things that until you've blown up a huge database or had these problems, it's hard to mimic it.

In the abstract.

So we're recording this here in Boston, and you know, like you, I used to live out in the Bay and now I'm back in Boston.

So I always like to ask people, what brought you back?

Um, you know, I I'll be honest, and it it the the culture out there, professional culture, is really not for everyone.

Um, so it really just was not for me.

Um, I think, you know, I kind of went out there with this goal in mind of I want to spend a year or two here and I want to really try to like jumpstart my career, work at difficult companies, you know, get a lot of experience.

Um, it just it didn't, I don't know.

It was just something about the environment.

It was a little bit too much, too, too much tech all the time.

So I remember like Yeah, that's

It's it's because even here in Boston, I mean, there's a lot of tech, but there's a lot of medicine, there's a lot of other things out there.

I mean, it's amazing, especially at first, but it is really all tech all the time.

I just I recall because live music is my biggest passion, and I remember going to a concert and not being able to hear the band over people talking about their startups in my ear.

Right.

So you've you've been here what, a year now?

six months?

Yeah, closer to six months, yeah.

What is what is Path AI?

So we look at pathology as the ground truth in medicine, right?

So let's say you've got some concern or your doctor has some concern about a mole on your body or a lump, etc., you go and you get a biopsy.

So that's just a bunch of matter taken out of your body, a small amount of matter really, and um placed onto slides.

So historically speaking, um, to make a diagnosis, and um if there is a diagnosis, then uh um to you know discuss or uh recommend treatment, what a pathologist would do is look at that glass slide through a microscope.

And that is the same way it's been for hundreds of years, and it's incredibly error prone.

Um these like

But now if you're talking about some of the more difficult uh, you know, small tumors or um some of the more rare diseases, this could get upwards of 30 to even 45 close to 50 percent discordance, which means you might as well be flipping a coin.

Wow.

It's a very brittle process.

And you know, pathologists they they look at hundreds of slides a day and they only really get a few minutes each.

So looking through a microscope, when you realize you could have about a quarter million cells on a given slide, it's like trying to find all the blue cars in Boston from a you know from a satellite view.

That's that's the parallel that we like to make.

So what we're doing is we're offering a GPS to pathologists, we're showing them where to look at the slide, we're giving them some quantitative analysis on the slide that the computer does.

We're not replacing the pathologists, but we're trying to augment their ability to effect a diagnosis and to properly treat the patient.

Right now, though, um, so we're a pretty young company, been around for like three years officially.

I mean, the first year was like two guys in a basement, of course, as most good startup stories go.

Um, and as most Boston startup stories go, one founder was from Harvard Medical School or Harvard, one was from MIT.

That's just the way it works, right?

Um, but uh so right now we're only effectively being used in pharmacology research, um, but we are building out, and this is really exciting for me because I'm on this team, and just because it's a really cool first step for this company and a great opportunity in the tech space, we are building out a medical device, so really impacting the lives of patients everywhere.

And it's interesting that you guys from the get-go, you're trying to enhance the pathologist, you're not trying to re replace them.

So an analytical tool should surface information to an analyst rather than just output a decision that we just take for granted as being true.

Is it a similar thing there or is it the thought more that they can totally replace radiologists?

Okay.

Um in fact, like, so this is my first job in the health tech space.

Yeah.

And we don't expect anyone coming in as an engineer, especially, or any other role that's not directly related to the biology or pathology, to know these things, but they've been doing a really phenomenal job of upskilling all the employees here and kind of teaching us about the different concepts of the pathol pathology.

I'm still like a baby brain pathologist, you know?

Yeah.

But uh, but

But I have been hearing um from people like who are in the radiology space that they're equally as excited, and that's that's something that I think is really worth looking into.

Very cool.

Why did Path AI choose Django?

Was it was it always always Django from the beginning?

Like what what did you know about that journey?

So the um first uh stage of the pathology or sorry, the path AI product was more of a service-based uh business.

So it wasn't really so much a product, so much as a means to um help our partners conduct this research.

So it was very a la carte, very much like, oh, you need this feature?

Cool, let me go throw that into the code base real quick, close the contract, make the money.

Um so he uh, in my opinion, correctly, identified a move to Python as being the ideal solution for some of the engineering issues we'd had.

So one of the issues that you have whenever you have a Java platform is hiring engineers.

It is very hard to hire Java engineers.

I've done it in the past, and you run up against this problem where either they are not very experienced in Java, which is fine, but it can be a bit of a beast to wrap your head around if you've never worked with it.

Or they're really good at Java, which means they're happily employed.

And I just I feel like as an educator, it's it's I've taught people Java and I've taught people Python.

And for me, getting somebody to learn Java is very difficult because it feels very alien, very foreign, especially if you're used to something like Ruby or Python that feels more natural.

Like I could do it, but why would I do it?

Yeah.

Not everyone shares that point of view, but you really just the just the print statement.

I think it's something like 12 lines in Java versus Yeah.

So it's seeing uh, you know, and there and there's value in learning, you know, just the structure and you know, the being um static typing and all that, but uh it's hard to hard to go to it when you know there's something like Python and then and actually I don't I don't know the play framework very well, but Django in particular is pretty nice to use.

Like it's not like terrible.

It works, it's worked for us.

So, you know, not to diss it at all, but I think that for where we want to be a year from now, as far as size, scale, um, and the types of problems we want to be solving, Python just makes more sense.

Um, you know, when I teach Python, one of the things I do is you know, I say, well, why are we learning Python today?

Because I'm really here to teach you how to code, but I really want to teach you Python.

And I pull up um, there's a website.

I'm not sure what the URL is, but it's um it has hello world in every language.

Yeah, no,

Yeah, we'll link to it in

the notes.

And then for fun, I show them brainfucker lol code or you know, all the fun ones, but uh yeah.

No, no, that's that site is a great way.

I mean, it's slightly unfair comparison, but there's some truth to it.

Yeah.

I mean, uh, you know, sure every tool has its use, but if your goal is to learn a language, starting with Java, it just feels unfair.

I mean, you know, because we've been on the podcast talking about new Django projects, but in the real world, often you are migrating, you know, from something else.

So when I had joined, um Pathai had just really it was just like a few, I think a few months into that transition.

Um so the first step of that transition for Pathai was to transition from MySQL to Postgres for various reasons.

So that had been completed, and then the first uh attempt at um spinning up a new Java or sorry, new Django application was made.

Now the goal was not necessarily to just port everything over to Django.

The goal, and I think this is the right way to work with legacy code, in my opinion, is to support a Java application.

Do not do any nouveau new development in Java, though.

Start all that new development in Django, and as things, you know, technical debt arises, new features that have to touch other areas of the code change, um, you start porting things over slowly.

Or like, you know, what I did was create a laundry list of these um, you know, API endpoints with the help of my coworkers that we can then pick the easy ones to port over.

And every time we hire a new dev, their first task is just create a crud endpoint in Django and sunset the Java endpoint.

And I assume that's Java uh Django Rest framework you're using.

So that so that first attempt was actually microservices.

We ran into this uh a few issues there though.

We didn't have a lot of engineers, we had like five or six engineers.

So every new microservice that spun up, we you know, was another microservice that someone had to own.

So we had people owning multiple services and it just got a little messy.

Also, we wanted to share code between the two.

Well, and can you just so what does it mean to spin up a microservice with Django?

So some you know, everyone's kind of building their own services in their own way.

Um so you know, we use Docker and uh to kind of create that virtual environment to set up our applications.

So we kind of had like um what we thought was a standardized Docker file, but we didn't realize that the services had kind of diverged pretty quickly.

Um so you know things were just not really consistent.

And we found that people wanting to contribute code to some sort of or sorry, share code across those two services, to two main services, because we had a lot of other smaller services.

Um, it just got a little arduous.

We realized we'd end up having all these repositories GitHub repositories with like core uh utilities that would have to be like pip installed, um, and it just didn't quite make sense.

You're you start you run the Django start project, got it, you get it set up in Docker, um, and then just kind of get going.

And how are you finding Docker with Django?

Because I find it's a little bit of a wild west still.

Okay, yeah, yeah.

I use yeah, we we should talk about that.

Um so uh this was actually my first real uh attempt at using Docker.

I've used it in the past, but not I say reels in like first scaled application with Docker and one where I've actually had to really get in there and edit like the Docker compose and everything.

Yeah.

I think with Django, um we've found a way that works, but there are definitely um occasional gotchas that you know we have to kind of think about.

I don't want to think about the infrastructure as more than I have to.

That's just the way that I am as a person.

Um, so for me, I find it a great source of comfort knowing that like we've vetted these Docker Compose commands.

We know that we're gonna be able to set up the environment the same way locally and on each other's computers and on prod and staging.

Yeah.

It just I don't know, it just gives me a sense of ease that I haven't had before.

I mean, that's a big one with pipm is when you where do you generate the lock file?

And we have had you know merge conflicts in a lock file, stink.

I mean, yeah, you I mean the problem, right, is you create the lock file locally, and sometimes if it's in the container, you you get conflicts.

I mean what I've what I've done is I've found if I do it within Docker and then through the um volumes it'll be the it'll be copied over, and then I spin down the container and then I rebuild it with the build flag to force rebuild.

That kind of works for me, but it's sort of it it doesn't matter which one you do as long as you're consistent, but you get some really nasty bugs with you know the lock file in particular.

Yeah, I

And but I think the fact that the files automatically sync but the database doesn't.

Yeah that that's a real um that takes a while to internalize.

So for local development, we have a um, and this is mainly used for so in like a self-contained environment, so we have some repos where everything is all in the same repo, and that's mainly for clinical purposes that it's just better to have even and I know it sounds kind of grody, but like having the front end and back end in the same repo.

Um, we've been able to make it work with Docker.

It's not desirable, but it's easier again for the the regulatory affairs process.

Um we've uh we so for that we'll have the database that just gets spun up as its own, you know, command.

It'll be like, you know, just we'll have the database image and then we'll just use the relies on keyword to make sure that that gets spun up.

But for other purposes, when we have multiple services that need to hit us the same database, yeah, we'll just have a separate um we have this repo called local dev docker, and what it is is it's just you spin it up, it has the database there, and we use a local internal network so all of our applications can talk to it.

The idea being like you shouldn't be using a local database to connect to a you know a container that's supposed to replicate what's happening on prod because your local database won't be the whole point is to keep everything consistent.

So I mean your mileage may vary on this, and also this is like my again, my first time really getting into this, but I think it's been it's been really cool to get to learn that.

And how do you uh I mean at Quizlet we had I think we took like a tenth of all the files so we had a version that we could use locally um as a whole separate episode we could do on that.

You've got right all those additional concerns.

We there is an open source data set, the TCGA data set, um, that people in this space can use.

And um that way we can have slide images and metadata about those slides locally, but we're not breaking any rules.

Yeah.

Wow, okay.

Roughly.

So you figure like if I've got like a phone with 64 gigs of memory, you get six images on your phone, and that's it.

Yeah.

Massive data, but like not so when I was at Wayfair, so I spent three and a half years working at Wayfair, and when I I talked about big data, it was just a lot of information, lots of rows.

I mean, I was working with clickstream data on one of the world's biggest e-commerce websites.

So like that was like run a query, even though it's on Vertica, you still gotta go walk to Starbucks and then come back and you get your results.

Right.

Yeah, I'm guilty.

Um, but yeah, so um the data that we have, it's not massive quantities of data, it's just that it's a large amount of data.

And when you log into our platform, you've got things like asset management, project management, personnel management for users within your org, but mainly we have slide management.

And when you have slides, you click on a slide, you got to be able to view that slide, and we use a tile server, much like Google Maps, so you can zoom in and out to crazy like depths.

We have a deep zoom image tile server that we've built up, and each of those tiles can be a few megs if we're talking lossless here.

Yeah, is to

Um, but you know, there are, I think, I believe that there are more forward-thinking, you know, environments where currently that is, you know, slide scanners do exist.

They're out in the wild, digitizing a slide image is not unheard of.

Um so it is happening now.

Um, and I think, especially in the research area.

But again, you go to those, you know, you go to any local hospital, you go in the basement to the pharmacist.

Right, it's always in the basement.

Yeah, they're gonna be looking through microscopes.

Well, because I know the radiology world just a little bit through some friends, really.

And I know in their case, they have like ten thousand dollar screens because it needs to be super sharp.

And I guess I would assume it's the same thing or it will be.

I mean, because if you have these gigabyte size images, you hope you have a a nice screen to

So that's what

So now something else you and I have talked about.

So you we both have backgrounds teaching uh and hiring actually is hiring Django developers, right?

Because there's an industry-wide problem of no one wants to hire junior developers.

Uh and you have some thoughts on this, man.

Oh, yeah, because you're because you guys are actively you're hiring and interviewing a lot of people right now, right?

We are so we're not doing the like hyper growth thing.

Hyper growth is just like it it sounds gross and therefore it is.

Um so we are scaling up though.

We're high so right now we're at 58 employees.

By the end of the year, we want to be at 100 employees.

I want to say like maybe roughly 20% or 20 to 40% of that is engineering.

When I say engineering, sorry, I'm thinking more like product engineering, but ML is obviously our product as well.

So we have ML engineering, we have um, you know, people who work in regulatory affairs, we've got IT, um, we've got uh, you know, various HR-related roles, and um we have a pathologist, we'll probably be adding more to that team, hopefully.

So um that's like machine vision, um, that's like PhDs.

That's that's a really heady stuff that like my background as a quote unquote data scientist, whereas working in pandas and doing time series analysis is meaningless.

But on the website, anyways, so what number did you say for

And that's not even counting like co-op and or interns.

And even in Boston, which has a good engineering culture, it's it's hard.

It's hard.

It's very hard.

We are a very atypical company.

Yeah.

Um, so I think when I hear the word junior, it's like, why what does that word even mean?

I don't I don't really like the word.

Like the the idea is that we're trying to hire people with a high upside, with high potential.

This is a long play.

We're not gonna churn and burn our customers, we're not gonna churn and burn our employees either.

So I don't want to hire an engineer, burn them out in six to twelve months, and then get another one.

That's not the goal.

We want to hire people who are gonna be a part of this company for the long haul.

They're gonna learn a lot and they're going to grow a lot within what we're doing.

So we're not looking for Django engineers.

Granted, if we get a Django engineer, really exciting.

Because there's not a lot of them, right?

Like there's not a lot of people who dedicate themselves to Django.

I I often have this conversation with people.

As big as Django is, I I feel like it's not sometimes it feels like a very small world.

Yeah.

I guess there's what edX here in Boston.

There's they're sort of mid-level.

I think from my experience that Flask tends to be the more popular web framework in these types of companies.

And that's, you know, I built dozens of web frameworks in Flask working at companies like Wayfair and Solaria.

And it just it's

Yeah.

And Django has its own opinions.

Oh, that's an yeah.

Or at least that's not true.

I don't think that they should have less opinions.

I want engineers to have opinions, but I want them to be loosely held.

Django's opinions are not loosely held.

No.

And we butted up, so we had uh a big misstep that I think we made, which was let me rephrase that as a big learning opportunity that we had uh early on was um splitting up our date our Postgres database into two separate schemas, not using the public schema.

Oh which Django doesn't support because Django that's that's a Postgres specific concept.

And Django is meant to be, while it is, you know, obviously Postgres is the first class, you know, citizen of Django, it's meant to be database agnostic.

Yeah.

So I myself and another platform engineer, we sat in a room for two, three days straight.

It was a it was an interesting three days trying to hack Python into being okay with our setup.

And we got it so that it would work in prod, it was fine.

But being able to spin up a test database with multiple schemas, it just we had we could do it.

It's just the lengths at which we had to go felt gross.

That's in yeah, that makes more sense with Flask.

I mean, because yeah, once you're off, it's really hard to get back on.

Yeah, um but as you say, I mean, I'm biased towards there's something nice about guardrails.

I I agree.

Yeah.

And if Django doesn't fully fit it, you might be tempted to

Like at the end of the day, what my team is building is not revolutionary in that many ways.

Like the machine learning team, they're building state-of-the-art, cutting-edge technology that is going to take us, us being the human race, into a really interesting time where we can actually have more effective diagnoses.

And this is a problem that I myself, as a consumer, you know, have seen my loved ones sit across from doctors and get a diagnosis that the doctor was not confident in.

Yeah.

So that's amazing.

But all we're doing is taking data and moving it back and forth.

Like we're showing slides to users, we're taking their, you know, annotations and comments and storing them in our database and displaying them.

We're not really, again, with scale, we're not trying to build something that's a highly available web service that knows everything about every user and uses bid stream data and does this.

It's not marketing tech, it's not right, you know, it's not high-speed transactions for like, you know, trading and yeah yeah so um I think Django works great for us.

Um, I've again I built a lot of tools in Flask.

I love Flask.

I teach Flask often to uh, you know, people who want to learn how to build their first API because you can do it in a matter of minutes.

Um I remember I taught a 10 week long class at General Assembly on Python web development, and about halfway through is when we actually focus on Flask.

So we, I mean, these are this is meant to be people who have never coded before so the first like five weeks are like how what is Python?

Yeah what is Python what's a print statement you know what is this weird terminal thing you're using yeah it's weird uh and um when we hit Flask everyone's like all right buckle up and I'm like okay we do this we do this we do this and we have an API and they're like oh oh

Oh yeah okay um so as when I interviewed at Solari we actually did practical interviews only where you had to build something so as a back end dev I had to build a chat bot in two hours uh and I did it using Flask and WebSock.

So um I remember when I did this in Django because my boss at the time was a really big Django fan and um I remember creating the models I remember creating the serializers and then saying all right so now what?

How do I get routes?

And he's like or no and then I create the views of course and I say okay now how do I get the routes he's like no no you're done I was like what do you mean?

And he said he's like just just run it and hit this endpoint I was like but I didn't define that the get or the post of the what?

It was it was mind blowing to me as a as a Flask developer.

I think a lot of times you need to do something a little bit more and you can but certainly to just like get up and going it's like oh yeah it's everything I it's like they read my mind.

So for example to create um you know projects in our database for our partners you have to create you know five or six or seven different models on a single API call.

And originally it was being done with like six or seven API calls because it was all RESTful.

It was all transitioned

ig blob of JSON and you know override the serializer class to create all the different models that we need or whatever.

So kind of just like showing around that like we have these guide rails but we can also be creative.

Well so let let's uh uh on the hiring front so you mentioned how does someone get hired with Django?

What is a profile of say someone coming out of college or coming out of a boot camp?

What you know should they have side projects should they be better stronger in Python than Django?

Like what what like what's some advice so that when they walk into the interview you can say oh this is a person with upside?

Which sounds backwards right um so sometimes I will give like an algorithms question um that is like everyone can get at least to the naive solution almost everyone can get to a better solution and most people can make it to the ideal solution.

And the goal is I don't care about your code.

I hand you the marker and I literally say to them I'm here to judge your communication.

I want to know what you're thinking about.

I want to know how, you know what what your considerations are and then simply based on whether or not they actually follow through because sometimes I'll say okay cool great thanks for letting me know and then they just pick up the marker and start coding and they don't say a word.

And I'm like I get you're nervous though you know um and one of the things that I like to do is even if I always like to point out something that's wrong even if it's not wrong.

I'll be like I don't know if that'll work the way you think it does does it

Because that's the thing is like at the end of the day the coworkers that you want to work with are the ones who can separate themselves and their ego from the code and the work being done.

That's the important thing.

So that's one way that I judge that another thing that we do at Path AI that I think is really unique every single person that works here has given a presentation.

I think maybe except for like the first three or four employees.

So part of your interview is you give a half hour presentation the first five to ten minutes of that is introducing yourself and most importantly telling us why you want to interview at Path AI why you want to work here.

Right.

That's so important in startups oh yeah when I was hiring at Quizlet you know we found it's hard to sell someone on the idea of startups if they're you know thinking about Google and startups that's sort of a hard thing to win.

Oh I think you know you just have to sell against them.

You don't have to worry about you know a big company or something.

Which is fine, but like if you want to be at Google you're not gonna have fun here.

Yeah.

So it was a a good pre-screen to say why don't you figure that out on your own and then once you're sure about startups then I can tell you why this is the one for you.

Right.

Give them something to grow from if they're not the ideal candidate already.

Like they may be trying to convince themselves of something but totally you know there are just certain personality types that are better suited to bigger or smaller companies.

Yeah.

So again everyone in the company gives for every candidate for every candidate.

Now not everyone shows up now we got 58 people here and I think you know some of those are remote so maybe you'll have like 40 to 50 people in the office at any given day and maybe like you know 10 to 20 will show up especially based on the role.

So for example our front end our front desk associate give it gave a presentation and I think a lot of people showed up to that because that's someone who you know affects everyone's gonna interact.

Yeah absolutely whereas like you know engineers will get some front end engineers some back end engineers some um you know we'll usually get some PMs and designers in there as well um and maybe even like IT or anyone really that's interested sometimes you know regulatory comes in because why not right?

so this is the first step of your on-site so for engineers we do have a on site okay yeah so we have a we have a phone call with a recruiter we have a hacker rank and then you come on site the first thing you do is you give this 30-minute presentation and like I said the beginning of the you tell us about yourself you tell us why you want to be here and um you know a little bit about your background but then the rest of the presentation is about a particularly thorny problem that you have solved in the past whatever that might mean.

Um I actually got to present on that and I think that was a really cool project where we were trying to um we had essentially pickle files uh that held weights for a given recommendation algorithm and we wanted to retrain that every day so that meant we needed to swap out that pickle file without any downtime which was like actually an interesting problem.

Yeah, yeah.

And I mean we were serving it up from a Samba share so that was Yeah yeah that was fun.

Um but so you know you get to present on this problem and and again it's about communication.

It's not always about okay is this the hardest problem on earth granted obviously choosing a good problem is part of the interview really um is like your decision making process.

But um it's really about how do you like tell us about the problem, set it up so that we know what what the issue is, explain it to your audience properly.

Because we're everyone at this company is hands-on, so we're all moderately technical.

But if you have a you know a UX designer in there, you don't want to start throwing around uh you know a bunch of hexadecimal values and not explain why you're doing so.

Um so I think you know one of the things that I took to heart after presenting my presentation was um one of the designers said to me, you know, for back end presentations, usually I understand 30 to 40%.

You were able to explain this in a way that I understood like 85-90% of what you were talking about.

And when she told me that I was like okay that probably means I did well.

And that's really Well

So you have a little bit of a

Yeah no totally like and that's I mean but you know that's just the way it is really I mean having an advantage of something no I am a public speaker and I know that for most engineers that's not their desired

Once you hit a base aptitude it's really attitude.

I mean the when I think of the people who haven't worked out in companies I've been in it's almost always attitude it's not aptitude.

And often they have a high level of aptitude which has gotten them to the point where they can get away with an attitude for a little bit but you know if no one wants to work with the brilliant jerk.

And and I usually again so communication is massive but really the most important thing that I look for especially in less experienced candidates is coachability.

So can I teach you something?

Can anyone teach you something?

Can you teach yourself you know independence like the ability to sit down for a few hours try to work through a really difficult issue you know look through the documentation look through uh stack overflow and then know when you have to say all right I need help I'm gonna go and ask somebody for help yeah that's important to me massively

And I think it's great that we get to use Python doing this.

Before I joined Path AI I was going through like a severe identity crisis as a developer.

So much so that I actually was looking through um culinary school programs to be like I don't want to write code anymore.

Well you were probably

And a lot of times it becomes doing things like mentoring or other things to kind of keep you interested yeah in coding.

I think it's pretty a lot of disciplines especially coding yeah that's I think that's not uncommon.

So no there's there's no stupid questions.

There's only stupid people and those are people who don't ask questions.

Right.

And you know so I think like given that and having the teaching you know was something that I was passionate about and I wanted to keep doing that even though if I didn't want to keep coding but you know I I took a I took a a solo trip um spent a week out in like Europe just because I was lucky enough to do that.

I was between jobs and I I wanted to just kind of get my head straight and figure out what I want to do in my life and I came back and there were just two things that stuck in my mind which was number one I want to be writing web services in Python because I'd gone back to Java for a brief period of time.

It was like nope nope nope

But you know I also knew that I wanted to be in health technology because at the end of the day I've worked 70 hour weeks week after week after week building something that I didn't feel was a net positive to myself or the world.

And if I have any opportunity of doing that, I feel like it's going to be in this space and I'm about six months in and I still pinch myself every day because I get to work at this company with insanely smart, insanely passionate people building really cool technology and also doing it in like a less stressful environment which is like I don't know I I'm really lucky to be a part of Path AI and I'm I'm really glad that um this exists and that as time goes on more and more companies like this are going to be cropping up and we're actually going to be living better lives through technology.

Yeah.

This was great