I wrote the other day about what I think Comp Sci majors are doing wrong at career fairs and how they should be distinguishing themselves from their peers. There’s a fun debate in the comments about whether I gave the right advice. Regardless, here’s a followup question I need answered from CS undergrads:

If you’ve been to a career fair, what did startups do wrong? How can we get you to notice us?

When I consider how we at 10gen set ourselves up at Big Ivy University’s career fair, I don’t think we did any better than the students did. We displayed our logo and the name of our product MongoDB, and … that’s it. I can’t blame the hundred kids who came up to our table and said, “What do you do?” We should say why an intership with us will be awesome, e.g.:

• The NoSQL movement is one of the most innovative areas in software these days, and we dominate it.
• We’re small, so if you’re smart you can make a big relative contribution.
• We’re run by and for coders: Our CEO codes, I code, our customers code, everyone codes.
• We’re on the kind of growth trajectory that eventually makes household-name companies.

I don’t know how to say these things convincingly, especially not on a poster, so that a smart undergrad who’s never heard of us will stop at our table. Suggestions?

I went to a career fair at Big Ivy University recently, and talked to fifty or so computer science undergrads who were looking for internships or full-time jobs with my employer, 10gen. I’m sure some of them were very smart, but they had not learned how to distinguish themselves from each other. One after another, these students came with identical resumes, identical suits, and identical pitches about why they should get a gig with us.

CS students, I want to tell you how to stand out when you’re introducing yourself at a career fair. If you’re an extraordinary hacker, you need to tell us that you are, and you need to show that you are on your resume. Otherwise we can’t find you.

What You Learned In School Is Not Enough

The first student I met at BIU handed me her resume, and I saw that she knew Haskell, and she’d done a machine-learning project. I thought, “cool,” and put the resume in the “call this candidate” pile. The third time I saw Haskell and machine learning, I realized that’s just what they teach at Big Ivy.

If you’re competing with students from other schools, then your coursework may be an advantage or a disadvantage. But if you’re coming to a career fair, you’re competing with kids who took the same courses as you. So I’m not impressed that you learned Haskell as a freshman—you’d have been kicked out of the program if you hadn’t.

One possibility too terrifying to contemplate is that the students I met at BIU thought their GPA mattered. If so, they’re in for a rude surprise. I know they all listed their GPAs on their resumes, but I forgot to look, and I think most employers will forget to look at GPA, as well.

Charisma Matters

It’s a shame, but it’s true: a firm handshake, eye contact, and a calm, friendly, enthusiastic manner make a big difference, even for nerds. I will spend more time with you, even though there are five kids in line behind you, and I will answer your questions better and ask you more questions. It’s not just that I’m biased towards charismatic people. Your social skills are part of what my company wants to hire. In the long run, if you work for us, you’ll be making friends with your coworkers, talking to customers, and presenting our products at conferences. We need you to be engaging.

Individual Projects, Unusual Languages, Unusual Courses

Look, if you’re graduating with a CS major, you will get a job. Relax. The market’s great. But if you actually care about software and want to work somewhere that excites you, you’ll need to put some effort into your resume and how you introduce yourself. Here’s what I want to see:

Individual Projects: 100 bonus points each

If you had an idea for a software project and you implemented it, then you should put that at the top of your resume. Above your name. And tell me about that project as soon as you shake my hand at the career fair. The project doesn’t have to be totally unique, or profitable, or complete—just make something. Then I’ll know you have cool ideas for things to build, and that you love coding, which is highly correlated with being great at coding. You’re in the “call back” pile.

If you haven’t built an individual project, start. Let your 4.0 GPA slip a little. It’s worth it to make time for this project. Don’t worry about getting college credit for the time you spend, just build it. Put the GitHub URL on your resume so I can check it out.

Extra Languages: 25 bonus points each

If the only programming languages on your resume are the required ones, then you’re showing me you do your homework. It’s not enough. Learn an extra language. It doesn’t have to be anything exotic like Erlang, just something all your peers didn’t learn in class. Put this at the top of your resume, under the individual project. Tell me about how you taught yourself C++ over summer break because you want to do 3D graphics for a living. It doesn’t matter if I’m not looking for a C++ programmer, you’re showing me you love learning about computers. But be aware that I may know this language, too, so if you claim you’re an “expert,” you better be for real.

Unusual Courses: 10 bonus points each

I know Big Ivy offers a computer graphics class, but it seems like only one student took it. All the rest just listed the same boring courses on their resumes: Operating Systems, Networking, blah blah blah. I know you took those courses; otherwise you wouldn’t be graduating. If you want me to notice you, take lots of electives. Again, your GPA doesn’t matter, so don’t worry about getting a little overloaded.

Longshots

Contributing to Open Source

I don’t recommend that undergrads go on GitHub seeking an open source project to contribute to. It’ll be different once you’ve been working for a few years, but right now you probably don’t have any itches that aren’t well-scratched by an existing project. Even if you do, I doubt you’re ready to write a patch that’s high-quality enough to be accepted. It’s much easier to start a new project on your own. For one thing, when you work on your own project, no one has to approve your patch.

Possible exceptions to this rule: Porting a package to Python 3 if no one else has started it; porting a package from a popular language to an exotic one if there’s no analogous library in the target language.

Freelancing

Your internships for other software companies are great, but I don’t recommend freelance work. It would probably be along the lines of setting up a WordPress site for your friend’s mother’s law firm. The level of sophistication required for your first real gig is going to stomp all over whatever summer job you get, so unless you really need the money, put your time into an individual project instead.

I have an opinion: most people learned about relational databases as if RDBMSes were designed to store the ultimate truth about some data. They figured that once the schema had been properly diagrammed and normalized, then they could load all their data into it, and finally, start doing some queries.

To pick on an easy target, look at Wikipedia’s article on schema design. It summarizes the two steps a designer must take:

1. Determine the relationships between the different data elements.
2. Superimpose a logical structure upon the data on the basis of these relationships.

Do you see a step that’s missing? If you’ve deployed and maintained a large-scale application you’ll probably see what the Wikipedia authors omitted. In fact, it’s the first step: Figure out what one question your database must answer. Then, design your schema to answer that question as fast as possible. And now you’re done. Come to think of it, you never had to do steps 1 and 2 at all.

There’s a total disconnect between the approaches of introductory SQL courses and real-world application development, and I think this disconnect is slowing down adoption of NoSQL.

Consider Facebook Messages. After a (now rather well-publicized) evaluation process, Facebook chose HBase, a NoSQL data store, as the main database for their message system. I haven’t talked to anyone there, but I figure they chose it based on this criterion:

How fast will our database answer the question, “What are this user’s most recent 10 messages?”

They chose the database system that could answer that question the fastest, and they designed the best schema they could think of to answer that question. Anything else they need to ask HBase may be slow, or difficult, but that doesn’t matter, because “What are this user’s most recent 10 messages?” probably accounts for 99% of the load on their system.

If you learned about databases in college, following some textbook, I expect you were guided through a long process of modeling real-world data using rows and columns, to express some profound truth about the data. Then, you were introduced to SQL, with which you could query the data. At the end of the course, maybe there was a brief discussion of database performance. Probably not.

Data at the scale that the largest websites handle doesn’t work that way. Large applications design their schemas to answer one question as quickly as possible, and no other considerations are significant.

The next time you read about a NoSQL database you might wonder, “What about foreign keys, or normalization? What about transactions? Why can’t I define secondary indexes? Why are range queries prohibited?” (I’m just picking some limitations at random—each system is different.) Consider who built these new database systems, and what their experience has been. The ideas behind NoSQL databases mostly originated at places like Google, Amazon, and Yahoo. They build huge systems, and huge systems’ loads are usually dominated by a handful of queries. Companies build their database systems from the ground up to optimize the performance of these queries. NoSQL databases encourage you to figure out ahead of time, “What one question do I need to answer?” Figure that out, and choose your database software and your schema based on that. Nothing else really matters.

Photo (C) Parent5446

I’ll be recapping last week’s talk on Python, MongoDB, and Asynchronous Web Frameworks this Thursday at 7pm, in Philadelphia, at the Philly MongoDB User Group’s inaugural meetup. We’ll be at the Devnuts office, at 908 North 3rd Street. We’ll have pizza, naturally.

First Philly MongoDB User Group

Here’s the slides for the talk I gave at the NYC Python Meetup tonight, on asynchronous web frameworks, Python, and MongoDB.

Direct link.

Embedded:

This Thursday in NYC I’m talking about Python, MongoDB, and asynchronous web frameworks at a meetup called For the Love of Python: Wine tasting, Red velvet cupcakes, and Tech Talks. The talk is a work in progress. To be strictly accurate, I have not yet started working on the talk, because the code I’ll be talking about is itself a work in progress. But come anyway, because I’ve been thinking a lot on this subject for the last few months, and I intend to present:

• A high-level discussion of what an async web framework is and when you need it, or don’t. I think there’s a lot of sloppiness on this subject, and I want to work with the audience on tightening up our thinking.
• A review of pymongo, pthreads, Tornado, asyncmongo, and gevent. You won’t be disappointed.
• For the first time ever, I will present an exclusive sneak-peak at my own experimental Python driver for MongoDB and Tornado, built on top of the official pymongo driver. It’s pretty snazzy, it uses greenlets, and it’s an example of a general pattern for asynchronizing synchronous database drivers that might inspire you to write your own database driver in Python. Buckle your seatbelts, we’re going deep.