Readit NewsI haven't tried pair programming. It sounds miserable. I figure I'd end up paired with one of those people that can't stand to see you looking for something. You know the type: you're looking through cabinets for something and they demand you tell them what and they demand you go directly to the right place. Sure, I'm looking for something, but I'm also learning where other things are.
Then, you simply use a screen sharing tool to share and collaborate on a code editor on each of your primary screens. We used to use Screenhero for this before they got bought out by Slack, but another tool that works well is something like Tuple.app or Drovio.
The beauty of this approach is that each person can "check out" temporarily and do research and look up stuff or check messages on their secondary monitor (without the other person seeing it), but they can easily move their mouse back over to their primary monitor and re-join in on the pair programming.
It makes pair programming a lot more tolerable, and gives you the ability to collaborate, while still having some flexibility and autonomy.
This also works well in both local and remote pairing sessions.
RubyMine, and the "jump to definition" feature in particular, is the primary thing that enabled me to really "get" Ruby and finally understand how everything worked together.
It totally makes sense though!
My two cents, the interviews here are going to help them assess how you work your way through problems, how you think and process, and how you communicate. That is a very valuable signal to get out of someone you're potentially going to be in the trenches collaborating with. That is the true value behind these route sets of challenges, much more son than "can this person code?"
We've hired engineers that have been absolutely amazing teammates in our department that on paper have had wonky technical interview questions, but it was because of the attitude and their approach in the moment that won us over.
They know you can code, they can see the OSS. The "hoops" here are for the intangibles.
I've also had candidates that utterly bombed their interviews, but we gave them a chance and they turned out to be some of the best employees we ever had.
Unless someone's daily job is going to actually be writing leet puzzle code all day, leet puzzle code tests don't tell you all that much about how someone can actually perform their job, especially when under the pressure of a stressful interview environment.
I'm at a point now where I firmly believe that what all these leet code tests are actually about is GATEKEEPING. It's about making devs feel smug about themselves as they administer the test to the candidate, and it's about inflating their own egos. It's basically just a form of hazing. After all, anyone can ace those puzzles if they study them beforehand. You might as well be hiring them based off of whether or not they can solve a Rubik's cube.
So I stopped doing those types of interviews. I have a "gut check" conversation with the dev to get a rough sense of their skill level, and then I might hire them on a contract basis to do REAL work on my projects. If I like their work, I might hire them full time. It's the ONLY REAL way to find out how someone actually works, and whether or not you get along with them.
The iPad is locked down and has a ton of educational apps on it, but the main thing he does on there is watch Youtube Kids or play Minecraft (using an Xbox controller with a bluetooth connection to the iPad).
His Youtube Kids account is locked down to mostly educational content only, with the content restrictions set to 2-4 years old. When I had it set to the 5-7 age range, Youtube kept showing him a lot of inappropriate videos.
He knows how to use the search feature to find videos about just about any topic. I might have a conversation with him about quantum mechanics and then later in the day I will catch him watching a bunch of videos about the topic. He is obsessed with outer space and black holes. He will binge on low quality entertainment like my little pony for a while, and then he will watch some educational videos about math, and then he will switch over to some Kurzgesagt educational videos about outer space or something, and then he might switch to magic school bus.
Any time I see something that I don't like on Youtube kids (like Ryan toys review), I will block the video (or the entire channel). I probably have 30 different channels blocked on Youtube Kids.
I don't know if I'm doing the right thing by letting him watch so much content, but I can definitely say that he knows waaayyy more about the world than I ever did at his age, and he is also a voraciously curious self-educator. He loves math, mainly due to the Number Blocks TV show, for example.
From the company point of view that might make sense if they don't think about the consequences. But for the person, since we all know that usually any such projects are silently rejected without explanation it's totally not worth the effort.
Having been on the inside watching some people review take-home projects and arbitrarily reject them for the most random reasons ("I don't like the way he writes comments, what a loser") I also have zero faith on them being evaluated fairly.
The only way I'd ever consider doing any kind of endurance project for an interview is if the company guarantees results if I put in the effort. Could be something like: Write code to interact with and/or provide these well-documented APIs, it'll be run against a test suite where I can see the results and it needs to meet xyz performance criteria and if you can deliver it in X hours or less we guarantee a competitive offer. Only then would it be worth the work.
But to spend a lot of time just to be ghosted? Big no to that.
Companies should be hiring people on a contract basis to perform REAL WORK. This work should ideally be the very type of work they would be doing if they were hired full time.
If they do a good job, then great! Hire them on full time.
If they don't do a good job, but they meet the acceptance criteria of the contract, then they get paid, but don't get hired full time.
If they don't complete the contract requirements, then they don't get paid at all.
This arrangement is completely fair to both parties, and doesn't waste anyone's time. It's a win/win scenario.
Unfortunately, most companies are too lazy to set up a hiring process that looks like this.