jessenoller.com

Fol­low­ing up on my “Find­ing Python peo­ple is hard” I fig­ured I’d send the call out again.

We’re look­ing for local-to-massachusetts (we’re in Acton, MA) peo­ple who are inter­ested in join­ing a dynamic, quality-focused test/automation team. Ide­ally, can­di­dates are flu­ent in both test­ing (areas may include: per­for­mance, regres­sion, web, stream­ing video, stor­age) and Python programming.

If you’re a strong test­ing per­son with some pro­gram­ming — maybe you’re not flu­ent in python — we’d still be inter­ested: We have no prob­lem teach­ing you Python. If you’re a strong Python per­son, but maybe with­out a test­ing back­ground — you’re also wel­come. Inter­nally, we use Java/C++ and Python — expe­ri­ence with all, or some of those lan­guages is great.

Even if you’re just start­ing out — per­haps you’ve just grad­u­ated col­lege — we’re look­ing for peo­ple that want to be great engi­neers. We look for strong engi­neer skills, con­tri­bu­tion to open-source work — we’re look­ing for peo­ple of many skill lev­els to join the team.

The role is for some­one to join the Engi­neer­ing team with a focus on Auto­mated test engi­neer­ing. We don’t slot peo­ple into “just test­ing” or “just dev” — we hire great engi­neers, and peo­ple who want to be great engi­neers. The core devel­op­ers help drive test­ing, and the testing-focused peo­ple help drive core devel­op­ment. The entire com­pany is focused on pro­vid­ing the high­est qual­ity prod­uct to our customers.

As part of this role, you will be devel­op­ing every­thing from sim­ple unit tests to highly com­plex func­tional level tests. Some of the more chal­leng­ing aspects include the fact that the prod­uct itself is very performance-driven, so the tests we develop (in Python) have to be able to drive a prod­uct capa­ble of push­ing tens of giga­bits of video data across the wire to it’s very lim­its. The prod­uct uses dis­trib­uted tech­nolo­gies and is a loosely-coupled sys­tem — we have to test and prove that as well.

Inter­nally, we’re using such tools as the pro­cess­ing library for con­cur­rency, Nose, YAML, etc. We encour­age open-source con­tri­bu­tions and com­mu­nity involve­ment (see the nose plu­gin I recently open sourced, and the PEP 371 work I’ve been able to do) and explo­ration of new tech­nol­ogy that might help us devise more effi­cient test­ing strate­gies. If you like push­ing bound­aries — this is the place for you.

A great exam­ple of one of the chal­lenges is a test I’ve worked on for some time — I’ve had to design a highly con­cur­rent test that can lever­age a sin­gle test client’s resources to the max to drive load against the sys­tem, while also gen­er­at­ing sta­tis­ti­cal anom­aly events to trig­ger inter­nal behav­ior to the sys­tem. Of course — just design­ing it for one test client won’t scale: This test has to be locally con­cur­rent as well as have the abil­ity to spread out to mul­ti­ple test­ing clients. Oh — and it has to gen­er­ate hun­dreds of giga­bytes of data as fast as it can to push the system.

Some of the tech­nolo­gies I’ve been per­son­ally explor­ing are the Actor-Model approach to con­cur­rent pro­gram­ming, Twisted for asynchronous/concurrent test­ing, etc. No tech­nol­ogy or approach is excluded — we approach all of the test devel­op­ment with the zen of python in mind:

There should be one– and prefer­ably only one –obvi­ous way to do it.

And just to add to that: There is only one way to do it: The way that works. If we find that an old approach doesn’t scale or do what we need it to do, and we have a new approach that can do it bet­ter, faster, cheaper, etc — we’re not afraid to adopt it.

This is a startup: and we’re really ramp­ing up on the automa­tion of the tests — so noth­ing is set in stone. We use Ubuntu, OS/X and even Win­dows for the devel­op­ment envi­ron­ments. Pick your edi­tor, pick your machine — the team is focused on mak­ing us, and you suc­cess­ful. Every engi­neer in this orga­ni­za­tion is empow­ered to do what it takes to get the job done.

If what I am say­ing sounds inter­est­ing — send me an email, or post a com­ment. I’m very inter­ested in talk­ing to you.

Following up on my "Finding Python people is hard" I figured I'd send the call out again. We're looking for local-to-massachusetts (we're in Acton, MA) people who are interested in joining a dynamic, quality-focused test/automation team. Ideally, candidates are fluent in both testing (areas may include: performance, regression, web, streaming video, storage) and Python programming. ...