Failed a Rails interview because of NixOS, what should I have done differently?

Help
1

I run NixOS as my daily driver. Failed a live coding interview for a Rails position. Not because of code but because I couldn’t get their app running in time.

The situation:

  • Asked company to sent a Gemfile beforehand to prepare. Actual project Gemfile didn’t match with minor difference.
  • Project included a Dockerfile, but it was broken: missing system deps, hardcoded localhost URLs, no docker-compose for Postgres/Redis, invalid Bundler platform. (probably was never suppose to be used)
  • Communicated before the interview that I can’t install natively due to my OS. Interviewer watched the build fail, left for 50 minutes with task (part of the interview process).
  • Spent the entire session debugging their environment instead of writing features (but still wrote some code).
  • Submitted a working Docker fix + full patch after. Company declined a redo (Interviewer aknowledge the problem and told I need a second try).

I got very frustrated after, and started to research flake.nix per project worked well before but ruby-3.1.2 is no longer in nixpkgs. And I managed it to run from github:bobvanderlinden/nixpkgs-ruby.

I tried the rbenv approach in my nix config:

programs.rbenv = {
    enable = true;
    plugins = [{
        name = "ruby-build";
        src = pkgs.fetchFromGitHub {
            owner = "rbenv";
            repo = "ruby-build";
            rev = "v20260326";
            hash = "sha256-7BceEdzBf2kjzLrAZf1kbS6tGoFercH7adw8fo2uBvE=";
        };
    }];
};

but ruby install fails because:

  • No gcc in PATH Need gcc, gnumake, autoconf, pkg-config in home.packages.
  • zlib.h: No such file or directory
  • RUBY_CONFIGURE_OPTS needed - must explicitly pass --with-openssl-dir, --with-zlib-dir, --with-readline-dir, --with-libyaml-dir pointing to Nix bin in store
  • home.sessionVariables don’t help immediately - need shell restart, and setting global CFLAGS/LDFLAGS affects all builds, not just Ruby.

Even with all deps added to home.packages and sessionVariables configured, ruby-build still fights.

Working example installing it from zsh (not possible or convenient to run this each time) also not sure it will work properly switching ruby versions on different projects.

RUBY_BUILD_SKIP_OPENSSL_COMPILE=1 \
  RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(nix eval --raw nixpkgs#openssl.dev) --with-zlib-dir=$(nix eval --raw nixpkgs#zlib.dev) --with-readline-dir=$(nix eval --raw nixpkgs#readline.dev)
  --with-libyaml-dir=$(nix eval --raw nixpkgs#libyaml)" \
  CFLAGS="-I$(nix eval --raw nixpkgs#zlib.dev)/include" \
  LDFLAGS="-L$(nix eval --raw nixpkgs#zlib.out)/lib" \
  rbenv install 3.1.2

My questions for the community:

  1. How do you handle interviews/onboarding that assume apt-get/brew? Do you keep a non-NixOS VM ready? Distrobox? Docker only? Something else?
  2. Is rbenv on NixOS a lost cause? Has anyone gotten rbenv install working reliably via home-manager without a wrapper nix-shell? I have flake.nix per local project but need something for situations like that
  3. Is nixpkgs-ruby / pure Nix the only real answer? My flake with bobvanderlinden/nixpkgs-ruby works great, but it’s unfamiliar to teams expecting rbenv.
  4. Older versions are no longer supported, but still older ruby version are used widely by companies

Not looking for sympathy or say the tool genuinely not working for situations like that. I am thinking moving on from nixos as my dev machine because of the overhead it is causing and missed opportunities. Want to know if I’m doing something wrong or if this is the current state of Ruby on NixOS?

1 Like
2

If you don’t have that ready for an interview I’d probably fail you too. An organization that isn’t bought into this ecosystem and doesn’t intend to pay you to introduce them has no interest in you fiddling with flakes just to get their dev env up.

You have to be able to work with the tools they give you; if you can’t quickly spin up a fedora or ubuntu VM to get past env issues during an interview you’re not prioritizing right. You can start the nix zealotry after your probation period.

1 Like
3

The session seems to have been announced first. So it dodn’t get you cold.

In cases when I have had a planned live coding session, I prepared a VM with a bare Ubuntu + asdf and elixir plugins + my favorite editor.

At least in the elixir world, asdf is the quasi standard. Anything else I realize missing during the session is usually just an apt install away.

So far this strategy worked well enough and never caused any troubles.

And also, the big benefit is, you can even delete or reset the VM during the session and thereby assure, that no company secrets will remain on your PC by accident. Because even if there was something witin their example project, and even if it got cached anywhere on the VM, after going back to the previos restore point, anything done in the VM will just be gone.

At the same time, I would never run the companies code on my machine natively, even years ago, there have been “companies” handing out exercises that were only meant to scan for passwords, secret keys and similar and submit that to the “company” you think were just doing an interview for.

7 Likes
4

Thanks for feedback. Spinning up VM or SSH into other server not a big deal. But what is the point of using NixOS if I use another distro for dev and can’t rely on my tool? With declarative way of living like NixOS enforces, do I need to maintain deployable Ubuntu instances with all my dotfiles configs? (vim configs, zsh configs and bindings, LSPs and so on). Looking into Distrobox as middle ground - Ubuntu container that shares home dir but gives apt-get. Anyone tried this approach? But still it links into your ~/.local/bin and can override system packages from nix. The flake.nix file was fully ready and tested on same version ruby, rails, and dependencies. But failed for one new gem which I was not able to point, configure during the interview designing load balancer at the same time.

5

Good points about VM security. Session was announced but the Gemfile they sent beforehand didn’t match the actual project - so prep only went so far. The flake I built from that Gemfile worked, the
actual project had different dependencies that broke during the call. What is your VM setup looks like? Is it full UI in KVM or tty only with ssh approach?

6

During the last sessions it was just a Ubuntu with a manually configured VScode. Just enough to be able to do my coding. I used VirtualBox.

If I had to do this again, I would very likely use a headless qemu VM and use SSH + nvim on it. Today I would even install nix on it to be able ot use my preconfigured nvim. I already know that it can work in “regular” asdf based setups.

7

oh that makes a lot of sense! Having best from both worlds. So you can deploy your dot files with nix. Unfortunately I manage my XDG_CONFIG without nixos. So maybe I could just clone my xdg directory and install required packages and then just ssh and expose my ports for databases, server workers, etc… like this in ssh config:

Host interview-vm
  HostName 192.168.x.x
  LocalForward 3000 localhost:3000
  LocalForward 5432 localhost:5432
  LocalForward 6379 localhost:6379
8

For the foreseeable case of a database being required, I tend to have a copypastable docker-compose ready, that I spin up in the VM, really avoiding anything leaking outside of the VM.

9

Thanks a lot it seems like I found the answer! There is a tool called Vagrant and I can setup with it any image using ruby in a declarative way. So I will just define basic packages and can ssh to it and it also solves the problem with isolation and security. I need to do more research to make sure it fits but I have right direction, thanks!

10

I’m a bit surprised podman is not mentioned in this thread. I use podman run --rm -it --network=host debian:forky /bin/bash (as normal user) for one-shots or things I cannot get to work on NixOS,

1 Like
11

99% of the time I’m not taking interviews. During that 99% of the time, using NixOS works fine for me. Most programming I do isn’t commercial, though I’ve gotten to the point that we’re also using nix at work.

NixOS doesn’t really enforce it, there are many escape hatches. But I wouldn’t risk having issues with those escape hatches during an interview, which is why I prefer a VM for this.

You can pretty easily maintain a home-manager setup to do your vim config and such, though. I think @NobbZ approach is pretty good. That said, having a VM available seems safer to me, who knows if you need to set up some graphical VPN application or some other insane thing companies force on you.

1 Like
12

While the most important stuff has been covered here already, I’d like to add some additional points, for inspiration. Highly opinionated, of course.

Using ephemeral VMs with any “standard” os is a must have, not only for interviews. Starting with a new company they expect you to get ready to do productive work as quick as possible. I feel the urge to do it right, preferrable with nix/nixos, but that’s definitely the worst time to pick up that fight.

I got used to a very simple approach for that: One VM for every employer and interview, either running on a little proxmox server or locally using kvm/virt-manager. Based on ubuntu cloud-images with cloud-init, it configures itself and doesn’t require interactive installation. Only setting up my ssh key and docker/podman, and the vpn for employers. (I also extend my nixos config to include the new ssh host, with forwarding options for gpg, ssh-agent and a socks5 proxy, for my browser). Easy to snapshot, backup/restore and to shutdown if it’s not needed. I’m currently running 2 of these VMs, one for my employer, and one for my private projects.

The only thing I need now is vscode, with its remote-ssh and devcontainers extensions. No matter what I’ve got to do, I can quickly create a new devcontainer setup for any common language including required features (asdf, eget, gh-cli, nix, …) in an existing or blank repo to spin up any environment needed in less than 2 minutes. 100% reproducible, shareable, extensible and fully separated from anything else. With the ability to automatically install my dotfiles in every devcontainer I spin up. As soon as vscode is connected to the remote host, a socks5 proxy is listening, ready to be used by a dedicated browser profile running an extension for conditional proxy configs, allowing access to vpn-protected resources. A fully separated environment for any kind of work, seamlessly integrated into my main desktop.

This construction served me well for the past 6 years now. It’s okay if you don’t like it, if you prefer nix-shell or any other solution. I’m not trying to sell it as “the best solution” available, just showing another alternative.

2 Likes
13

I’m not in an interview since switching to NixOS as my primary OS, but I’m learning Lua and I need to use/test Luarocks for other Linux distros. My solution has been using Distrobox so I’m sure that the `.rockspec` file works without problem. In fact, I use Arch Linux over Distrobox for Lua development, so VS Codium plugins for Lua are available. So I second @NobbZ’s advice (just with a different distro in my case).

Also, regarding advocating for NixOS, I’m doing that in my institution, but slowly, as a teacher and workshop facilitator, that is less stressing that during and interview. The process is slow, but time is not against me, in that context.

1 Like
14

This isn’t a directly helpful response, but as someone who occasionally runs technical hiring processes, I find the idea that the interviewee would have to provide their own infrastructure in which to do the exercise kind of wild, precisely because debugging environment differences are not what I want to be testing in an interview. I would use one of the many existing tools for sharing a sandboxed coding environment with the interviewee – at most I’d do something like ask them to send an SSH public key ahead of time so they could log in to the VM I’ve preconfigured where they do the work.

(Part of the presumption here is that people will not be using their personal devices for the actual job, so I need to test them on their ability to work with the org’s systems, not their own.)

3 Likes