How Not to Get a (Python) Job – a rant

May 27, 2012

How Not to Get a (Python) Job – a rant

At PyCon 2011, Brian Moloney (of Imaginary Landscape here in Chicago) gave a talk titled How to Get A Python Job”. It wasn’t really so much about getting specifically a Python job as about how to land any job. It was the same sort of advice you can find in a lot places – hints on how (not) to apply, how (not) to present yourself, how (not) to interview, how (not) to impress interviewers, and so on. If you’re looking for a job, go watch it and take his advice very seriously.

I went to Brian’s talk because I had just found my own Python job and I was curious about his perspective. I had started my own job search with my fair share of negatives – the economy was in the toilet, I was over 50, I didn’t have much formal training, my experience (in private education) wasn’t exactly mainstream, etc. And yet within 3 months of sending out my first resumé I had a job, and even had to turn down other offers. Even as I settled into my new job, I was frequently contacted by recruiters looking for Python programming help. And yet, I’ve heard many people complaining quite vocally about how difficult it was (and is) to find programming jobs in general and Python jobs in particular.

As the IT director and lead developer at a startup trying to grow its tech staff, I’ve been heavily involved in searching for and interviewing developers. In that process I’ve seen people of all ages and backgrounds painfully ignore the basics of getting a job. So the idea behind this post is to put one more voice out there, sharing some of the things that make me not want to hire an applicant.

Here are the things that make crazy. Take from them what you will.

Not knowing the market. Several candidates have said, “it seems like no one is looking for Python people.” Say what? I get called regularly by recruiters looking for Python developers. We’ve been searching for a Python dev for months. Admittedly, the market is better for more experienced people and you might need to relocate, but even junior Python dev positions are going begging. Ask any recruiter, we’re a hot commodity. When someone tells me that no one is hiring for Python, that tells me one of two things… either that person doesn’t know the job market (at least around here), or they aren’t really a Python developer. In the first case, I’m a pretty firm believer that the responsibility for finding jobs lies with the job seeker and not having done research on the market it a bad sign. If you don’t care enough to do research to find your own career, why should I expect that you’ll have the initiative to solve problems and help our team move forward? And the alternative is worse – in a market where knowing how to spell the word “Python” (at least on a resumé) should get you at least a few calls, not getting any traction is a red flag.

Not knowing the craft. This is so obvious that it shouldn’t need saying… except for the fact that it needs saying. “If you’re applying for a Python programming job, you should know as much as you can about Python and programming.” That means a basic understanding of the language, some basic knowledge of programming, some familiarity with the common or hot tools and technologies, etc. Obviously the depth of that understanding will vary depending on your experience, and for junior positions, particularly, you’re not expected to know everything, but you still should have some idea of the field.

I’ve interviewed candidates who couldn’t tell me how they would approach a problem, or what libraries they would use (or even have used), who’ve never even heard of Django, and so on. I’m no fan of springing little programming puzzles on candidates, since to my mind that mostly tests the ability to solve little puzzles, and I don’t expect lengthy dissertations on advanced programming topics, but I do expect you to be able to know the basics of coding and Python syntax, to have at least a nodding familiarity with current technologies, and to be able to discuss the approaches, tools and pitfalls involved in some of the coding you’ve done.

And speaking of the coding you’ve done, particularly for junior developers, you may not have done that much professionally. However, if you haven’t done anything outside of classwork, I’m going to be pretty skeptical. There are tons of opportunities to get involved in open source projects, to create your own web site, to help with something for a business, a club, or even just scratch your own personal software “itch.” It doesn’t matter how big or how successful your projects were, what matters to me is that you’re interested enough to be in the game on your own time.

Not knowing us (and the job). It’s been said before, but if you don’t care enough to do some research and thinking about us and the position before you come in for an interview, why should we think you’ll care once you’re hired? You’ve got the job description, probably some names of people at the company, and the entire Internet as resources. Even if you don’t have absolutely all the information, you should be able to find out enough to ask questions and maybe even float trial solutions. Why do you do x? How do you deal with issue y? Have you ever thought of trying z to solve this problem? Even if you’re completely wrong about your assumptions, the very fact that you’re thinking about our business is very compelling. If you want to be really sneaky talk about how “we” might solve some of those problems together.

And speaking of sneaky (not really, since it’s clear if you’ve done it or not), if you know who you’ll be interviewing with, look the people up online. Google and LinkedIn are your friends here. At worst you’ll have a feeling of control during the interview and at best you can work in a comment or question relevant to the interviewer’s background, which is almost always good. I’m not going to support hiring you just because you looked at my LinkedIN profile, but it does tell me you cared enough to do some research, and that’s a good thing.

Not selling yourself. Don’t go into your shell – there is a job open and somehow you’ve gotten an interview. So take advantage of it! You may be an introvert, it may be hard to talk about yourself, or maybe you just don’t think you should have to “market” yourself. Whatever… but in this situation you’ve really got to go for it. Show us how interesting you are, how much you care about the work, how cool you think the job is, how much you would bring to the team. If we hire you, we’ll have to work with you every day, so why should we look forward to that? (In a business sense, of course – promising to keep everyone loose with dirty jokes is probably not be the way to go here.)

We can only hire a few people and we need to get a lot of stuff done. We have lots of problems crying out for solutions so we want someone who is eager to tackle those problems and has some chance of succeeding. As Joel Spolsky succently put it, “smart and gets things done.” You may not have the exact sklls to fix every problem at this moment, but that’s not the entire point – as a startup none of us had the exact skillset for this business when we started. But all of us were ready to dig in, we figured it out fast, and we got the job done. And that’s the sort of person we need.

Note: this is not the same as emphasizing how good this job would be for you. I understand that you want to move from that old job to a new, more interesting area. I applaud the fact that you just love to learn new things. I’m totally on board with how wonderful this opportunity would be for you… but we need to move and scrub a ton of data, polish the UI, analyze customer behavior, and keep thinking of new ways to stay ahead of the game. How are you going to help us do that?

Please feel free to ping me with comments or questions: comments are not automatically published, so if you have a question or comment, please feel free to leave a comment and indicate if you want it to remain private.

Edit: If you’re looking for Python jobs you might try the Python Job Board, which as it happens is where I found my current position, or the PyCoder’s Jobs site (I have no direct experience with this one, this is not meant to be an endorsement), which is dedicated to Python jobs and run by the same people who do the Python Weekly newsletter (which I do find very useful, actually.)

[edited to add company name and contact info]


ISTE, Python and Robots

June 28, 2011

Monday I was at the ISTE (International Society for Technology in Education) conference in Philadelphia to give a version of the same talk I gave at PyCon in March, talking about my experiences teaching Python using the combination of Scribbler robot and Fluke bluetooth board developed by Georgia Tech and Bryn Mawr. I think the talk went reasonably well – 50 or so attended, and they laughed in the right places, which is my main criterion for success. I also got to say hi to a few old acquaintances and even meet a couple of new faces with Python edu-sig connections.

Although I was talking about a class I’d taught, and combining robots with Python, the other point that I hope the audience also got was the need to make programming classes relevant, real, interesting, and above all, darned cool. As anyone who’s heard me talk about it knows, I’m happiest teaching project based courses where we’re free to pursue interesting topics as they come up. Writing a chat bot in Python, plotting the Mandelbrot set in Java, or trying to crack passwords in C, it’s the joy of tackling a hard problem and doing something really exciting that has driven all of my best classes.

It doesn’t have to be robots, or necessarily Python, but if kids don’t leave a programming class feeling they’ve truly done something pretty amazing, I think we’ve missed the boat. That feeling I think is key to getting a more diverse group of kids into the field (yes, I mean girls, but others as well) and it should be within reach – there’s so much amazing stuff they can do.

I’m not alone in this thinking, of course. Many of the edu-sig gang have done great work in this regard, including Jeff Elkner, Kirby Urner and Brian Brumley, and many others. But we’re too few, and too spread out. In general, the state of secondary and middle school programming instruction in this country reminds me of the old Woody Allen joke about the Jewish ladies at the resort, “The food is so awful here…”  “Yes! And such small portions!” We have to keep working on that from all sides.

I was also surprised to find that I was the only Python related talk at all of ISTE. I’m afraid the joke is right – if it doesn’t cost money, it gets no traction at ISTE. Similarly, there were only a few other open source related talks, a sad decline from my first couple of years at ISTE (then NECC) as the Python presenter at the start of the Open Source Pavilion. Then it looked like open source software might make a real dent in one of the most commercialized conferences I’ve ever attended. I could seriously say that I went to preach Python and open source at NECC because that’s where the unconverted were. Well, the unconverted are still there, and more numerous than ever, I’m afraid.

Still, there were some encouraging notes. Out of the 50 or so who attended my talk there was one gentleman who was trying to get programming classes offered by his school, and who thought that Python and robots might actually be the way to persuade his administration to try it. Another was reworking an established program to include more Python as the capstone language, because, as he put it, “all the colleges are switching to it”. I truly hope he’s right on that one.

Finally, thanks to my employer Zoro Tools ( for giving me the time to go make the presentation – go buy something
from us – we sell nearly everything. 😉

And even greater thanks go to the Python Software Foundation Board for supporting my trip. My rather quick departure from Canterbury for had left my travel to ISTE unfunded, and the PSF stepped in to help me for the second time. That’s probably something that the PSF should brag about somewhere – what other open source programming language’s foundation has cared enough about education to send someone to speak at big conferences like ISTE? If others have, good for them, but I’m thinking it’s pretty rare.

PyCon Poster Session will be Amazing

January 23, 2011

As the poster session chair, I’ve been watching poster proposals come in for PyCon over the past several weeks. I was very happy with the posters last year, but this year we have a truly amazing collection. Since the submission deadline has been extended until Tuesday, January 25, (which is also the Early Bird registration deadline) I won’t name specific posters yet, but the submissions cover the spectrum.

There are posters on Python in the sciences and bio-informatics, on Python for education and citizenship, on new packages and uses of Python, and even a couple of posters that showcase Python as a tool for hardware hacking “makers”.  And every single one of them looks great. Every. Single. One.

As I recall the excitement in the room last year for the first PyCon poster session ever, I can only smile as I think of what the reaction will be to this collection. I promise you, people will be wishing that the poster session could last all day to give them enough time to inspect each poster and chat with every presenter.

Better yet, you still have a chance to join this impressive company. If you want to submit a poster, just swing by the poster session CFP on the PyCon site by Tuesday to submit a poster proposal.

See you at PyCon!

Not Python – AppInventor doesn’t quite do Life

January 10, 2011

AppInventor Test Drive

I’ve always been sort of fascinated by drag and drop programming schemes – the sort of thing where you use little graphical blocks to represent code structures. The simplicity of it appeals to me as a teacher of programming for one thing. And I’m not alone – this idea is used in languages/environments like Scratch, which is gaining popularity in the school world right now.  The problem with languages like those is that they always seem to be limited – they’re too cumbersome to write much of a program. And for teaching languages, sometimes that’s OK.

Recently, I decided to try a drag and drop language with at least somewhat higher expectations – Google AppInventor. I’d written a few little test apps using AppInventor – a clock, some tests of location, buttons and colors, and one where I could “roll” a ball around the screen by tilting the phone, and it looked like it had some real potential.

A Real Test – Life

That led me to try writing Conway’s Life. I like Life because it’s fairly easy to write (I make my AP Comp Sci students write it every year), it’s fun to look at, and yet it asks a certain amount from a language – 2 dimension arrays, a fair amount of processing, some screen redrawing, etc.  I know that following a discussion of Alice, our tech support specialist, Simón, wrote a version of Life in Alice, which was painful – it required huge contortions to create a 2 dimension array of cells, and was painfully slow with even a 10 by 10 world.

So New Year’s day (yeah, I don’t really follow bowl games 😉 ) I started on it and made a fair amount of progress. Some things were actually easier than I expected. Creating a 2 dimension array as a list of lists was obvious for a Pythonista like me, and drawing the cells on the canvas was also dead easy.

Other things were not quite so straightforward, but still no real problem. For example, AppInventor doesn’t have a “counting” for loop, but only a “for each item in a list” loop. That meant to get the indexes I needed to check surrounding cells I had to use while loops and manual increment counters, but that was no big deal.

So after an evening of messing with it and looking at the documentation, I was in pretty good shape – I had a 20 by 20 “world” or cells which I could randomly set as alive or dead and I could iterate through that world and draw dots on the screen for the live cells.


At that point frustrations started to set in. The first frustration wasn’t really AppInventor’s fault entirely, but rather just the nature of the coding by blocks interface. I soon found the process of coding by blocks very irritating. Switch to the right block pallet, drag out the block you want, set initial values, then drag into place, rinse and repeat. It doesn’t seem so bad when you first start out, but keep in mind that everything is a block. For an if statement comparing two items, you need four blocks – the if, the comparison, and each item. When you know what you want to do, repeating that process gets very tedious very fast. In fact, I started wishing I could just open a window and type in the code. Of course, a little tedium never stopped me, so I pushed forward.

The second frustration ended up being a bit more of dealbreaker. In its current incarnation, AppInventor allots a fixed size panel for assembling blocks. As my logic got more complex, my stacks of blocks grew until they spilled off of the panel. That could have been survivable, but then I found I couldn’t edit the parts off the panel, and I couldn’t move the stack so that the bottom end would stay on the panel. You can zoom in and out, but that doesn’t change the relative size of the blocks compared to the panel.

At that point, just short of getting the rule processing finished, I gave up. I suppose I could have gone back and tried to break things down into smaller functions or pulled my stacks apart for editing and the stuck them back together, but I had simply had enough. And I had already broken things down so that the functions would have been under 30 lines of Java or so. It’s not an intrinsic limitation, of course, but for the moment it does limit the code you can write. That was the issue that made me give up, although I might have struggled on a bit if there hadn’t been one other issue.

And speed…

I also ran into a issue with processing speed. There isn’t any. Running on a Droid Incredible, it took 2-4 seconds to process and draw a 20 by 20 world. That’s pretty shocking. After I gave up on the AppInventor, I wrote a similar implementation of Life in Java and doing the same processing and drawing seemed to be nearly instantaneous, to the point that I needed a 200 ms. delay in the processing loop. (For the record, I never got to the point where the AppInventor version was looping to update, instead I was starting each generation with a button press.)


In spite of the fact that it failed my Life test, I find AppInventor an interesting tool. As a teacher, I can see it being useful for introducing programming to non-programmers. The blocks should make things easier to manage and understand, and the coolness factor of writing an app for your phone would boost motivation. It also is good as GUI-based “glue” for the OS, which I’m sure was one its primary purposes – you can tie several different bits of the phone’s functionality together pretty quickly. Building on this I can see a use as almost as an interface generator – whipping up a quick UI that then calls other code (maybe written in Python for the ASE?) and grabs the results. As I get time, I’m going to experiment with this.

Python in the news

December 12, 2010

How we got a Python story published

This past Monday, the unlikely occurred. The morning newspaper here in Fort Wayne, Indiana ran a small article on high school kids using Python. That’s unlikely for a few reasons – first, while “tech” school programs around here tend to get news coverage, you almost never hear about programming (that’s because even in “tech” high schools, very little programming is taught). And when programming is taught in high schools, the language tends to be Java or Visual Basic. (I know, I know… don’t even get me started on that topic.) And most people around here, reporters included, have never heard of Python.

The story was about my Python class, and it wasn’t an accident. The class is a project based class intended to be accessible to non-programmers, where we’ve been exploring the capabilities of Georgia Tech’s combo of a Scribbler robot with their Fluke bluetooth board. If you missed Jay Summet’s poster at PyCon, the cool thing about this pairing is that you can run Python on a laptop and use it to control and interact with the bot by way of the bluetooth connection. So my kids have been drawing shapes, solving obstacle courses, taking and processing images, playing music, etc. with the little guys. Along the way they’ve also learned about looping, branching, functions, modules, documentation and sharing code, among other things. It’s probably been one of the cooler classes I’ve ever taught, and I’ve been enthusiastic about promoting it internally here at school – to the school newspaper, the school web site, teachers, the school administrators, really anyone who would listen. 

It’s a great bunch of kids and they’re doing some fun and interesting projects, but I know from experience that alone won’t get you much press. In this case I think we did some things right to get the word out about my class and Python. Since I’m pretty sure that my class isn’t the only bunch of people in the country doing newsworthy things with Python, I thought I’d outline what we did in the hope that it might make a small contribution to the Python advocacy front.

What we did

I’m not a publicity expert, but here is my take on how we got our 15 seconds of fame.

The first thing I did right was the internal promotion. Maybe it’s having a book to promote, maybe it’s just advancing age, but I’m getting less shy about promoting projects these days, and it does make a difference. If even the people you work with don’t know you’re doing something cool, how can you expect anyone else to care?  By making sure that everyone internally knew about my class, I got the support of our administration and the even more valuable support of our publications director. Having her help made things easier for me, although if you don’t have that help, some time and research can cover a lot of the same ground.

Getting our story published came down to 3 main pieces:

  1. knowing who to contact
  2. knowing what they want/need
  3. giving it to them

Who to contact

In my limited experience, just sending out press releases to the newspaper is rather like cold sales calling, resume carpet bombing, or handing out leaflets on a street corner – the return is vanishingly tiny. Instead, you have to make personal contact with the right person.

These days newspapers departments in particular are understaffed and overworked, so  don’t even begin to think that anyone on the other end will take the time to figure out where your news belongs. It’s your job to make things easy for them – before you do anything else, figure out what kind of story you have, where it would go, and who would write it. In my case, it’s our publications director’s job is to help find the answer to those questions, but even without that help our situation would have been pretty straightforward. The paper does a weekly “Education Notebook”, with a small education feature and education announcements, all done by the same person. She writes education stories, we have an education story. That’s the person we contact.

What do they need?

As I said, newspapers are under pressure these days – falling circulation, staffing cuts, and so on. For example, these days in Fort Wayne, with over 200,000 residents there are now a total of only four full-time newspaper photographers, and they are on the run all day. So if I want a reporter to run my story, she has to be able to see easily what the story is and how it fits in her section. So we had to tell the reporter what Python was, what our kids were doing with it, and why she (and her readers) might care. For us, that came down to 3 things:

  1. High school kids were using the same programming language as Google and NASA.
  2. Robots make for a more beginner-friendly approach to learning programming.
  3. Kids were doing some seriously cool stuff, like programming “intelligent” behavior in robots.

Give it to them

The story was good enough that the reporter and a photographer came to visit the class. Here again we made every effort to give the the story they came for. I spent a little time before class giving the photographer some background info, and once the class started they had full access to talk to the kids as they were working, and to ask me more questions for background. It’s a bit of hassle, but worth the 45 minutes or so of time it takes.

Follow up

Finally, after the article appeared, I made sure to send a quick thank you email, which is not only polite, it helps keep the connection open for the next time. And I also made sure to circulate the article link to the Python education community and other interested parties. Oh, yeah, then I blogged about the whole thing here… making sure to get the absolute maximum mileage out of one tiny article. 😉

So that’s it – I hope our experience inspires other efforts to publicize interesting Python projects in their communities.

Ohio LinuxFest

September 13, 2010

I’m recovering from the 2010 Ohio LinuxFest. Between talking about Python to Linux sysadmins for a solid day, the evening gatherings, the hallway track, and everything else, I very nearly lost my voice. But that was a small price to pay.

For my “Python for Linux System Admistrators” tutorials everything went quite well. There was a minor delay waiting for a projector, but otherwise the venue was fine and I had a good turnout – some 20-25 people who (in addition to being sysadmins) were a joy to teach. By the end of the day, everyone was tired, but I was pretty happy that we’d covered a core of Python that would a) let them get going on their own and b) was particularly relevant to their jobs. If anyone is interested some materials for the course are here. The slides are just as I used them, meaning that in some cases they are just prompts to remind me of where I’m going, rather than a standalone resource. But anyway, they might be of some use.

In addition, the bookstore sold a few copies of Quick Python Book, 2e, I caught a few good talks, and more important, I got to talk to several interesting people – maddog, Jorge Castro and Amber Graner from the Ubuntu community, Linux scribe Brian Profitt, Robert Blackwell from the Perl community (I promise I’ll be nicer when I talk about Perl from now on), and several others, not to mention a rather inebriated Buckeye fan and even my high school girlfriend. How can you beat that?

Python for Linux at OLF

September 1, 2010

I’m in the final (but not as final as I would like) stages of preparing for my day-long tutorial at Ohio LinuxFest. OLF, as we call it, is a great event, with some good keynotes, interesting talks, and even maddog. Not to mention first rate tutorials, such as, oh… “Python for Linux System Administration”.

The morning session I’ll spend on basics – writing scripts that illustrate control flow, lists, dictionaries, strings, etc. from the point of view some basic sysadmin scenarios. I’ll also introduce the basics of the subprocess module to call other Linux tools.

Then in the afternoon session, we’ll look at some more involved tasks, like traversing files systems, regular expresssions, daemons, using the network, etc.

I’m looking forward to it – I think it will be a blast.

So if anyone has any cool intersections between Python and Linux sysadmin you wouldn’t mind me stealing, or any other suggestions or words of wisdom, by all means let me know.