Referred by a friend, held up multiple companies that were later in the interview process to accommodate the interviews because the team was on vacation. After 2 weeks, they came back and finally scheduled an interview with me. They gave two substantial take-home projects, each described in a single paragraph of broken English. I did one and sent it off, leaving a variety of TODOs and loose ends as potential points of conversation, expecting the ordinary "Let's talk about what you did" routine.

Instead, I got an email back that said it wasn't fast enough and that they wanted me to redo it to be faster, and also that I should add options as CLI flags instead of hard-coding them, as if I didn't know this was a possibility. I asked my friend what was up and he suggested that I return a version with several new features, which I reluctantly did that night after his assurances that there was just a miscommunication but he knew I'd be great, etc.

Since the document gave no direction on what they'd like to see and since the earlier standard-demo style response got derided for being demo-like, I chose an approach and exhaustively demonstrated the tradeoffs associated with it, including a test mode that showed cases in which it was inadequate.

After several days, they replied saying that that answer was too complicated and that they wanted me to try to make one that was even faster. I called my friend's boss and said that this isn't how we do interviews and they need to tell me what they actually want. They said that I had failed the first sample by making it too complicated, but they'd be willing to let me do the second take-home "exam" -- the hiring manager literally referred to it as an exam -- and that then "discuss the first one" if I do a good, "very simple" job on it.

I would've dropped out by now if I didn't have my friend's name attached to my application, but I did, so I went on. I completed the second task the night requested and did so as simply as possible, which included making use of two external libraries. I specified in the README that these dependencies existed and needed to be installed, and that I was not bundling them in order to prevent the project from becoming cluttered and therefore perceived as non-simple.

After over a week of delays and promised discussions that never occurred, they got back to me to say that the second demo "didn't run" -- presumably because they failed to install the dependencies clearly listed in the README, which were introduced specifically because they asked for the simplest possible version -- and that they were therefore not going to proceed with an offer.

Overall, the process stretched over several weeks and was an abject waste of time. This process may work for those who are desperate or junior enough to see no problem going through several iterations of the "exams", taking guesses at what the interviewers are hoping to see, but those of us with more than one job prospect are better off avoiding the timesink. It's frustrating to get told that your code doesn't work when you know what really happened is that the interviewer ignored the README, or that your first sample isn't good enough because it didn't have enough options as CLI flags.

Note that my insider had been told that they wanted "the very best DevOps person available" for this role -- only to have the code dismissed on trivialities without any discussion around tradeoffs or respect for the fact that "the very best DevOps person available" would have something to do other than take guesses at whatever the interviewers are trying to get with oblique "make it faster" demands, as if there were a single answer to that. Don't think the experienced hire thing is going to go too well for them.

Tell us about a time you had a conflict at work? Write a Vagrantfile to spawn three interdependent systems with load-balancing as simply as possible. Ouch, we didn't tell you it had to run without any dependencies, and we didn't bother to look at the README, so you failed. Write a script to detect duplicate files across a directory tree. Can you make it faster? Can you add more CLI flags? Can you make it even faster? Oh, yes, just like you said in your email with the initial sample? OK, but don't make it faster those ways. Why don't you do this one thing that doesn't actually do what we think it does? Oh, because then you'll write a test mode to prove that it doesn't work very well? Yuck, too complicated. You failed. Can you do the Vagrant thing?