2021-09-26: Interviews, Building a Split Keyboard
Learning from interviews
We have interviewed quite a few people for Software Engineering role at Skit. In 2019-2020, we had a lot of applicants who were straight out of college or around 1 year of experience.
Recently, we have been interviewing a little more experienced bunch of people (around 2-6 years of experience)1 and I could see the difference in the kind of discussions I have had with them vs people with 1-2 YOE.
For new graduates, most of the discussions have been more like a checklist of questions, if they clear those, they are through. However, I try to discuss more on people’s work rather than going through a set of right or wrong questions as much as possible. This gives a better understanding of their skill as an Engineer. But in absence of hobby projects or internships, only way to evaluate some language skill is to go through a list of language proficiency questions.
I interviewed at Razorpay in late 2017 and in one of the tech rounds, the interviewer asked me to just talk about any programming language concept I want. I talked about internals of GIL in Python, how it works internally, and how its implementation has changed since Python3.2 in contrast to how it was before. I liked this discussion a lot, it was more of a learning session for both the interviewer and me, and we discussed about it for about 45 minutes. In my previous company’s (DriveU) interview, I had a 30 minutes discussion with the VP of Engineering about our vimrc files.
People like to talk about what they are passionate for, it’s a great way to assess to what depths they can go for the things they like. If they like the work we are doing at the company, we could see them replicating the same at work. This is something which I now actively try to look for irrespective of the years of experience they have.
Interviews are already a little intimidating, we don’t do any DS/Algorithm questions. Unless we start building our own database, I don’t think we need to ask how to build a B+ tree because that’s not the kind of skill we need right now. For any candidate this is the workflow I follow:
- Do a 15-20 minutes read through of the resume and projects (if shared).
- Make a list of questions I would like to discuss more on based on their
projects or current work. For example: One person had worked on an in-house
load testing framework so I was curious to discuss on:
- How did they do load simulation: concurrency, real user scenarios etc.?
- What exactly they were trying to test and monitor? correctness, response times, hardware logistics etc.
- Get on the call.
- Keep a notebook and try to create a map of their work. I try to create a basic block diagram of the projects people talk about based on their explanation and then do QnA on them to understand the hows and whys.
- A significant amount of time is spent on talking about the company, culture, the people etc.
It’s interesting to see how people’s way of approaching a problem is influenced by their current job. For example, in a hypothetical scenario to send thousands of concurrent HTTP requests in Python, some people might choose a message queue which they had recently worked with. Not commenting anything on whether it’s right or wrong. But, I feel it could be concerning if you start considering these approaches as conventions. Talking to people, and understanding the varied kind of solutions and the thought processes they have for similar problem statement, I learnt that I am also in a bubble of certain philosophies and thought process which is being influenced by the people I work with. I feel it’s important for me to go out and learn from other people’s experience more often than I do right now.
Building my own Lily58 split keyboard
I had built a mechanical keyboard early this year. More about it at: https://vipul.xyz/random/building-mechanical-keyboard/. It was more like assembling individually ordered components together: keyboard kit, key switches and keycaps. I feel I will definitely build a few mechanical keyboards in my lifetime.
This split keyboard which I am trying to build is as hardcore as it can get, getting a PCB, diodes, some Arduino stuff. TBH, I don’t know how it works, I am not an electronics person but I am learning with this. It’s a Lily58 split keyboard and I always wanted to try out a split keyboard. I might have to get used this split layout which would take some time.
I don’t have much soldering experience. Behold, my work of art.
My 10 years old speaker. Keeping it alive.
Here’s a small time lapse video of me soldering the tiniest thing ever I have worked with.
I have to do 58 of these and another 58 of a different piece. This is only the left half.
Look at the size of this diode!
Banana for scale.
It’s difficult to procure keyboard parts, I can’t even find Cherry MX key switches on online stores. I might have to use the key switches I have in my current keyboard to test this out (or look at some Chinese online store). I hope it turns out well in the end and the thing works. Either ways, I’ll make a post on how I built or messed up my split keyboard depending on how it turns out.
Some artists I like
I like the music by Josh Turner, Reina del Cid, Carson McKee and Tony Lindgren. They have collaborated a lot together and I love their original compositions. I have been following their work since 2016 and I have come across a lot of different artists because their covers and their musical influences.
I came across an OC by Reina del Cid today morning (she has collaborated with Josh on this one) called, What I’m Losing.
I like the beautiful opening chord progression and I tried to record a 30 seconds excerpt from it:
1. We don’t have hard constraints on the years of experience when we hire. If people have exhibited the skills and values we are looking for, YOE is secondary.