Jacob Kaplan-Moss

Tag: programming

🔗 Thoughts on my first machine learning project November 11th, 2022

Fantastic post about what building an ML system feels like.

Quality Is Systemic September 9th, 2022

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

Work Sample Tests: Wrap Up and Q&A January 6th, 2022

This is the final post in my series on work sample tests. It’s a wrap-up post: I’ll address a few random points I couldn’t quite fit in elsewhere, and answer some questions from readers.

Work Sample Tests: What doesn't work (and why) December 30th, 2021

I’ve written about a bunch of effective work sample tests and the “rules of the road” that make them effective. One thing I haven’t talked about is counter-examples: types of work sample tests that don’t work. I tend not to do this sort of thing: I find it’s usually more useful to talk about what does work than to pick apart what doesn’t. But here, I think it’s illustrative: looking at why certain kinds of work sample tests fail can help illustrate the principles of effective tests. Let’s look at a few kinds of work sample tests that (usually) fail, and why.

Work Sample Tests: Labs & Simulation Environments December 24th, 2021

The work sample tests I’ve covered in this series so far all involve software development. But what about roles that don’t involve day-to-day coding: roles like security analysis, penetration testing, technical support, bug bounty triage, project or program management, systems administration, technical operations, and so on? For those roles, I turn to simulated, “lab”-style environments. Here are some examples of that kind of test.

Work Sample Tests: ‘Reverse’ Code Review December 15th, 2021

For most software engineering roles, the best work sample test will be some combination of the exercises I covered earlier in this series. But not every role; there are some circumstances where other types of tests fit better or are better at revealing some critical piece of information relevant to hiring. This post covers one of them: a “reverse” code review, where instead of you reviewing the candidate’s code, you have them review yours.

Work Sample Tests: Bring Your Own Code December 7th, 2021

If you’re hiring engineers, some candidates will already have code they can share: side projects, open source, and so on. It’s silly to ask those candidates to write new code just for your interview if they already have code they can share. So, if you’re asking candidates to code as a work sample test, you should also offer to let candidates submit something they’ve previously written. Here’s how.

Work Sample Tests: Pair Programming November 30th, 2021

I tend to prefer asynchronous work sample tests. The flexible scheduling of asynchronous exercises (i.e. “work on this whenever you like”) works better for the majority of candidates. But for some candidates, and some roles, synchronous exercises work better. By “synchronous” I mean: work sample tests that are explicitly scheduled, and that has both the interviewer and the candidate working directly together at the same time. In these cases, I often turn to pair programming.

Work Sample Tests: Coding “Homework” November 23rd, 2021

Coding homework is my default work sample test: I use it for all engineering roles unless it’s obvious that another kind of exercise is better. There are good reasons to make homework-style work sample tests the default: they’re relatively easy to construct, they scale reasonably well to large hiring rounds, they’re accurate simulations of real work, and easier than most other kinds of tests to construct in a way that maximizes inclusivity. Here’s how to conduct a coding homework work sample test.

Peter Norvig on programming languages October 18th, 2010

Peter Norvig: [Programming] language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don’t have those things you’re in trouble regardless of your language choice.

Backwards compatibility June 9th, 2010

Backwards compatibility is pain sometimes: # We need backwards compatibility with code which spells it this way: # def my_view(): pass # my_view = cache_page(my_view, 123) # and this way: # my_view = cache_page(123)(my_view) # and this: # my_view = cache_page(my_view, 123, key_prefix="foo") # and this: # my_view = cache_page(123, key_prefix="foo")(my_view) # and possibly this way (?): # my_view = cache_page(123, my_view)

Professionalism July 4th, 2009

Yes, it’d be nice if contractors kept up to date on the progress of the various building codes. They don’t. There are a lot of people who asked about the building codes in the 1970s and were told (right or wrong) what they were. So they went ahead and learned their trade, build their homes, and chose watching a DVD or spending time with their kids over watching city council do battle over asbestos insulation.…

"Syntactic Sugar" November 22nd, 2008

It frustrates me when I hear people dismiss the differences between computer languages. There really isn’t any difference between languages, the argument goes, because “all Turing complete language differ solely on syntactic sugar.” That’s a direct quote from part twelve of Michele Simionato’s excellent The Adventures of a Pythonista in Schemeland, but I’ve got no beef with his articles. Like I say, they’ve been an excellent introduction to Scheme for me.…