This episode of Talk Python to Me is the second in a two-part series about getting your first Python job
in an attempt to bring a wide spectrum of thoughts on this discussion.
It's Getting Your First Python Job as a Python Developer Part 2.
This time, we hear from the experts on episode number 41, recorded December 10th, 2015.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter, where they're at Hired underscore HQ and Snap underscore CI.
That's right. ThoughtWorks and the SnapCI team have joined the show to keep the episodes coming.
Be sure to find them on Twitter and tell them thanks.
Welcome, everybody.
This is part two in our Getting Your First Job as a Python Developer.
I hope you've listened to episode 39, where we introduce the topic and we talk to new developers
who just got their first job in Python.
Now we're turning the tables and we're going to talk to the experts,
the people that do the evaluating and hiring and finally make the decision on who get these jobs.
We have experts from a bunch of great companies, including Netflix and PayPal.
The format will be the same as part one.
We have a bunch of guests who are experts and we're going to ask them questions and we'll kind of do a panel type discussion.
We'll hear from each of them in turn.
So let me introduce the panelists.
Last time I made a couple of book recommendations.
I'll just repeat them here really briefly because I think the way that people should look at their career and jobs is undergoing a pretty dramatic shift.
And on one hand, we all have to individually take responsibility for promoting ourselves and building our skills.
And the other, the landscape of employment is changing somewhat.
So if you want to explore these ideas, be sure to check out Soft Skills by John Sonmez and The End of Jobs by Taylor Pearson.
Okay, with that, let's get on to the questions.
So you can hear a lot of advice from our experts.
And I want to make sure that you know where they're coming from, the type of people that they expect to be working with when they give this advice.
So my first question to the group was, what kind of Python developers do you work with and do you interview?
Our first two panelists should sound familiar to you.
First up, we're going to hear from Roy Rappaport from Netflix.
He was the guest on show 16 when we talked about how Netflix is using Python to do amazing things.
And following Roy, we have Mahmoud Hashemi from PayPal.
He was on show 4 talking about Enterprise Python.
So let's hear from these guys.
Roy's up first.
What kind of developers do I get to hire and interview?
Typically, I work with and interview two kinds of Python people.
Devopsy people focusing on orchestration and operations in an AWS environment of a large ecosystem.
And people who can use Python to build solutions to some of the problems that arise in operating in these sort of large ecosystems.
So that's both ad hoc Python use to solve the sort of 5 to 10 minute sort of problem and architecting a Python based system to, for example, auto discover SSL certificates in a large distributed environment like Netflix's, for example, and alert us when some would expire.
Which was actually the first project that I got to be responsible for when I became part of the engineering organization here at Netflix.
Hi, my name is Mahmoud Hashemi.
I'm lead developer of Python infrastructure at PayPal.
And I'm also the presenter of Enterprise Software with Python coming soon from O'Reilly.
My code is at github.com forward slash M-A-H-M-O-U-D.
Dedicated listeners may recognize my voice from episode number four of Talk Python to Me.
And it's great to be back on the show.
Question number one.
What kind of Python devs do I work with and interview?
So I work with Python infrastructure engineers.
Now, software infrastructure is the foundation of all sorts of other software development, from web to backend to batch to automation and tools.
To do it well, you have to have personal experience developing in two or more of those categories.
For the past year or so, my team has been adjunct to the PayPal application security team.
And that's actually who I'm hiring for right now.
So a little plug.
If you have at least five years of industry experience and want to get into some ultra high performance Python security work, shoot me an email at M-A-H-M-O-U-D at PayPal.com.
All that said, one of my services on the Python infrastructure team is also performing phone and in-person interviews for PayPal teams looking to expand their Python talent through hiring.
So I hire for a lot of teams, in other words.
So just check out the PayPal careers page.
And if you see Python mentioned in the job description, then there's a good chance I'll be doing one of the interviews.
Okay.
Hi, Michael.
So quick intro to me and why I'm going to be answering the questions I'm answering.
Hi, my name is Lorena Messa.
I am a junior on the platform team at Sprouch Social here in Chicago.
I'm going to be addressing the questions that are geared towards the quote unquote expert or rather the person who's participating in doing interviews for candidates on our team.
So as a junior, I was I've recently been added into the shuffle for interviewing at Sprout.
And I think one of the things that's kind of interesting is that we'll come to talk about is what does it mean to use Python at Sprout and really who are the types of candidates we have come in.
I myself came into programming being a first I first started programming in grad school using R to data on structure my data and do what I needed to for my grad research.
And I then went on to explore it more on my own, did an immersion program.
And now I'm with my first software engineering position.
So the way we use Python at Sprout Social, we use Python in a few ways.
The biggest the biggest way we use Python is we use it for our API.
We have a Django API that really glues all the data together.
And we take all the data that that's been stored, that's been shaped into the formats that it needs to be from our Java services and is then repurposed into whatever format we need and return it to our web client.
So the predominant use for Python is going to be more in tune with web development.
We do have some backend services that are written in Python, but the bulk of that of our backend services are going to be Java.
So any heavy data lifting is going to be predominantly there.
That being said, we do have a lot of internal tooling that is written in Python.
So, you know, we obviously use Python to glue together some processes that need to be automated.
So be it tools that help developers make their lives easier.
If you're just exploring some data, you know, I think people opt to use Python as their first language just for scripting and getting things done or getting their toes wet, writing an initial prototype for something.
And then also we do have Python.
We do use Fab, which is for Python to do some operations work.
So the type of people that we, that I work with include web development, backend, backend service folks.
And then we do have an in-house data scientist.
Next up is Adelzan Kastamav.
Hello, Mike.
Thank you very much for your wonderful podcast and for letting me be a part of your cool project.
So the first question is, what kind of Python devs do you work with and interview?
So currently we are the biggest online travel agency in Kazakhstan.
And our system is completely risen in Python.
Consequently, it means that we are looking for web developers in Python.
But also because of the amount of data generated from our users is enormous, is huge.
We also should hire people who can work with this data, organize and make sense from these datasets.
Fortunately, Python is also the first class citizen in this area as well.
So we are looking for web developers and we are looking for people with a knowledge of statistics and with a working knowledge of Python.
How to connect statistics in Python and make something cool.
Now let's hear from Greg Langston from Connectria Hosting in St. Louis, Missouri.
At Connectria, we've engaged with many different types of developers.
We've engaged with small mom-and-pop style shops and also Fortune 500 companies.
Our customers often have development teams already built into their existing processes.
So with most of the UI built on their side, most of our work has been in developing back-end services, API integrations, and workflow automation.
That's because our customers typically are partnering with us to increase efficiencies in their existing deployment pipelines,
to introduce some new efficiencies in their DevOps continuous integration or deployment models.
That being said, we also have several projects mostly written in Flask or Pyramid that integrate with our inventory and monitoring systems.
With some UI components built into microservice architecture using Docker.
We often look for candidates who may have experience with infrastructure as code, cloud platform modules such as AWS.
This requires experience with Bodo, the AWS client package for Python, or some other cloud platform SDKs.
We often take a cloud infrastructure orchestration approach to our development, which involves understanding infrastructure components such as load balancers and databases.
So for us, having the ability to build and develop those backend services and APIs towards that orchestrational goal is absolutely critical.
And finally, let's hear from Sean Milochik.
For about six years, I hired web application developers for a startup that provides payment solutions for clinical trials.
We use a lot of Python and Django, use a lot of third-party APIs, and our work was directly customer-facing.
The second question I asked everybody was, what is the most important piece of experience that you look for in a candidate?
If I had to narrow down the most important piece of experience I'd look for, it'd be real production experience at some reasonable scale.
Not so much in terms of size, you know, in terms of number of machines or all of that, but more in terms of mindset and orientation.
I want to see a focus on building things well, automating where possible, and having a long-term view of the systems you put in place.
And I look for a time that you've applied productive laziness to solve a problem.
So, the most important fundamental skills I look for are closely related to experience, environmental fluidity, and personal learning ability.
Now, what do those mean?
So, as for environmental fluidity, well, specifically, PayPal uses a lot of Linux.
So, I look for candidates that can demonstrate familiarity at the console, interacting with the operating system.
While I don't usually give candidates complex, algorithmic questions on the spot during interviews,
I do log them into PayPal's test servers and have them do a little bit of basic debugging.
For the experienced people, you can almost feel them relaxing into a familiar environment.
For the inexperienced, the terminal can be an aptly named dark and scary place.
Either way, the command line is a foundational technology critical to enterprise work,
and I really feel like it's not going away anytime soon.
So, lack of command line comfort is a big yellow flag, especially when Linux is so widespread and easy to experiment with on your own.
The other characteristic I look for is learning ability.
The skills to read and research naturally, absorbing and arranging information automatically,
because I've been burned once or twice by talented people who were honestly just too lazy to read the docs,
or too intimidated to read the source code.
You don't have to do it in big gulps, but you do need to do it consistently.
So, I usually look at what candidates have done to learn lately,
like the sources they've been consulting and so forth.
So, for instance, I'll say, show me some source code you've written and what you learned during that process.
Or, tell me about a project that sounds much simpler than it actually was.
You know, I might ask, what sites taught you the web?
Or, have you seen any noteworthy source code lately?
Have you read any good books?
On the other hand, I watch out for Hacker News-y types.
My projects have topped HN several times in the last couple years, and some lurking is fine,
but I want someone ready to outgrow that consumption and commodification of the creative work that is software
that gets interleaved with the press releases on Hacker News.
Someone who's ready to dedicate time to actually create the sorts of things that others will upvote.
I think the most important piece of experience is how they approach problems and break it down
and turn something that may have seemed otherwise impossible or very difficult,
how they broke that down to smaller, more manageable pieces.
After all, coding is about problem solving, and we are building recipes to automate tasks,
to automate things, to make an ecosystem that can work in harmony.
So when a candidate comes in and they talk about problems that they've solved and how they went about doing it,
really I'm trying to see what was the original problem,
what were the ways they went about trying to solve the problem, what worked and what didn't,
and also, you know, where's the passion?
What really drives them?
I think it's really important to have people who are excited about what they do
and are okay to, they're okay with things failing because at the end of the day,
you're going to try things and it might not work,
but you need to have the ability to then sit down, reflect, understand what went wrong,
and move forward to iterate and try something else.
Demonstrate problem solving, I definitely think is the most important piece of experience.
I think there are two pieces, important pieces.
The first one is responsibility and the second one is maturity.
Why?
From my point of view and from my experience,
usually people who actually have never worked before,
for example, students,
they don't lack technical skills,
they lack social skills.
And social skills are crucial.
They lack of communicability.
They lack of responsibility, maturity.
Because majority of people think that programmers and programming in particular isn't antisocial.
And programmers are people who actually are staring at the screens all day long
and writing some magical code and doing something magical.
But I think that programming is a social skill as well.
Because in order to create something,
in order to create something valuable,
you have to communicate with many people.
You have to communicate with managers.
You have to communicate with your team members.
You should be a good team player.
You should communicate with customers.
Also, you should communicate with the end users of your products
in order to get feedback.
You should be responsible for everything.
You should write effectively.
You should express your thoughts concisely in a written form.
I think writing is also a very crucial skill for programmers.
I mean, not writing code, but writing articles,
express your thoughts and stuff like that.
And if a person is responsible and mature,
it is a great pleasure to work with him.
We particularly look for experiences where a developer has taken a task
and researched community packages that can be imported
in order to complete the objective faster than if they were to write vanilla code
in place of that.
The reality of today's code economy with open source technologies is that codes and packages
likely have already been written to assist in completing particular tasks.
And that means mostly the challenge becomes then kind of assembling those components together
with some of your own custom development to solve the particular problem.
I don't often encourage writing code without consulting existing packages.
We use packages such as requests and Flask, for instance, quite heavily.
It's just less necessary than when Python was first developed.
We also require that developers know how to set up a virtual environment, virtually in V, for instance,
in order to create isolation of their package needs,
which can then further be built onto continuous deployment practices.
From a code centric perspective, we look for things such as good practices around exception handling,
logging, security best practices in your code, those types of things.
Any code written must follow good standards around those types of things.
Unexpected data formats, bad JSON structures, all those types of things.
So those are critical to what we review.
The most important experience I always look for in a candidate is not knowledge with a particular piece of technology,
but curiosity and demonstrating that they are actually interested in programming.
Anything they have not done for school or work.
Someone that even if they didn't get a job as a programmer,
they would have to write code because they're compelled to do it.
It's just part of who they are.
This episode is brought to you by Hired.
Hired is a two-sided, curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front,
and you can view the offers to accept or reject them before you even talk to the company.
Typically, candidates receive five or more offers in just the first week,
and there are no obligations, ever.
Sounds pretty awesome, doesn't it?
Well, did I mention there's a signing bonus?
Everyone who accepts a job from Hired gets a $2,000 signing bonus,
and as Talk Python listeners, it gets way sweeter.
Use the link Hired.com slash Talk Python to me,
and Hired will double the signing bonus to $4,000.
Opportunity's knocking.
Visit Hired.com slash Talk Python to me and answer the call.
The third question I put to our panelists is really trying to dig into what you can bring
and what you can work on when you don't yet have your first job,
or at least your first job in Python.
So if I'm in school or I'm moving into programming,
but I don't yet have a developer job,
what can I work on to show that I have some reasonable experience?
Maybe something like an open source project.
Maybe you could create a little side project or a mobile phone app or a website
or even participate in some of these code competitions.
I'm thinking of things like Kaggle data science competitions and so on.
So let's hear what they have to say.
Roy's up first.
If someone is applying for their first job,
what can they present to show that they have the right skill set or education?
Well, first of all, we don't care that much about education necessarily.
We'll talk about that in a moment.
But it's also worth noting that it depends on your definition of what first job is.
Netflix is pretty public about not hiring people straight out of college.
Typically, we don't hire interns.
And so this may be something of a moot point.
But if you're talking about someone's first interaction with us,
we love to see open source contributions and side projects, obviously.
I think looking at mobile phone apps is an interesting example of what you might be passionate about,
which is interesting.
Even if the actual skills related to that are not particularly relevant to us,
we tend to think of skills as something you can pick up pretty easily anyway.
I haven't seen much by way of code competitions, so I don't know how relevant they would be.
What we tend to go for really is take-home exercises as part of the recruiting process,
which let people solve some sort of problem we've had run into in the comfort of their own home,
on their own equipment, using their own time.
That's actually worked really, really well for us.
When it comes to first jobs and concrete projects, I'll look at anything and everything.
With new developers, it's just so rare to get someone with anything interesting in their GitHub or Bitbucket account.
And so that's definitely my first stop.
Software is increasingly portfolio-driven these days,
and so I do get a bit discouraged when I see a developer that doesn't have a GitHub or a site or even a blog.
Because you can cram for an interview and you can exaggerate on the resume,
but you can't really fake a meaningful commit timeline going back a year or two.
Even if it's just some school projects,
I at least could see that you've tried and you have some basic Git skills.
Contributions to other projects tell a good story too.
You were probably using the project for something, being productive.
You took the time to understand how it worked.
You were able to communicate and lived up to someone else's standards.
That's stressful for a lot of people for sure,
but that's got a lot in common with enterprise development too.
Side projects and apps that run an environment similar to our own are very interesting.
Mobile phone apps?
Not as much.
Side note here,
code competitions and scores from Reddit,
Stack Overflow,
and Hacker News are okay,
but honestly those skills don't really apply that well internally at a big company.
In my experience, it can be sort of hit or miss.
This may make me kind of unpopular,
but some people who have high scores, high karma on those sites can tend to be a little bit impatient and unhelpful with people inside the company,
and not to mention the internal processes.
That said,
if you're someone who helps out with mentorship or gets on IRC and answers beginner questions, that could be great.
Definitely mention that sort of thing in your interview.
So when a candidate comes in, ways that they can try to showcase their skill set.
I mean, we have it in college.
We have different types of learning, be it formal or non.
But what I think I get most excited about is more side projects.
Maybe someone started on something that isn't within their day-to-day role,
and they got really excited about it.
And then they went out there and they wanted to learn more.
So does someone have a side project like they were curious perhaps about how they could take a problem that maybe perhaps all developers have,
which is, you know, writing good documentation.
You know, do they recognize a need that it's somewhat painful and or an afterthought to write documentation?
And then they're like, okay, how can I write a tool that will make this better?
And then they turn that into a side project.
Or maybe they're curious about machine learning and they've started taking a Coursera class and they're taking a project or a algorithm into their own and applying it to a project.
I think ways that we learn, you know, you are passionate about exploring and learning outside and creating your own projects,
that really demonstrates initiative and really demonstrates a curiosity that I think is fundamental for coding.
So side projects are really exciting to me.
And also show the creativity of a developer.
And then also open source contributions are pretty exciting as well.
Particularly if someone has used a tool a lot and they start recognizing the holes or problems.
Or even if they're saying, the way I learned how to use a project is I went through and started following bugs and started adding documentation to an open source project.
Adding documentation to a project might seem like a small and insignificant thing, but actually can be quite useful and important.
So really, you know, side projects, they may seem to be terribly overwhelming or large, but there's other ways you can go about doing it, finding a favorite tool and finding ways to contribute.
So I think those are two ways that people can demonstrate things that they've worked on.
Another thing that is definitely not required, but I am intrigued by, is seeing how people give back to the community at large.
For example, are they participating as men?
Are they doing a mentoring program?
Do they act as a mentor?
The Chicago Python user group has a mentoring program, which I've really not heard many user groups doing.
So it's exciting to see someone say they have a love for something and they're ready to give back, be it as a mentor or maybe even as a mentee, are they participating in one?
Giving talks at local user groups, giving talks at conferences.
I think all those things are very interesting as well because it's going to show how they'll create community within your work environment and how they'll be contributing to the procurement of knowledge in days to come.
It's important to have people who are looking to add to the conversation rather than just participating in the conversation as it exists.
I think that everything matters.
The more, the better.
Because from my point of view and my experience hiring developers in Kazakhstan, usually people who are applying for their first job don't have anything to present.
That's why it is very, very difficult to make right decision based on this.
It starts looks like a Russian roulette.
You start to rely on your intuition, which is not the good decision-making technique.
And I would say that it is better to make mistake and not hire a good person rather than hire a wrong person.
And that's why if a no previous job experience candidate shows his interest in terms of open source contributions, site projects, etc.
It is definitely a big plus for him.
And I would highly recommend to explore a wide range of open source projects.
It is not the only best way to explore other programming code, but also opportunity to share your code and get feedback from more experienced developers, which is very important in real projects, where the majority of your time you spend with working with other experienced developers and working with the legacy code.
So take a look at Django, take a look at Flask, requests, SQLAlchemy, and tons of excellent open source projects and start exploring and contributing to them.
Practical experience with the language is critical, but we do desire candidates to have some formal education in software development, typically one to two years.
That training can often establish good development habits, such as setting up good unit tests, exception handling, logging practices, and commenting standards.
We like when candidates can present examples of that practical experience with the language, sample code, snippets, those types of things.
We want to see what the packages they've imported, how they interact with those, and just to see what the forethought was for choosing those packages over other options, because there are many in the pip space.
We want to see how the developer thinks about their code just as much as the code itself.
We also require submission of unit tests as part of review in the process.
Test-driven development is a critical part of our current development workflow, and it greatly improves our ability to resolve bugs quickly and discover as many of those as possible earlier in the sprints.
Given that we support cloud platforms for our customers and those platforms are constantly evolving, we look for individuals who are capable of being flexible and dynamic as the languages and framework needs evolve.
The reality is that tomorrow we may need different skill sets for another language entirely.
So we look for individuals who love to learn and pick up new skills and are energetic and work well with others.
What I'm looking for in general is anything that they did for themselves for fun.
So, sure, code competitions, personal websites, little things they did like Project Euler type things.
Open source contributions are always good, especially if it's related to the types of things we're doing, or even if it's not, because anyone, even an entry-level person, could have fooled around with something that no one else on the team knows and can enhance the team.
Everyone can learn from everyone else.
This episode is brought to you by SnapCI, the only hosted cloud-based continuous integration and delivery solution that offers multi-stage pipelines as a built-in feature.
SnapCI is built to follow best practices like automated builds, testing before integration, and provides high visibility into who's doing what.
Just connect Snap to your GitHub repo and it automatically builds the first pipeline for you.
It's simple enough for those who are new to continuous integration, yet powerful enough to run dozens of parallel pipelines.
More reliable and frequent releases.
That's Snap.
For a free, no obligation, 30-day trial, just go to snap.ci slash talkpython.
This fourth question is really about trying to compare and contrast the value of long-term education like four-year college degrees with hands-on experience.
I hear from a lot of people that it's hard to get your first job out of college because people say you don't have any experience.
But at the same time, if you don't have a college degree, maybe that's a stumbling block.
So I ask everyone if they were presented with two candidates.
One who has a really solid computer science degree but not a lot of experience because they've still been in school.
And another with little formal education but a couple of years' experience working with the technology they're looking for.
Like maybe you're hiring for a Python web job and this person has experience working with Flask and SQLAlchemy, talking to MySQL, and it's all running through Nginx and load balancing, all that kind of stuff.
They've been doing that for two years, but they only graduated high school.
How would you balance these two candidates?
Well, you know, I'm never going to decline solid formal education, of course.
Solid formal education is great, and especially as you solve bigger and bigger problems, it can become more and more relevant.
Big O notation, for example, is maybe not that relevant to you as you try to figure out how to search for a given IP address in a file with a thousand lines.
But around the time that you try to generalize this to Netflix scale, you're probably really going to want to care about the difference between, say, ON and ON log N and cubed, for example.
That said, we really are interested in problem solvers, and really what we're talking about there is practical problem solvers.
And I'd rather see you having solved real-world problems rather than gotten good grades if I'm in the position of having to pick just one of these two options.
And again, since we don't look at people's first job necessarily, the educational background for us is not particularly relevant in our both recruiting process, but also in terms of deciding who we're going to give offers to.
I have people on my team who don't have degrees.
I have people on my team with PhDs, and I have no idea where the people with PhDs got their degrees from.
It's never been relevant.
Question number four, degrees.
So this is an interesting question.
Which one do I value more, or which one does the company value more?
Because management marketability really comes into it with large companies.
Of the three hires I truly consider my star hires, none of them had a CS degree.
One was electrical engineering, the other was math, and the final one was comparative literature.
The things they all had in common, though, was just a voracious reading habit and extensive hours spent in some Python or POSIX environment.
Computer science degrees aren't really necessary for the majority of enterprise work.
Like I said before, environmental fluidity and willingness to read docs are far more important.
A couple of CS classes will get you some useful vocabulary and teach you time complexity, though.
As for the concept of a degree in general, if you want to work at a big company, it's a lot easier to get in with a bachelor's.
You don't need much more than that.
The right two years of experience can go a long way in terms of skills development, but in terms of management marketability, no degree raises a lot of eyebrows in those cases.
So, in short, for enterprise software, my observation is that a computer science degree is about as good as a non-CS degree plus two years of experience,
which is about as good as no degree plus four to five years of experience at least.
Most professors and academic programs don't give you all that much pragmatic knowledge, even if it's pretty old stuff like Emacs and terminal usage.
Basically, everything is about how you approach your assignments in free time.
If you push beyond the requirements, you will learn much more.
So, if you're in school, take an operating systems class.
Take a networking class.
Maybe take a crypto class.
You'll learn almost as much running a shared server in your dorm.
Now, both of those are different types of knowledge, so consider doing both.
If you're not in school, Coursera and other options are far better than nothing, and I'd like to hear about those experiences in interviews.
So, for candidates that have computer science degrees and those who don't, I don't actually have a preference of one over the other.
I think that something that's unique or maybe interesting about Sprout, we are a startup.
We're about five years.
We're in our fifth year here in Chicago.
I think startups are interesting spaces because you get people with a broader background.
At least that's been my experience.
And when you have people who come from different backgrounds, you know, maybe someone who was both technical and was a lawyer.
Or maybe someone came from a PhD that wasn't in computer science and went into programming.
Or maybe someone who was a musician and came into that.
Speaking of which, these are all examples of people I know and work with that have these types of backgrounds.
These are some of the most exciting people to work with because their ways of breaking and approaching problems, they come from different vantage points.
So, definitely, I think having the ability to speak about fundamentals is somewhat non-negotiable.
You need to understand how to talk about the complexity of an algorithm and understand its performance.
So, big O is important.
You need to understand different types of data structures and what is applicable in an appropriate situation.
And I think for people who don't have formal education, these are the type of things that you can learn over time or you can take the initiative to learn on your own.
So, while a computer science degree is definitely a good indicator of someone's skill set, it's not the end all.
You're looking for a nice combination of things.
So, for people who don't have formal education, I think what's important is that they're continuing in their learning and how is it they're doing it.
Are they participating in online learning?
Are they in different user groups looking for mentors?
Are they reading textbooks at home?
I think all that's really important.
And really, for people who don't have the formal education, you can see people who are doing this when they get to the technical interview and they're breaking down problems.
And you get to see how they think and how they evaluate the code that they would intend to write or whatever the problem is they're trying to solve.
So, in a nutshell, both are great backgrounds.
But I think it's how you continue that learning for people who don't have formal education that's going to help compensate for some of the knowledge you're missing.
Yeah.
So, the answer is, it depends.
For example, a person with a solid computer science degree could also have a solid knowledge in a particular technology stack or domain and vice versa.
And definitely, I would prefer that person.
But the real world situation is a little bit harder than this.
And I think that currently formal education is not the number one priority in terms of making decision to hire a candidate or not.
But what really matters is the experience.
Experience person reduces costs for businesses.
Experience lowers entry barriers.
Experience also reduces the likelihood of technical debt which this person could introduce, thereby decreasing the productivity of other developers.
And nowadays, the gap between people who have a formal computer science education and those people who don't have is decreasing with the introduction of MOOCs.
What is MOOC?
MOOC is a massive open online course.
And platforms like Coursera, like Edex, like Udacity, MIT and so on, they provide tons of high quality courses free of charge.
And I think that we are living a very, very special life where education is becoming cheap and affordable for everybody with the access to the internet.
So, you can go there and start learning something new with thousands of students.
That's a great opportunity.
You can collaborate with them and you can help each other.
If I had to choose between someone with a solid degree and no experience, and someone with a couple years experience but no degree, that really wouldn't give me enough information because neither one of those things tells me how a person is going to be in my group.
If they're going to be a culture fit.
If they're going to continue to learn.
How much they really love what they do.
One question I always like to ask is, if we made you an offer and you had an identical offer from another company.
Same money, same everything.
Why would you choose us?
I want someone who appreciates the environment of a startup and the type of people they'd be working with.
The people that are interviewing them.
Who talk about themselves during the interview to give them an idea of what we're like.
And the main thing is a culture fit.
Even if they didn't know Python.
And beyond that, someone who really loves what they do, is willing to always learn, is always curious, is going to bring their ideas and things they discover out in the open source world into our company and make everyone better and make our product better.
That is what I'm looking for.
And the education and experience just don't matter.
This last question was an optional one.
I didn't want to put anybody on the spot.
So I said, answer it if you want.
Otherwise, just skip it.
And a couple of our panelists answered it.
And that question was, why did you hire the last person you hired?
And I ask this because it's great to talk in theory about comparing formal education versus experience versus side projects.
But actions often speak louder than words.
And in this case, I thought maybe we'd find something interesting.
Well, you know, that's actually kind of funny.
The last person I hired was someone who was interviewing for a manager position with us.
Actually, but we hired him for a position as an engineer.
Because as we looked at what he was really interested in doing, he was passionate about technical innovation and was very, very strong in that area.
He was interviewing for a manager position because he had been a manager before and was used to working in environments where the way you got to be technically innovative was to be a manager.
Because as an IC, individual contributor, all you got to do was implement the technical decisions of your management chain.
In our environment, it's actually exactly the opposite of that.
So the IC position was a great fit for us and was a great fit for him and his passion and what he was actually interested in doing.
And that's worked out really well for us and him so far.
So I gave my most recent thumbs up to a developer who knew Django and was willing to continue working with it.
But most importantly, he could start on site before the wreck closed.
You see, in large companies, empty seats have expiration dates.
And everyone is willing to gamble.
Because somebody is better than nobody.
And even if they're worse than nobody, then you still get a backfill when they leave or are pushed out.
But this developer seems to be working out.
And I only helped hire him for another team.
So let me talk about one other one.
The last engineer I hired onto my team was recruited over the course of two years.
I met him at PyCon 2012.
And we collaborated on a few open source projects.
And, you know, eventually the planets aligned and he was able to join my team.
Real recruiting can be a really long process, not the least of which is due to weird budgeting and bureaucracy.
So don't get frustrated if you're still waiting on an email reply from me.
And do network and meet people and go to conferences and play that long game.
One last piece of advice I usually give people as well is to, if you're really just looking for a job,
you want to get into the mix with the industry,
Just make sure that your LinkedIn profile exists and says that you are a software engineer.
And then just change your location to the Bay Area or Seattle or some other tech hub.
Actually, I hired a person just recently for about two or two and a half weeks ago.
This person is a young, smart guy without actually strong computer science formal education,
but with some little bit of working experience.
Previously, he only worked in one place as a web developer.
But the thing which makes him different from others is his passion for knowledge.
I was amazed by his habit of reading books on a regular basis.
He explores and learns different MOOCs.
We just recently took the MOOC from Coursera, which is called Learning How to Learn.
I highly recommend this course to listeners.
Take a look.
This course is very, very good.
Learning How to Learn.
And he's interested not only in computer-related subjects,
but, you know, other stuff like scientific, non-fiction, and so on.
And also, he reads tons of code from different open source projects
and making some contributions to them.
Because I think that because of technology is a rapidly growing area,
everybody should stay hungry and be curious.
Because we are lucky enough to be a part of something
which can change people's lives in a better way.
And the idea of creating something that can be used by millions of people is fascinating.
And people who are fascinated are willing to continuously improve themselves.
And I wish everybody to be fascinated and improve their life and themselves in a better way.
Thank you very much.
Rather than discuss why I hired any individual,
I'd rather talk about why I've hired my favorite people that I've hired.
And there are many recurring reasons.
And among them are they're interested in open source.
They're interested in the community that brings us the tools that we use every day.
They keep themselves up to date.
They follow key people on Twitter.
They're on mailing lists.
They go to conferences.
They follow blogs.
They're interested in doing things the right way.
They follow the community's best practices.
They use linters.
They pay attention to style because it doesn't matter to a certain extent.
If the code works, it matters that I have to be able to read it.
I have to be able to maintain it.
Maintainability is by far the number one most important thing in programming, in my opinion.
And someone who's not satisfied with meeting the requirements, someone who wants to make it better, they want to do it the right way.
And I don't mean an ivory tower, unattainable perfection that it has to be done exactly textbook perfectly.
Just it's done well enough that it's easy to maintain.
It's easy for other people to understand.
They're not taking egregious shortcuts.
They leave the code better than they found it.
And they're someone whose code review you want to do and someone you want to talk to at lunch about code and just generally hang out with.
Well, that's it for the questions.
I really learned a lot, and I think I got a better picture of what it takes to be successful getting a developer job these days in general and getting a Python job in particular.
So thanks so much to the panelists who contributed to this show.
Before we wrap things up, Lorena and Mahmood had a few parting thoughts for us.
Okay, that is my questions.
And I guess just kind of as a last bit, I did like this question about advice for other new developers looking for their first job.
So I'm going to be devil's advocate and add another response here.
So for that in particular.
So my advice to anyone who's a new developer looking for their first job, especially if you're someone who feels perhaps like maybe you shouldn't be in the field.
Imposter syndrome is rampant.
And I think many people feel like imposters, even if you've been coding since you were eight.
I think what's really important is to understand the work environment you're going to be going into.
First of all, you know, knowing the problem space that you'll be working in.
Is that interesting to you?
If you're a bit indifferent and are looking for just that first job in general, understand how you are as a person who codes.
How do you learn best as a new developer?
If you're a junior and this is your first time looking for a development job, it's going to be important that you have good support.
So are there are there seniors that you compare with?
Are there seniors who will mentor you?
Is the place you're working?
Do they participate with lunch talks?
Do they do they care about hosting meetups?
There's a few ways you can gauge this.
Or, you know, you can even ask to do a coffee with the company that you're possibly going to be interviewing at.
All of these things are really good ways to if you able if you can if you can do a coffee with a developer on the team, if you can go to their space when they have a meetup.
All these are great ways to learn more about the team and the environment at large there.
So really best advice.
Be true to who you are.
Know what you need in order to succeed.
So set yourself up for success.
Find a team that matches your style of learning.
OK, I hope that helps.
Thank you so much.
Thanks for doing this, Michael.
I really can't thank you enough.
You know, I'm so psyched to just start sending people links to this, you know, instead of having to, like, you know, go through this whole rant every single time.
It varies a lot from person to person.
But really, everything that I put in here is, you know, pretty generalizable stuff.
And it's what I say to, you know, basically everyone who asks me this question.
So really good work.
Really good idea for a show.
Really looking forward to hearing what the other people have to say.
All right.
Have a good day slash night.
Bye-bye.
This has been another episode of Talk Python to Me.
Thank you to all the panelists who participated in today's show, which has been sponsored by Hired and SnapCI.
Are you looking for a new job or considering a job change?
As always, Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to me to get five or more offers with salary and equity presented right up front and a special listener signing bonus of $4,000.
SnapCI is modern, continuous integration and delivery.
Build, test, and deploy your code directly from GitHub, all in your browser with debugging, Docker, and parallelism included.
Try them for free at snap.ci slash Talk Python.
You can find the links from today's show at talkpython.fm/episodes slash show slash 41.
And be sure to subscribe to the show.
Open your favorite podcatcher and search for Python, which should be right at the top.
You'll also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
As always, thank you for listening.
Smix takes us out of here.
Stay tuned.