Kartones Blog

Be the change you wanna see in this world

Regarding Technical Code Tests

Quick post with some personal thoughts regarding the last Code on the rocks podcast, which was about recruiting and human resources, but it mentioned the topic of technical code tests for candidates.

First, a confession: I am quite terrible at doing code tests, due to two main reasons:

  • I tend to get nervous, so I try to complete them in one sit even if given more time (like "the weekend")
  • I always time-box them if they aren't limited in time

When I start a code test, I get into a state I can only think about it, so my normal life gets disrupted until I'm done. I'm unable to take long breaks, or sleep and then continue. I also know it can be harmful for me to time-box when I could instead take advantage, because I could for example do multiple iterations using the extra time to improve something, but my reasoning here is:

  • This is a test, so for me the rule "is take it as such, a test": not strive for perfection but "what you'd do in a few hours most"
  • My time is precious. I'm not going to spend a whole weekend with an unpaid code test, I'm sorry

I've only done 4 code tests in my life (out of 10 companies I've worked/work at):

  • one I nailed it
  • other I did well enough to get hired
  • one I failed (there were external factors but I still had mistakes)
  • the 4th wasn't evaluated as I got hired elsewere and they stopped the process. I'd like to think was going to be ok

Asking for a code test it's a standard practice, and in some scenarios it is one of the few alternatives (e.g. remote work), but I dislike them as it is hard to be trully fair/objective evaluating them. It is also quite hard to come up with unbiased coding challenges, too easy to fall into either algorithmic ones, or too specific/narrow problems that while you might actually be working at if hired, you might as well not have faced before (so is not fair to ask about them). And most times there's a subjectivity factor upon the reviewers: They might not like your style of code, they might have their biases and/or preferences, and sometimes happens that they might be reviewing the code for the first time and think there is only one "correct approach".

I instead prefer other alternatives:

  • do an actual job task (or bugfix): getting paid for it as will take some time, but is a nice way to get the feeling. The main problem of this approach is it's really hard to do while working
  • "work with us for a week": Similar to previous one, but becoming a member for a certain time. Best way to see (both sides) if there's a match, you're part of meetings, etc. and not just of a specific task
  • doing a real task while pairing with an actual engineer from the company, so you don't get overwhelmed by doing something without knowledge of the scenario/context
  • if not the previous one, at least doing a code test but live with a peer from the company, in a constructive way. Probably will make you nervous but at least you're able to explain your reasonings and the other side can also ask you why you take some decisions

Also, one thing I think it is critical is to give feedback to the candidate. I'm not saying you should reply with the failure points, but at least give some general feedback so they can improve. After all, they gave you time and effort by doing it.

And finally, coding tests are a cheap way to filter candidates for the recruiting deparment, but they do take effort both from candidates and from the technical side of the company (preparing and reviewing them). Effort that sometimes the recruiters could also spend filtering their targets instead of blind-shooting everywhere. This is a complaint because I've seen and still see so many bad examples.

For me code tests just work as a filter but act like a double-edged sword. I know of a few good engineers who have failed code tests, and I've met other people who probably were good "coding" but were not somebody I'd be happy to work with. As usual, there is no silver bullet.


Recommended Articles - 2017/09/05

Vacations delayed this post a lot, but on the other hand lots of interesting articles gathered during this weeks.


Book Review: Writing Idiomatic Python

Review

Writing Idiomatic Python

Title: Writing Idiomatic Python

Author: Jeff Knupp

A small yet very useful book to teach you how to do things in a proper "Python way". It assumes you already know the language, and uses a very simple yet effective system of 1) describing the topic, 2) showing the harmful/wrong/typical way of doing it and 3) showing the idiomatic/best way to do it.

Comprehension lists, generators, choices of function arguments, default value caveats, even when to discard using objects in favor of simpler structures like named touples or just modules with functions.

Some of the examples were very revealing for me, as I come tainted from other object oriented languages and things are different in Python. You can read it in one or two afternoons so there's really no reason not to do it if you work with this programming language.

Notes

I updated my Python Gist with some notes from the book.


Recommended Articles - 2017/07/25

My latest bag of interesting articles and talks I've recently read, watched or listened too (you can check which podcasts I listen to here).


Emulators for Ubuntu Linux

I love videogames and I grow up with what now is called retrogaming. I also switched from Windows to Linux a while ago and, despite having a dedicated gaming desktop PC, it is mainly for recent titles. Taking advantage of some holidays I decided to setup some emulators at the laptop. It wasn't always easy so I decided to write this post, both for myself in case I need to repeat it and just in case it is of use to anybody else.

Shadow of the Beast - Commodore AMIGA

Note: At the time of writing this blog post, my system is an Ubuntu 16.04 x64. Based on my experience, Linux software is very sensitive to operating system versions (way more than Windows), so I can't guarantee that everything will run for example at Ubuntu 17.04.

For Arcade machines I use MAME, I use the oficial Ubuntu Software Center MAME Arcade build/binaries plus the GNOME Video Arcade GUI (available at Ubuntu Software Center too). The main issue is that it is a barebones GUI, missing many many features from things like MAMEUI, so I also keep MAMEUI inside a virtualized Windows XP SP3.

Before continuing, a small intermission to explain the reasoning behind that Windows XP virtual machine. VirtualBox has come a long way regarding Virtualization, and even under Linux (where I haven't been able to make work 3D emulation) it works quite nicely and I use it mainly for three tasks that have to do with videogames (among other unrelated tasks):

  • Playing old Windows games that don't work with Windows 7 and don't require Direct3D, like Civilization II.
  • Access advanced VirtualBoyAdvance features like object and map memory visualizers (GameBoy development related). It works really well inside VirtualBox, and Wine wouldn't load it.
  • Launching MAMEUI to see game snapshots (screenshots). Initially only until I finish doing the cleanup but I actually want to try running a virtualized MAME32. Note that I haven't tried running it with Wine, so it might work. From a host SSD it boots up in less than 3 seconds and just has configured a few shared folders to not need to move things in & out. And yes, XP is really old, but precisely is that version the one chosen for conflicting games (with Vista and 7 more than a few old Windows games stopped working). Oh, and for USB 2.0/3.0 and other goodies support, install also the VirtualBox Extension Pack.

For old Nintendo systems (Gameboy, GameBoy Color, Gameboy Advance, NES/Famicon and SuperNintendo/SuperFamicon) I use Higan. You have recent versions at PlayDeb2, but wherever you grab it, should at least be v103. The main reason (apart from typical better emulation and speed) is that GameBoyAdvance BIOS ROM loading was mostly broken under Linux and got fixed around version v100. One remark, to run GameBoy Advance ROMs, you need the BIOS ROM.

To play the SEGA MegaDrive/Genesis, I used DGen/SDL, but you need to compile it and it is command-line based, so in the end I tried and am happy with Gens, which can be obtained at PlayDeb2.

My beloved Commodore AMIGA 500 still works nicely, but floppy disk loading times and the like are tiring, so I also play this great computer via emulation. Especifically, using FS-UAE + FS-UAE Launcher. A few notes/tips also here:

  • RTFM. There are many options and some "flows" are really clunky, like disk swapping (you need to "multi-select" all disks to be able to F12 and switch them, but the UI doesn't mentions this anywhere). The documentation is almost a mandatory read in this case
  • To run anything you need the desired AMIGA firmwares (e.g. I needed Amiga 500 one). In this case there are even official commercial compilations of AMIGA software which include them
  • To run Workbench tools you need AMIGA Workbench, and to run hard disk programs you need to first create an AMIGA hard drive (via the configuration)
  • Combining that the AMIGA was prone to give Guru meditation errors either with cheats or with obscure unrecoverable errors, plus other mysterious hangups that make my whole Ubuntu freeze to death once or twice while running in fullscreen, this is the only emulator that didn't felt 100% stable. Still, in general works nicely and I'm not entirely sure it is not due to my graphics card, as in windowed or borderless maximized window I had no such issues.

And finally, to play old MS-DOS games either not available at Good Old Games or that I already own, nothing beats the great DOSBox, which can for example be found at Ubuntu Software Center. This is a generic operating system virtualization so each game might need individual tweaks, but many work perfectly out of the box.

One thing that I haven't tried yet is Playstation/PSX emulation. PS2 is still not 100% emulated under Windows so I don't even care, but I have pending to check for Linux PSX emulators, there should be something decent already...

Once setup, all this software works nicely, but it is not an easy task (at least not without this post summarizing it ;). There is a great all-in-one solution that I tried, RetroArch. It is a multi-emulator GUI-software-thingy that supports plugins to run many many systems, from legacy ones to really recent stuff like Wii's Dolphin emu. The reason I wasn't convinced by it is that at least when I tried it a few months ago, the Linux build was unstable and only worked with some systems. Windows build looked way more robust (I tested it) but as wasn't my plan uninstalled. It is the base system used at the RetroPie distribution, so the distro is correctly setup and already contains many basic features I probably missed out, but it wasn't as trivial as I thought.

My laptop is an old 2012 Dell XPS but runs perfectly the systems mentioned above. I know a Raspberry Pi can even run now Neo-Geo games at a decent framerate so one day I'll get one, but my two main reasons for waiting are a) I wanted to do this learning experience before grabbing a quick'n easy solution, and b) I still want to wait a bit further until commodity hardware evolves and runs more powerful machines like the PSX or GBA without frame skipping (probably something like a Raspberry pi 4 will do).

Hope this list helped you out!


Previous entries