1. 55

  2. 41

    Well I’m thoroughly impressed. Not just at the reverse engineering, but also your ability to expose one of my biggest gripes with tech’s hiring practices.

    “Great job showcasing all the necessary skills and techniques that we use on our day-to-day job. Awesome work. Can you reverse this linked list?”

    1. 25

      Exactly. I interviewed at Google back in 2011 or 2012. Maybe it’s different now, but there were no questions about fit, personality, drive, or what you wanted to do with your career. There were no questions about my past work or anything like that. It was an all-day on-site series of gotcha questions.

      (My favorite was “you’re trying to unmount an external drive on Linux and you can’t, why?” I ran through everything I could think of and after an hour got to “the umount binary is on the disk you’re unmounting.”)

      (That or, I was asked how you would measure latency between two systems. I said “ping.” The interviewer just stared at me, so I kept talking. “Lots of pings averaged over time and throw out or explain any outliers.” Kept staring. This sort of thing for an hour.)

      The whole experience really turned me off of Google, honestly. I was expected to just sit and have questions barked at me for hours because by God I should want nothing more than to work for Google.

      1. 8

        I interviewed at Google last year and had a great time with the on-site (Zurich). There were no trick questions, I think they stopped doing those years ago.

        The typical question was something reasonably simple algorithmically, that then turned out to contain a lot of details you could delve into as time allowed.

        I rather liked that the focus was on showing your enjoyment in solving problems.

        1. 6

          I had a similar experience in 2013/2014. Screener full of questions with lots of gotchas and edge cases (syscalls, what data structures don’t guarantee log n, what component is not in a passwd entry, …), even a sudden “quick, what’s 2^24?”. Remote technical interview was an hour with a shared google doc writing C (have fun indenting while keeping your sanity) with a phone to my ear to the interviewer. Offered an on-site interview but evolving home situation meant I couldn’t proceed. I’m very, very thankful for that now.

          1. 3

            the umount binary is on the disk you’re unmounting.

            Weird. I don’t see why this could be a limitation. Disks can be unmounted with the umount(2) syscall, and a process using this syscall doesn’t have to be tied to its executable file (just like any other process), right?

            (I know this is a bit off-topic)

            1. 5

              The executable would be opened and resident, holding a reference to the mount.

              1. 3

                Oh I see. From the Linux man pages:

                       MNT_FORCE (since Linux 2.1.116)
                              [...] If, after aborting requests, some processes still have active
                              references to the filesystem, the unmount will still fail.

                It’s probably a Linux-specific limitation. I just tried it on OpenBSD and MNT_FORCE unmounts the filesystem in anyway (processes started from the unmounted filesystem keep running). It fails without MNT_FORCE though.

                1. 2

                  I’m surprised OpenBSD is okay with it. I wonder if it has to do with OpenBSD’s umount being statically linked. Linux holds an open reference to the executing file for demand-loading/page-sharing purposes (I’m pretty sure most recent versions of Solaris and other Unices do too), and will block attempts to write to an executing file with ETXTBSY to prevent you from modifying a running file. That open reference to the executable prevents the umount from happening.

                  Interestingly, I just ran an experiment and Linux doesn’t prevent you from writing to open shared objects that aren’t being directly executed (that is, dynamically linked libraries). So, I can start a process foo linked to libfoo and while I can’t write to foo, I can write to libfoo and cause a SIGBUS/SIGILL/whatever when foo loads that code.

                  That’s interesting.

                  EDIT: I guess it makes sense because you can dynamically load modules via dlsym or whatever and you would want to pick up changes in that case. It’s still interesting though.

                  1. 1

                    Linux holds an open reference to the executing file for demand-loading/page-sharing purposes

                    Oooh, you mean Linux reads executable sections from the disk on demand? I didn’t know this! Locking the file makes sense in this case. I think it also makes sense that OpenBSD doesn’t do it given OpenBSD’s emphasis on simplicity and security.

                    1. 2

                      It’s not that Linux reads executables on demand, it’s that executable pages can be read back from disk if those pages end up being paged out due to memory pressure.

                      (IIRC, I’m at game night and waiting for my turn to come up.)

              2. 1

                I’d think once the binary is executing and in memory… Maybe the filesystem shows it open thus the disk is busy?

                Note: I should reload the page before replying

              3. 2

                My interview experience was pretty bad back in 2016, too. No more trick questions, but I wasn’t a “culture fit” lol

              4. 1

                Why do people always use reversing a linked list as an example? Google usually asked about graphs… If anybody can’t reverse a linked list then I doubt they’ve done much coding, right?

              5. [Comment removed by author]

                1. 9

                  I think that was kinda the point.

                2. 1

                  On the philosophical side: the guy thinks that anyone who passes all the obstacles is genius, he thinks himself is not a genius, so he didn’t get it. Seems pretty self-consistent to me.

                  1. 1

                    Always fun to read about reverse engineering efforts.