Transcript: PathAI - Robby Grodin

Hello, and welcome to another episode of Django Chat. I'm Will Vincent. This week,

I'm joined by Robbie Grodin of Path.ai to talk about how they're using Django at scale. Hi,

Robbie. Hey, thanks for having me on. So let's talk about your background,

how you got into programming. Why don't we start there?

Sure, that sounds great. So, you know, 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. So different background than you're typically, you know, going to hear in these

types of cases. But while I was working with those tools, and also I got a really cool part-time job

at a company nearby called Cakewalk that makes music technology 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 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 another major and i just kind of took off from there

was immediately getting involved in projects like the java music specification language adding xml

parsers to that and started working i did a co-op the northeastern has a great co-op system i got to

work at blackberry for six months and um you know back was this back when blackberry was a real

thing or they started the decline this was actually like so this is in 2010 when they were

rim 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 layouts happened right and right because the

iphone came out in what 2007 i think yeah so he is finally and was this up in canada right no

actually um so they have a or had i don't know if they still have it um a satellite office in

andover it's about like 30 40 people so it was andover mass yeah andover mass so i was um on

part of the core mms sms team uh which is just located there it's a random team to be located

yeah very interesting to work at a company on at that stage though yeah it was it was interesting

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 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.

So I want to focus as much as we can on, um, you know,

path AI where you are now and how using Django,

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

I think box as well.

Yeah. So, um, after I graduated, I moved out to San Francisco.

I went to a music tech startup that literally a month after I got there

folded, 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, I don't last long there.

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

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

And in what languages and frameworks were you using?

Yeah, so it was PHP, you know, the dirty PHP.

And it was great, though.

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

I was a code reliability engineer on their 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?

Well, and that's great because it's hard to get that experience unless you are already

at scale.

Exactly.

And that's what we're going to 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.

It's hard to see around the corner if you've never been there.

Right.

So we're recording this here in Boston.

And 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?

That's actually a very nuanced question.

You know, I'll be honest, and the culture out there, professional culture is really not for everyone. So it really just was not for me. 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. It just, it didn't, I don't know, it's just something about the environment. It was a little bit too much, too much tech all the time.

Yeah, that's a very East Coast attitude, but I agree with it. 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.

It is. 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, every cafe is, you know, okay, good.

Can't escape it.

so now so path ai so you've you've been here what a year now no um six months yeah closer to six

months yeah and then what's the quick pitch for listeners what is what is path ai so path ai's

goal is to be the world's computational pathologist so we look at pathology as the ground truth in

medicine right um can you explain what pathology is absolutely 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

to you know discuss or 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 like what what kind of levels like um for a so discordance amongst pathologists

for some of the more common uh diagnoses you're looking at like a six percent discordance rate

but now if you're talking about some of the more difficult uh you know small tumors or 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 satellite view. That's a 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 pathologist, but we're trying to augment their ability to

affect a diagnosis and to properly treat the patient. Right now though, 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. 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? But so right now, we're only effectively being used in pharmacology

research. 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 wow and it's interesting that you guys from the get-go you're trying to enhance

the pathologist you're not trying to replace them i mean that's my my personal philosophy on

technology is that um good technology should always augment a human not 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 and is that the same and because i think radiology is the other

medical space where there's a lot of excitement around using yeah computers is it a similar thing

there or is it the thought more that they can totally replace radiologists i wish i could

actually give you a more informed opinion but um i actually don't really know much about radiology

okay 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 pathology.

I'm still like a baby brain pathologist, you know, but I'm sure osmosis and you're working

with it every day. So totally, but I have been hearing 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. So you said you joined about six months ago. Why did Path AI choose

Django? Was it always Django from the beginning? Like what, what do you know about that journey?

Yeah, so originally, the application was built in Java using the Play framework.

So the first stage of the Path AI product was more of a service-based business.

So it wasn't really so much a product, so much as a means to 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.

What's a way to fund it, I guess, starting out is to be, yeah.

So we hired a VP of product design and engineering,

Jackson Wilkinson from care.com.

And he came over with a wealth of experience

in a lot of things, including building Django applications.

So he, 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.

Yeah. There's less of that middle ground.

Yeah, precisely. 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.

Yeah, I mean, for me, I started with Python and JavaScript, and I only, several years

in, looked at Java, and I did a couple undergrad courses, and it was just, you know, like walking

to the fridge on my hands.

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

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

it's something like 12 lines in Java versus, so it's seeing, you know, and there's value

in learning, you know, just the structure and, you know, just being static typing and

all that but uh yeah hard to go to it when you know there's something like python and then and

actually i don't know the play framework very well but django in particular is pretty nice to use

yeah no i i mean the play framework's not bad i would say 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

Python just makes more sense.

When I teach Python, one of the things I do is 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.

there's a website i'm not sure what the url is but it's um it has hello world in every language

yeah now i yeah it's like a hundred different languages yeah we'll link to it in the notes

yeah so i always show them here's java 20 lines here's python one line and then for fun i show

them brain fuck or lol code or you know all the fun ones but uh yeah yeah yeah no no that that

is a great way i mean it's slightly unfair comparison but there's some truth to it

yeah um for a beginner at least i mean you know sure every tool has its use but if your goal is

to learn a language starting with java it just feels unfair so then and i know this is before

your time but do you have a sense of what that transition was like 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 yeah no actually so i joined at um a really exciting time

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

my sequel 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 thing 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 co-workers 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 nice and i assume that's java uh django rest framework you're using

yeah so we use drf so that so that first attempt was actually microservices we ran into this

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 very between right what and can you just so what does it mean to spin up a

microservice with django so you know we so that was kind of one of the issues is we didn't really

fully define that right 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

realized that the services had kind of diverged pretty quickly uh 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 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 reposit

github repositories with like core uh utilities that would have to be like pip installed um and

it just didn't quite make sense so is each one like a django like a self-defined django project

where you start okay everything yeah 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 is um just not to get too off track

but i'm working a lot with docker and my new book and how are you finding docker with django because

i find it's a little bit of a wild west still yeah so this was actually um and using pippi's

pip or sorry we use um pipenv pipenv okay yeah yeah i use yeah we should talk about that yeah

definitely um so this was actually my first real uh attempt at using docker i've used it in the

past but not i say real as 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 yeah

you know we have to kind of think about versus like pip yeah versus just like using pip but i

think um you know given that we have like a front-end team that you know sometimes they can

hit staging but sometimes they can't um just because our environments are still in their

infancy um being able to quickly spin up a docker container on a front-end devs uh computer and not

having them worry about what's inside of it is actually a huge benefit yeah well and in a team

setting too to you know to be on the same image yeah is yeah i think it's good because you know

as somebody so i'm i'm an application engineer 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 composed commands we know that we're

going to 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 and i mean i found the main you know the the challenge with docker is you want to kind

of just use it and you know someone gives you a recipe and it works until it doesn't and then you

have to really learn yeah docker and you know things like um containers are ephemeral you know

rebuilding images i mean that's a big one with pip env is when you where do you generate the

lock file yeah so we generate locally and check in the lock file and we have had you know merge

conflicts in a lock file stink yeah there's i mean there's two ways to do it 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 uh 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 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 oh yeah we um i at least i personally

but most i think most devs here do everything inside of the docker container yeah i try to do

everything i can inside of it and but i think the fact that the files automatically sync but

the database doesn't yeah that's a real um that takes a while to internalize well we also put

our databases into a docker container 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 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 gets spun up but for other purposes when we have

multiple services that need to hit 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 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 yeah yeah yeah yeah that's yeah i mean your mileage may vary on this and

also this is like again my first time really getting into this but i think it's been it's

been really cool to get to learn that yeah i mean when you work on stuff at scale you realize things

like a production database is massive 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 there's a whole

separate episode we could do on that yeah well for us i mean there's also considerations about

data because the data that we have on prod cannot live on our laptops right you've got right all

those additional concerns but in our in this space because you know this isn't new like health tech

is i think this is a really exciting time for health tech because a lot of other people have

made a lot of strides we there is an open source data set the tcga data set that people in this

space can use and that way we can have slide images and metadata about those slides locally

but we're not breaking any rules oh that's yeah i see that solves a lot of problems it does it's

very helpful um so something that we've talked about previously is that you know many django

applications are you've got a lot of users a little bit of data but in your case you have

a small number of users and like can you talk about the sizes of data you're dealing with yeah

an image of a slide could be anywhere from two gigabytes to 20 gigabytes wow okay so but two

gigabytes on the small size two gigabytes on small let's say let's call it 10 gigabytes right

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 got

to go walk to starbucks and then come back and get your results right or it's like the modern

my code is compiling exactly like my query is completing or like you come back and you've got

a few messages from one of the DBAs like, dude, I hate you. I killed your query. Yeah, I'm guilty.

But yeah, so 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 and so is a modern pathologist just looking at a computer

screen then um that's our goal yeah is to not yet but maybe soon um so now and this is also again

i'm coming up against the limits of my customer knowledge 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 farm.

It's always in the basement. Yeah. Sorry. They're, um, they're pathology lab. Yeah. They're going to

be looking through microscopes. Yeah. Well, cause I know the radiology world just a little bit

through some friends, really.

And I know in their case, they have $10,000 screens

because it needs to be super sharp.

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

Because if you have these gigabyte-sized images,

you hope you have a nice screen to...

You know, you'd think so.

Or is it more about all the levels that you can go through?

Yeah, it's really about being able to zoom in

to a super high amount of...

Just really getting in there and seeing it at a high fidelity.

Got it.

So now something else you and I have talked about,

so we both have backgrounds teaching and hiring, actually,

is hiring Django developers.

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

And you have some thoughts on this matter.

Oh, yeah.

Because you guys are actively hiring and interviewing a lot of people right now, right?

Absolutely, yeah.

So we're not doing the hyper-growth thing.

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

So we are scaling up, though.

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 maybe roughly 20% or 20% to 40% of that is engineering.

And what's the other percent?

So we have ML engineers as well.

When I say engineering, sorry, I'm thinking more like product engineering.

ML is obviously our product as well.

So we have ML engineering.

We have, you know, people who work in regulatory affairs.

We've got IT.

We've got, you know, various HR related roles.

And we have a pathologist.

We'll probably be adding more to that team, hopefully.

And so the machine learning, is that like PhDs or can you come in and work on that at a college?

Yeah, so that's PhDs.

So that's like machine vision.

That's like PhDs.

That's the really heady stuff that like my background as a quote unquote data scientist

where I was working in pandas and doing time series analysis is meaningless.

Okay.

But on the website anyways.

So what number did you say for?

So I think we currently have.

Well, how many are you trying to hire?

Oh, we have.

Because I'm curious, like just to walk through, like what is the process of hiring, you know,

is it 20, 30 people?

yeah we have about like yeah for the rest of the year we want to hire about 15 to 20 people i think

for engineering and that's not even counting like co-op and or interns right and even in boston which

has a good engineering culture it's it's hard it's very hard um it's also very hard when you're

a young company that um knows what it wants but is not we're not typical 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

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

play. This is again, not hyper growth. We're not going to churn and burn our customers. We're not

going to churn and burn our employees either. So I don't want to hire an engineer, burn them out in

six to 12 months and then get another one. That's not the goal. We want to hire people who are going

to be a part of this company for the long haul. They're going to 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 it doesn't feel like there is 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 but i mean you can with the exceptions of like you know pinterest and um i

think instagram's on django as well yeah um well yeah you don't have a lot of huge django apps out

there like massive scale django apps discus discus i guess there's what edX here in boston there's

they're sort of mid-level yeah so there's they're out there but it's not like a stone throw can hit

five companies using django 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 is that more

is that more because it's just easier to do something small in flask or microservices or

what do you think that is i think it's partially that but i think you know the fact of the matter

is when you work at a large company that is scaling you have a lot of opinions yeah and

django has its own opinions oh that's it yeah and one of the reasons that i tend to prefer hiring

less experienced you know engineers is because they have less opinions 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 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 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 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 yeah and i i see a lot of

companies have this issue where there's you know yeah django isn't quite what they want and then

they at some point they customize it and then they're kind of off the train of updates and it's

it's like, why are you using Django? Yeah, that's, yeah, that makes more sense with flask. I mean,

because yeah, once you're off, it's really hard to get back on. But as you say, I mean, I'm biased

towards there's something nice about guardrails. I agree. I mean, look, I've, I've done some low

level flask hacking. And it's fun in the way that driving down the highway at 120 miles an hour is

fun. But at the end of the day, it's not sustainable. Yeah. Well, it's Yeah, this isn't a,

know attacking flask no i love flask but it's it's good to have these use cases and talk about

you know you know maybe some of the reasons why django isn't at ascom at huge companies just

because you have as you said lots of opinions lots of you things you need to do and if django

doesn't fully fit it you might be tempted to but for us like we have a again we have a very simple

product that we're building 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 the 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 yeah yeah so um i think

django works great for us um i've again i've 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 it is very magical it is and and django is the same thing though i remember

the first api i built in django was a um an api that was meant to be used for an interview case

where if for front-end developers we build the api and they would build the front end oh yeah

okay so 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 and i did it using

flask and web sockets yeah 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 oh 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 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 what it was it was mind-blowing to me as a as a flask

developer yeah yeah there's a lot of what the view sets then you're using i'm sorry yeah view

sets yeah yeah create it it was all generics i mean this was like three models and like

nothing interesting at all no no function based anything that makes sense in an interview setting

it's true yeah i mean view sets are i think we'll we'll dive deep into carlton and i'll dive deep

into them at some point they're they're they're very powerful and they can work great if you have

standard needs um 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 yeah and i mean that's been a big thing here like just kind of through education you know

mentoring people who haven't used django before is like let's start with view sets and then

but like don't forget to also then follow up with the front end team because oftentimes the front

end team doesn't know that things can be better 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 apis calls because

it was all restful it was all transactional you guys do nested nested api calls and i mean at the

time like yes but they were kind of hacked they weren't exactly like formatted in a restful way

um and at the time we didn't though it was sorry sorry at the time that this project had started

no it was all transactional nothing nested and now we do properly restful nested calls but we

also on the back end are like all right we don't need it to all be transactional we can you know

take this one big 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 yeah we carlton and i recorded an episode which probably

come up before this talking about Django REST framework and GraphQL. And, you know, because

GraphQL is fantastic, but a lot of people maybe don't realize that you can do a lot with RESTful

API structure and minimize a lot of the overhead without needing to go to GraphQL.

And that's one of the cool things about working on a smaller team is that we sit right next to,

you know, all the engineers, and I can just shout over at my friend, buddy,

Hey, you want me to make this easier on you?

Yeah.

Well, so let's, on the hiring front.

So you mentioned, how does someone get hired with Django?

a profile of say someone coming out of college or coming out of a boot camp what you know should

they have side projects so they'd be better stronger in python than django like what like

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

upside so i think um so the first off i focus a lot on communication because i can hire an amazing

developer who can build the world's greatest application but if he can't communicate with

anyone else sitting around him then who cares and how do you evaluate that and how i evaluate that

is i give them painfully easy interview questions 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 they're like 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 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 don't know if that'll work the

way you think it does does it just to force them to but also to frustrate them because that's the

thing is like at the end of the day the co-workers 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 um 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 pathai why you want to work here right that's so important

in startups oh yeah especially for us 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 if they've narrowed it you know i think a lot of times people think they should they feel

bad about saying well i'm interviewing with your competitors when in fact if someone comes in and

says i'm interviewing at all these other medical startups or just all startups that's a great thing

oh because then you know you just have to sell against them you don't have to worry about

you know a big company or something yeah well i think to a point that you made when we were

chatting previously was that like if somebody comes in here and they're interviewing at google

amazon facebook it's like do you want to work at a startup or do you want to work at a massive

corporation which is fine but like if you want to be at google you're not going to have fun here

that's what we that's what i found at quizlet because i worked a lot on hiring the early team

and you know a lot of really smart kids not kids young adults coming out of top schools and

if they were considering one of the big companies nine times out of ten they were going to go there

yeah so it was 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 which

i think is you're doing you should always be trying to do a service to the person that's

interviewing right give them something to grow from if they're not the ideal candidate already

and sometimes if you're you know the interview seat you can tell what someone wants better than

they can 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

i mean i'm guilty of that myself as well in the past we all have been but i think that's a great

learning experience um you know for people yeah all right so tee up an easy algorithm question

is one of the things it's already made a presentation yes it's a small presentation

oh sorry yeah so the presentation we invite everyone in the company so again everyone in

the company 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 i'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 gave a

presentation i think a lot of people showed up to that because that's someone who you know affects

everyone's going to 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 and this is like a first round like is this like the

they pass the early rounds or this is like right off the bat so this is the first step of your

on-site so for engineers we do okay so if they make it to 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 this, you tell

us about yourself, you tell us why you want to be here. And, 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. So for me, you know, I alluded earlier to some low

level flask hacking that I did at Wayfair, I actually got to present on that. And I think

that was a really cool project, where we were trying to, we had essentially pickle files 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 uh i had to really get deep down into like the the server

hooks and everything to make that work and i mean we were serving it 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 yeah um it's 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

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 what you've already been teaching for a number of years too

right so you have a little bit of like a huge advantage 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 though i am

a public speaker and i know that for most engineers that's not their desire no i mean even a blog post

is is frightening for a lot of people but yeah but i i you know i'm i'm biased towards feeling

that communication is important and practice is important and ultimately you know i always think

attitude over aptitude 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 no no and i mean that's why we you know the db factor how much of a db are

you you know how much you know and like how how nice of a person are you is really meaningful 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 going to go and ask somebody for help yeah that's important to me massively i agree

Well, I think we're getting near our time. Is there any other points you wanted to get in on there on Path.ai, Django?

Yeah, so I mean, we're, we're scaling up in a massive way. And we're building something that is massively useful. And I think it's just really exciting to get to be a part of a team that has a problem that we all can actually wake up in the morning and be like, I know why I'm going to work today.

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 culinary school programs to be like, I don't

want to write code anymore.

Well, you were probably what, five something years in professionally?

Professionally, I was like six or seven years in.

I think that's not uncommon, though, that somewhere I've seen like five to seven years

in you to have this sort of like midlife crisis where you know it's you have the confidence to

know you can build anything but you realize how hard things are and it's a little bit less shiny

and there's a there's a little bit of a gut check on like okay 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 i think that's not uncommon well teaching

keeps me humble it reminds me like there's there are no stupid questions because anyone who asks

me a question is oh this this might be a stupid question i say six or seven years ago i had the

same question so no there's there's no stupid questions the there's only stupid people and

those are people who don't ask questions 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 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 is 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 that clarifies it yeah back to and i used to be a polyglot i thought of myself as but

now i'm pretty confident that i'm a pythonista as much as i hate that word um 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'm really lucky to be a part of Path.ai and I'm really glad that

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. Well, I think too, for developers who have some experience, who maybe want that extra

meaning and realize that they can be more productive at 40 whatever hours a week instead

of 80, I think that's a growing trend. I hope so. I think the time of being a developer and

being miserable being intertwined is is is slowly ending and i'm glad for that well thanks for so

much for coming on the show and uh we'll see everyone next time thanks for having me this is

great