One of the points of technical interviews is to find out how someone solves a problem. Usually that problem is one that the interviewer knows the solution to and wants to see the interviewee arrive at a similar (or perhaps, more impressive) solution. This means the interviewer, under the auspices of pairing with the interviewee, basically sits back, evaluates, and trys to prod the interviewee forward rather than interacting with them in a normal way.

This is clearly not a great way for either side to find out how the other solves a tricky problem. For one, if you as the interviewer happen to select a problem the interviewee has already seen (or something very familiar), you may not get a great picture. Or if you select a problem they are incredibly unfamiliar with, you may mostly be unimpressed by the lack of familiarity with the context of a problem rather than the actual way they think.

One of the best ways I’ve ever gotten to know people over a couple of hours is at a meetup for board gaming. By the end of the first night, I could identify some really clear patterns about what people do in various problems. Even though interviewing might be a more stressful time, it occurs to me that after a few rounds, relaxation would set in and a good evaluation could be had.

Game Type #1: Pandemic / Forbidden Island / Forbidden Desert

These three games all have similar dynamics and would be useful for determining how someone handled potentially stressful situations with lots of possible solutions and trade-offs. It would also be great to see how much someone listened to another person’s input vs. trying to control the situation themselves.

Game Type #2: Hanabi

A fantastic Cooperative game that’s all about communication. You can’t see your own cards, and you have a very limited amount of information you can exchange before you are forced to start losing cards and reducing your abilityto succeed in the game.

Ideas for evaluation

I think there are a lot of variations that could be tried to see what they told you about the person you’re trying to evaluate. Some include:

• What happens when a player tries to take over?
• What happens when a player disengages?
• What happens when a player makes a clearly bad decision?
• What happens as the game progresses and frustration / stress increases?

In the end, I think it would be clear that winning or losing the game wouldn’t be the criteria for evaluating, but how the game was played. Since the interviewer and the interviewee are both on the same side, it makes it even more clear.

For the last 3 years I’ve worked full-time remote from home in my lovely Cloffice. I find working from home to be a relatively rewarding experience and I find that I am still able to get a lot done (even with 4 home-schooled kids around).

Along the way I’ve learned some life hacks to working better with a 15 second commute.

1. Work when you’re effective One of the biggest benefits of working from home is that you have a lot more control over your hours. If you work best at 5am, you don’t have to wake up at 3:30 to get ready and get going. If you work best at 9pm, you can still have a life and not be looked down upon for not being in your office chair from 9-5. Figure out when you work best and then work those hours.
2. Have lunch away from your desk (with your family if you have one) I have lunch with my kids nearly every day. Sometimes I have meetings during that time and have to eat at my desk, but those are the exception and not the rule.
3. Get dressed, have a shower. There’s some powerful psychology at work when you dress well even though you could be on an important conference call in Pajama bottoms. Showering and getting dressed does some positive things for your psyche and cues you in for the day.
4. Let your family interrupt you (but have an indicator for when they should try not to) You are working from your home. Your family is there and loves you (much more than your coworkers, in all likelihood) – spend time with them. When your kids ask you for 5 minutes of your time… give it. When your spouse needs something done, do it. Enjoy that time. But also, when you need focused time, have a signal that is clear to them (a closed door, headphones on, a sign on your wall, etc) that they can see and not be rejected by you. Let them see that you need time to focus and then make the call to determine how important what they need is. This requires some mutual cooperation, but can be very rewarding if you can strike the balance.
5. Don’t read e-mail first. It’s tempting to read your e-mail first to slide into the day… but if you can resist it, start with a difficult task and move on from there. E-mail will still be there, but if every day is eaten up by the tyrrany of the urgent, you’ll never get anything done.

There are lots of things you can do to your developers to make them better. You can send them to conferences, you can review their code, you can let them pair with co-workers and peers, you can give them hard problems that require creative thinking.

You can also let them in on the business side of things.

When you let your developers help make business decisions, they not only become better developers, they also become more valuable to the organization and more able to make solid, trustworthy decisions.

Of course, this means that you simply must continue to empower your devs to actually make decisions.

• Let them deploy when they believe a feature is ready.
• Give them permission to design and spec features.
• Permit them to talk to the stakeholders

Most of what you are doing is giving them freedom to fail. When you do that, you’re creating an environment where they don’t rely on safety nets to catch them, but rather, focus on doing a great job top to bottom themselves.

This is absolutely invaluable.

Does that mean you don’t ever give them feedback? No. Let features be designed by your designers. Let your PMs approve features. Let your QA engineers reject stuff. But never chastize your devs for taking initiative and trying to put forth a best effort. It’s important for the developer and your organization.

After a few weeks of working on the Ergodox, I’ve finally found what I believe is an ideal layout.

But that’s for me. You’ll be different. You’ll think of things differently. You’ll have different needs. You’ll hate where my spacebar is, or my curly braces… and that’s exactly what the Ergodox is for.

It’s not only ergonomic in the sense that you do not strain your fingers to reach keys around them, but it is also ergonomic in the sense that you can place keys where they make sense. You could literally come up with your own keyboard format–though I certainly wouldn’t suggest it.

So how do you go about figuring out your best layout? First, you have to know what keys you use the most and what keys you want access to.

Back in August, I ordered an Ergodox from MassDrop - Cherry MX Blues, an aluminium top plate, and hardware programmable keyboarding was in my future.

It took a long time for it to get here. Plagued by problems in their supplychain, MassDrop finally got all the pieces together around December, and shipped them off to be assembled for those of us who didn’t want to try their hand at sauldering. It finally showed up on my doorstep last week–though I was so excited that I met the UPS guy in my driveway.

I’m typing on it now. But I didn’t at first. The keys were in such radically different positioning that I couldn’t properly strike the keys. For about 48 hours I could barely type at all. I wondered if I’d made the right choice.

I took a bit of time and kept working. Things were getting slightly easier, but I still was below 70% of my former speed. I decided to try to “get work done” on my second day and just go back to my laptop keyboard. Of course, my fingers had already begun to adjust to the new keyboard layout, and so I couldn’t type on that either. It was a serious wakeup call that I’d basically set out to reprogram my own wetware and become dependent on this thing. Here’s hoping that it’s the last keyboard I buy :)

But after a few days I got very proficient. I’m even faster at using this keyboard as an alternative to a mouse because I almost never have to pick my hands up off the home rows. The fact that it has layers and thumb keys made a huge difference.

So I finally settled on a layout.

There are several things about this layout that I absolutely love:

• The "[", "]", "{", "}" keys are in a similar place, and more reachable. It currently takes a bit longer to think about the fact that I have to “toggle” level 1, but I expect that to go away quickly.
• The up, down, left, and right navigation keys are on level 1 directly over the H, J, K and L keys. This allows me to use vim-like movement in any program simply by toggingling the layer with my left or right thumb.
• Having the LGUI / CMD key under my left thumb makes it so that it is used by the same finger, but in a much more accessible spot.
• I cannot type with backspace in the upper right anymore. Taking your hand off home row to backspace as much as I do is nonsense.
• The two keys that are above the main thumb keys are pretty useless, but I find them fairly useful for volume and for combining with other keys (I have the alt above the command key so that I can do command-alt easily)
• I thought I would miss Caps lock being mapped as CTRL, but now, since CTRL is under my thumb, having escape there is great.
• I use the (mostly worthess for typing) inner keys to navigate through the layers. Cycles fairly nicely.
• The bottom rows are mostly useless, but I like having a place for seldom-used keys that doesn’t mean a big arm movement.

All in all, so far I’m loving it. I’m back up to about 90% of my previous speed, but my hands are much more comfortable and I do not have any wrist strain or numbness.

Next step is to tent these slightly and to try to figure out the best positioning for my trackpad. Great investment and totally worth it. Try one if you ever get the chance… but know that it will take quite a while to get used to!

Last weekend I participated in the Global Day of Code Retreat here in Austin. I was impressed at the diveristy of participants, the overall good nature of those there, and what I was able to learn even while pairing with relative beginners.

When I got there, there were 3 women and 3 men in the room. By the end of the day there were about 6 women and 10 men. At least 6 of the participants grew up in foreign countries. It was, for a computer meetup on a Saturday, a fairly diverse crowd. I was impressed.

We started off by pairing on the Conway’s Game of Life problem. Initially we did no tests (intentionally) and just cowboy coded it. We got pretty far, but it was difficult to verify results by hand. We ended up spending a lot of time figuring out how to display the board. We progressed through several exercises: No loops, 5 lines of code limit, tests-first, no objects, and behavior/rules oriented approaches. Every exercise had some level of frustration, but they were all enjoyable and I learned a lot.

By far, the most frustrating part of the day was having to delete your code. I did so, but I was surprised at how attached I became to a set of code in 45 minutes. How much more likely am I to become attached to an implementation I’ve worked on for 3 weeks?

I also learned a lot from doing the “no objects” exercise. It was incredible how fast we were able to implement once constructing objects was out of the way. I was amazed at how much it pointed me toward Functional programming paradigms like filters, etc. And it made it much easier to see what kind of object to create rather than coming up with some idea of what should be before you created it. When I got home I CMD-Z’d my way back to this exercise and examined and refactored it. I know that’s against the spirit, but I really enjoyed it and learned a lot from it.

All in all, a great day. Good food and good fun and good learning. Hope to do a virtual code retreat sometime soon either with coworkers or random pair partners.

Pairing is hard, but to me, the hardest part about remote pairing is not technology or even logistics, it’s collaboration and problem solving together. To that end, there are multiple pairing styles that are worth looking at when you’re trying to pair with someone knew. Each style facilitates collaboration differently and knowing how they work helps.

Driver / Navigator

Fundamental Idea One partner “drives” at the keyboard, focusing on implementing. The other partner “navigates” verbally, focusing on big ideas, questions, typos, and conventions.

Strengths

• Great for “unequal” pairing partners / mentoring (let the less experienced ‘drive’)
• Let’s someone with a highly customized environment work effectively without inhibiting the navigator
• Great for “thinking through” big problems you’re solving.
• Easy tech setup, can just use screen share.

Weaknesses

• Can lend itself toward one partner becoming less engaged (Driver is only copying what is said, Navigator stops talking)
• Equal partners may desire more “take turns” kind of approach
• Driver learns less tech, navigator learns less theory/big ideas
• Weaker on TDD, small problems, repetitive solutions

Trade off / Taking Turns

Fundamental Idea Partners take turns driving and navigating, perhaps with a 15-20 minute timer.

Strengths

• Both partners get to learn tech and think about big ideas
• Keeps both partners engaged
• Great for partners of similar skill levels
• Still good for thinking through problems
• Can sync code via git to allow for current driver to use their own environment.

Weaknesses

• Hard if host environment is unfamiliar for either pair
• Harder to “mentor”, but still a viable option

Ping-pong

Fundamental Idea Partners take turns by making all tests pass, writing a failing spec and passing control to the other partner.

Strengths

• Great for exercises
• Keeps both partners engaged
• OK for mentoring or more equal pairing

Weaknesses

• Really difficult in unfamiliar environment
• Nearly requires a terminal sharing/buffer sharing style of pairing
• Bad for big problems, communication is most effective through tests, easy to psych yourself out otherwise.

Conclusion

Which pair style you pick will be up to you and your pairing partner, but it’s worth considering what kind of problem you have and what your relationship is with your partner. My general rule of thumb is, for small exercises, do Ping-Pong pairing. For real world problems with unequal skill levels, do Driver-Navigator with the less experienced person driving. For real world problems with equal skill levels, trade off to keep things interesting. YMMV.

As developers, we have a tension that we almost always deal with, the tension between writing the best possible solution and the fastest possible solution. Usually we end up somewhere between them, sacrificing a bit of quality for speed. I’ve yet to hear of a developer that would say they sacrificed a bit of speed for quality–but isn’t that what we want to do?

For myself, I’ve always struggled with this balance. What we want is to continually improve quality and deliver features quickly and readily. Can we do both?

I think we can, but it still requires discipline. How many times have you been able to begin a project, full of hope in it’s future quality, only to find yourself skipping tests and throwing around bad naming practices just to get something out on time? I know that’s happend countless times for me.

So what discipline does it require? I think we can learn a bit from the construction industry. We often throw about the metaphor of a “foundation” to build upon. Usually we’re refering to the framework or other technologies–our app is the bricks and mortar, wood and drywall. But what you see with each step of building a house is that the “foundation” that is currently in place is allowed time to firm up and be solid before building on top if it. The slab exists and is completely hardened before you add your frame. Your frame is complete before you add drywall or a roof. Your drywall is complete before you paint. There’s plumbing and electric that has to be thrown in all along the way, and then there are finishing touches that need the entire structure to be “complete.”

For us, that means building up and firming up a data model before you allow it to be built on top of. As you build, it still may require small changes, but what we must recognize is that a small change threatens everything built on top of it. The more stable your foundation the more confident you’ll be in building on top of it.

So my idea here is that when you are heading toward quality, focus on firming. When you’re focused on delivering, build on top of what’s firm – if it’s not firm, push back and say “guys, this isn’t firm enough for us to be building features on yet. Let’s spend time letting it firm up.”

There are lots of skills a developer has to have, but one of the ones you really need to have if you ever want to make a living is being able to interview well. There are lots of things that make interviewing a challenge, but if you interview well you’ll learn something at the least and get a job offer at the most.

Let’s talk about how to interview well.

1. Be Brutally Honest

While I’m sure you can lose job opportunities by being honest, you can’t really lose the right job opportunities by being honest. If you don’t know something, just say it. If you know something you’re not good at, point it out. If you know something you are good at, point that out too, but don’t oversell yourself. Be confident in the fact that you are worth being hired even if you’re far from perfect. They aren’t either.

2. Be Sincerely Humble

If someone asks you how you’d rank yourself in a technology like Javascript on a scale from 1-10, take the number you think you might be at and ratchet it down. Anyone who is interviewing with me and says they are a 9 or a 10 on anything needs to be writing books or conducting classes on the topic. You might be a 9 or a 10, but in all likelihood you’re average or below average in most technologies you work with. Give an honest and humble perspective of yourself–this sets expecations later when they drill you about escoteric things a 9 or a 10 should know.

3. Be Enthusiastic

Come to an interview with lots of enthusiasm. Be yourself–you don’t have to fake it. Just find things you’re excited about and show that through your body language and the way you speak. Listen well, engage people, talk and ask lots of questions. Questions show curiosity and who doesn’t like to be thought of as interesting?

4. This is a Two Way Street

You’re interviewing them as much as they’re interviewing you. You want to know what kind of company they are, what culture they have, and what issues they have as a team. They’re trying to size you up, but you should be sizing up the company too. How do they make decisions? How do they deal with conflict? How do they organize code? How do they work on a day to day basis? What can you expect if you show up on day one? What about day 31? What about day 301?

Sometimes you can’t ask these questions directly because they are hard to answer. If you can ask to come into the office and pair program with someone or sit in on a few meetings, that will give a great bit of insight into how an organization works. You might not be allowed to do these things, but it never hurts to ask. Also, consider what an organization that says “no, you can’t pair program with us before committing” is really saying. Maybe it’s security, but maybe it’s just a lack of transparancy? Consider what an organization says by it’s actions and policies.

5. Try to learn something

From every single interview you’re in, you have an opportunity to learn something. You can learn how another organization manages their code review process or how another developer does some trick in VIM. In this respect interviewing can be beneficial to your current employer. Even interviewing with companies that you don’t have much interest in can give you general information that is hard to obtain otherwise (and I’m not talking about proprietary information). You can get a sense of the technologies some other companies are trying to use and how they use it. You can also get ideas about processes you can take with you to any other employer. How do they do scrum? How does she handle conflict in the team? How do they code review? How have they tried to maintain culture while they’re growing?

6. Interview while you’re employed

This last one is much more circumstancial, so if you’re not employed at the moment, you might not be able to do anything about this. If you are employed, make sure you continue to interview! I try to keep my ear to the ground and interview at least once a quarter with another company. Because I’m always trying to learn something, this usually becomes beneficial to my current employer, but it is almost always beneficial to me.

Beyond that, if you don’t need a job it’s much easier to be very honest and make sure the new gig would really be a good fit. It’s also much easier to negotiate a better situation when you’re already in a good one. Don’t wait until your current job is in bad shape before you start interviewing elsewhere.

Conclusion

Interviewing well is a great skill. The more you practice it the better you’ll become and the more opportunities you’ll have. Remembering that a successful interview does not necessarily mean you get a job makes a big difference. Look at every interview as an exploration of future opportunities. Some doors will open and others will close, but you can learn stuff either way.

A New Way to Level Up?

A few weeks ago at LSRC, Katrina Owen mentioned exercism.io as a site she set up for people to go learn new things, get feedback and head toward better code.

I was intrigued. I have always loved small, easily finishable exercises that allowed me to think about things OTHER than the exercise itself. I tried a few and quickly became hooked.

But the thing that really surprised me was not just how hooked I was on leveling up on the exercises, but how hooked I was on reading other people’s code and providing feedback on it. It was fascinating to see how many different ways someone else solved the same little problem. Little differences like naming to big differences like Functional vs. OO approaches to problems become easy to evaluate. It also becomes clear where certain solutions shine and where they don’t.

Room for improvement

There are a few little things that it struggles with. This is not meant as a tear down, but rather as a recognition of the limitations of the system and ways it could improve.

It’s easy for the “one true solution” to be cargo culted down. Instead of giving feedback and trying to nudge their solution toward something slightly better, it’s much easier to just try to nudge them toward your solution. There isn’t a great way around this, it seems, since you’re talking about how people work by default.

There’s also the feedback problem. You can give feedback to anyone who has submitted an exercise you’ve already had approved, which means that as you progress, there are fewer and fewer people evaluating your exercise. The point is the feedback more than the solution, so little feedback causes you to disengage from the site over time. This is solvable by getting the experts to focus first on the latest exercises and getting more experts involved overall. It’s still hard, though.

Finally, as the UI expands, it is becoming clear that it’s hard to do UI for programmers. They all want to look at data 1000 different ways but UI is about compromise and saying no most of the time. This is a piddly detail, though in the grand scheme of things.

But filling a void

But it is great at what it does.

• It gives you direct, real experience on programming languages (that you may or may not know yet) with experts looking at and evaluating your solution.
• It gives you the ability to look at and evaluate other people’s code. This makes you more open and better at solving problems
• It gets you thinking about refactoring in a much bigger way. Refactoring in the small leads to refactoring in the large, though it’s still a hard transition.

I am very impressed with the niche that it does fill already. I hope some of the kinks get ironed out and that Exercism is around in a few years as the de facto way to learn a new language, level up in a language you already know, or help newbies out. Can’t wait to see how it pans out.