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

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

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 (http://www.zorotools.com) 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 Zorotools.com 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.

Seven Languages, Seven Weeks, the beginning

A couple of days ago I got an ad for a new book, still in beta, from the Pragmatic Bookshelf – Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, by Bruce Tate. The book covers some key concepts in seven different languages (Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby) over the course of seven weeks, with the discussion of each language broken up into bite-size “days” of discussion, examples, and coding assignments. The idea (which I totally buy into) is that seeing how different languages with different programming paradigms handle various problems will improve one’s understanding of programming overall.

According to the author, he used an online poll to choose the languages, and then made a few tweaks – JavaScript was just too popular, Python was too like Ruby, etc. While it’s not exactly the list I would have chosen – Io? Prolog? – it’s a pretty buzz-worthy collection. Since I already know Python, I’m happy enough that it didn’t win out over Ruby.

The seven in seven thing is sort of a gimmick, I suppose, but a darned good one. I’ve always liked the idea of learning different languages, both human and programming, and this will give me a framework to hit some of the programming languages I’ve had on my list for a while.

My plan is to post my reactions as I work through this grand tour of languages, particularly from a Python perspective. It begins with Ruby, which unsurprisingly seems pretty familiar, but then I’ve only covered one “day” so far.

Now if only someone will come up with a similar book for human languages that includes Hindi, Mandarin and Finnish, I’ll be set for the rest of the year…

My “Don’t miss” posters for PyCon 2010

I’m co-ordinating the first ever poster session for PyCon US in Atlanta this year and things are finally coming together. We have 18 posters set for our 90 minute session in the Expo Hall (with snacks!) Sunday morning. I wouldn’t have minded having a few more posters, but we have a strong collection, and the current numbers mean one can spend only 5 minutes per poster, less if you take into account standing in the snack line.

So I’m thinking about the posters I particularly don’t want to miss. If  you want to do the same, you can visit http://us.pycon.org/2010/conference/posters/accepted/ and see the lineup. Here’s my list of “don’t miss” posters:

• P3. “Python 3.1, Unicode, and Languages of the Indian Ocean Region”, by Carl Trachte – I studied Sanskrit and Egyptian in grad school, and I’ve always been interested in languages and fonts. And I have to trade a few jokes with Carl.
• P9. “3to2”, by Joe A Amenta – the potential of 3to2 to help drive adoption of Python 3 is so great I just have to see this. And say “way to go” to Joe in person.
• P13. “Distributed Version Control in the Classroom”, by Dr. Daniel Rocco, Will Lloyd – as a teacher of programming I’ve tried (and not really succeeded) to introduce a DVCS before. I need to see how these guys make it work.
• P14. “Join Open Source! We need you – tips on finding a project”, Asheesh Laroia – How can I not want to see a poster from someone who would make a “Soylent Green” joke in his decription? 😉
• P20. “Teaching Programming with Python & Robots”, Jay Summet – Teaching programming with cute little blue robots – ’nuff said!

Quick Python Book, 2nd Edition

Book project complete

I’ve finally finished a book project – The Quick Python Book, 2nd ed. from Manning Publications was published as an ebook last week and will be available in traditional dead tree format in mid-January.

QPB had been selling steadily for the Manning folks for years, since it came out in 2000 and they wanted it updated for Python 3.x. Since the original authors weren’t available, I got the job.

It was billed as a quick and easy job, and it was probably easier than writing from scratch, but revising a programming book from version 1.5 of Python to version 3.x was a lot harder than I’d expected. On the other hand, I also learned much more about Python 3 than I’d expected. Suffice to say I’m a complete convert and am impatient for everyone to get their libraries converted so we can move to Python 3 everywhere.

I also got a real feel for the tech book production process. I really think that Manning’s process is very sound and the people I worked with were first rate. Unlike my ill-fated project with O’Reilly, this was tolerable and my efforts to get things done on schedule were appreciated.

Anyway, my goal now is to do some screencasts to help publicize the book. Since I’ve never done any video editing before, this will take a little learning as well.

I also have a couple of other Python projects in the works which I’ll now be spending my time on – more about those soon.

 

Installing Python 3.0 on Ubuntu

In the course of updating a book for Python 3.0, I’ve had a lot of need to test and compare code in Python 3 and Python 2.6. The first is obvious, and the second is needed because Python 2.6’s -3 commandline switch is a  key step in the process of converting code from the 2.x world to Python 3.

Python 3 vs Python 2.6

In this post I’ll talk about installing Python 3.0 from source. Python 2.6 works much the same way except that you need to exercise some caution to make sure that 2.6 doesn’t replace 2.5 as the default Python. This is a bad thing because all the Python packages and libraries you install by way of Ubuntu packages are tied to the default Python 2.5 installed automatically. If 2.6 becomes your default Python interpreter, suddenly you lose all of those packages. Python 3.0 on the other hand will not set itself up as the default Python interpreter unless you explicitly tell it to.

The problem with Ubuntu

The problem with Ubuntu is that I’ve been running it for a few years and I’m spoiled. Using synaptic or apt-get to install software has become second nature to me, and it’s been a while since I installed any significant package from source. So when I needed the latest Python installed, my automatic reaction was to look for packages.

The bad news wasn’t unexpected – there are no Python 2.6 packages in the standard repo’s, which is really no surprise since 2.6 wasn’t released until after Intrepid. However, there were packages for Python 3. Beta and RC versions, to be sure, but there were packages. The problem was that while the base Python 3 package installs just fine, there seems to be no compatible Tkinter package. No Tkinter, no IDLE. Since the book I’m revising makes some mention of IDLE, this was a deal-breaker for me.

Back to the source

So out of necessity, I figured out how to make source installs of Python 3 and Python 2.6 (mostly) happy on Ubuntu 8.10. If you’re familiar with compiling from source on Linux/UNIX, just grab the packages listed below and get to it. OTOH, if you’re new to compiling, I’ve given more complete directions below…

General Prerequisites

In general, you need the following packages installed before you try to build Python from source:

1. build-essential – the compiler and tools to build pretty much anything.
2. libsqlite3-dev libreadline5-dev libncurses5-dev zlib1g-dev libbz2-dev libssl-dev libgdbm-dev and tk-dev – these packages (and their dependencies) are needed to build various Python libraries. Note that you need the “-dev” versions. Having libsqlite3 installed, for example, won’t be enough to build the Python libraries.

If you’re already at a terminal prompt the fast way to handle the above is:
doc@x60:~$ sudo apt-get install build-essential libsqlite3-dev libreadline5-dev libncurses5-dev zlib1g-dev libbz2-dev libssl-dev libgdbm-dev tk-dev

If you installed the Python 3 Ubuntu packages, you should uninstall them before going on.

Installing Python 3.0

1. First you need to get the Python 3.0 source from http://www.python.org/download/ – choose either of the compressed source tarballs and save to your home directory (or other convenient spot).(For the following steps you need to be in a terminal window)
2. The next step is to unpack the tarball – switch to the folder where you saved the tarball and…
   
doc@x60:~$ tar xvf Python-3.0.tgz
3. The tarball should be unpacked into a folder called Python-3.0, so switch there…
   
doc@x60:~$ cd Python-3.0
4. There are 3 steps to compiling from source – configuring the package, compiling, and then installing. You configure the source package with the configure command;doc@x60:~/Python-3.0$ ./configure (the “./” is important here)

   This command checks your system and sets up the correct options for the build. It should end with a statement “Creating Makefile”. If there are errors instead, they must be fixed before you go any further.

5. The compile step is pretty easy – you give the “make” command:
   
doc@x60:~/Python-3.0$ make

   The make command will take some time, since it has to compile everything. Again, if the make ends with an error, you must fix the error to go on.

6. The install step is the big one, since it actually puts  Python 3 on your system. By default Python 3.0 will not replace your existing Python, so it’s safe to go for it:
   
doc@x60:~/Python-3.0$ sudo make install

   You need to use sudo because the install will try to place the files in spots where a normal user doesn’t have access – by default under /usr/local/.

After this, you should have python3.0 and idle3.0 available from the commandline. Creating menu entries,shortcuts, etc, I’ll leave as an exercise for the reader.

One of the Biggest Challenges in Teaching Programming

It’s not what you think. It’s not “when do you introduce objects?” Nor is it “which language?” or even “which approach?”

Nope. As a teacher for all these  years I’ve found the hardest thing about teaching programming is coming up with the right problems. Lets face it – the bulk of problems and examples in almost all programming texts are just awful. They tend to be simpleminded, boring, obscure, or just plain lame. We’re all sick of the dreaded “hello world” first program. When I titled my last PyCon talk “Goodbye hello world” I got a reasonably full room, probably largely because of the title.

Not that I’m free of blame either. I’ve assigned the various calculators, cash registers, math functions, etc. right along with everyone else. Because they need to do something and it’s hard to come up with problems that are at the right level of difficulty, illustrate the concept being taught, and are interesting, engaging and fun.  So we just do the best that we can and hope to get through before the boredom sets in.

Of course, I’m being a bit sneaky here. I’m hoping someone will read this post and refute me by posting a bunch of boffo exercises. That would really teach me… 😉

I have found a few problems/projects that I thought did work well, so let me get the ball rolling:

• Conway’s Life – great for several things, including 2-D arrays, simulations and timesteps, even objects. Kids can find it fascinating and every time I assign it, at least one kid gets completely wrapped up in it.
• graphics and animation – in Python the Livewires library makes animation pretty easy, and kids have enjoyed making things move around the screen. They also are learning looping and branching at a minimum, but they don’t seem to notice.
• turtles – replacing “hello world” with some simple turtle graphics has also worked well. And the sequence of movements makes the idea of a program as a sequence of instructions clear from the beginning.

‘Learn Python’ Launches

Welcome. This is the inaugural post for a collection of odds and ends (probably mostly odds) relating to the process of learning (and teaching) Python. I’ve been programming for 20 years and teaching programming for over half that time, and a proponent of Python since 2000. I’m also working on an upcoming book on Python for a well-known series by a well-know tech publisher. (More of that later )

My hope is that this blog will generate some discussion and that it will be useful both to the readers and to me. There is a movement in education circles called “Writing Across the Curriculum” which talks quite a bit about the benefits of “writing to learn”. If nothing else, that should work.