Over the past five years I have conducted 750+ interviews and directly reviewed 10,000+ more. Through that I made observations with the hiring process, common candidate pitfalls, and possible improvements and optimizations we can make to our hiring processes.
The result is a series all about hiring and being hired for software engineering positions. The perspective from both sides of the table is analyzed: how can we as hiring managers improve our processes to more accurately assess candidates in order to build the best team possible? Likewise, how can we as candidates navigate the minefield of technical interviews to come out on top with the limited visibility we have into the process we find ourselves in?
- The Principles of an Effective Hiring Process
- What Are You Assessing Your Candidates For?
- Don’t Make Me Write Code on a Whiteboard
- What is Cultural Fit?
In November 2014 I found myself on Estes Rockets’ website looking at their Black Friday sale. The only experience I had with model rockets was from a weekend at summer camp over a decade prior. But with the prices of some low power kits at $4 I figured building them could be a fun rainy weekend activity. A week and $30 later a box full of six rockets came in the mail and then proceeded to collect dust in my closet until one uneventful weekend in May when I decided to at least open the package. I had foolishly underestimated the amount of time it takes to assemble even a simple low power rocket (my vision of building all of them in a single evening was not realistic), but the next weekend I headed down to the local park with the assembled rockets, a pack of motors, and a launch pad I made out of PVC pipe. It was fun, I thought, but launching small rockets 500ft up doesn’t hold one’s attention for very long. That’s when I discovered the world of high power rocketry and an active community in my city. After attending a few meetings with the local NAR club, I loaded up my car and headed out to the last high power launch of the season with the intention of getting a level 1 high power rocketry certification. Being my first high power launch, I was not expecting just how high and far downrange these rockets can go. Despite seeing my rocket come down I misjudged how far out it was and spent the remainder of the afternoon wandering around a field full of mud, thick brush, and mosquitoes that I would not want to spend ten minutes walking through. Long story short, I did eventually recover the rocket, but I had plenty of time to think about how I was never again launching a rocket without a tracking system installed.
Over two years have passed since I’ve done any significant development on my encrypted chat program, Cryptully. In that time, a few issues with it have arisen and some issues were left outstanding from when development ramped down. Some of the larger items that needed to be addressed were:
- Most severe: The SMP MITM attack detection implementation was ironically vulnerable to MITM attacks.
- The hard coded DH prime was not uniquely generated.
- The tests have been failing for over two years.
- There was no way to for the server to determine what version of the program a client was running.
- The documentation for running and building the program had become out of date.
I have never gone back to a project after such a long period of time to fix bugs and add new features. Overall, I was pleasantly surprised at how well the code had aged after being neglected for two years. That is, everything still worked with the most recent versions of the libraries and frameworks I used and there were only a few spots where I wondered what the hell I was thinking when I wrote that code. However, there were a few challenges in fixing some of the long standing issues outlined above.
As I was working my way through the chapter on memory management in Understanding the Linux Kernel I thought it would be fun to try to write a program that translates a virtual memory address to a physical address. Moreover, I wanted to do it user space. And to go one step further, why not try to get the physical address of a buffer, go to that location in memory, modify it, and then see the changes by using the virtual address.
WARNING: I am far from a kernel expert. Everything here is me just documenting my experimentation with the kernel. It is very likely that mistakes and incorrect information are present. Please email me with any corrections.
There are a few problems with trying to accomplish this task in user space:
- The idea behind virtual memory is to provide an address space of contiguous memory. The memory for a process is most likely stored in non-contiguous blocks.
- There’s no guarentee that a page is even in the physical memory of the system. It could be in the swap or in a cache somewhere. There could be no physical address to get!
- For obvious security reasons, a process does not have access to the raw memory of the system, even if the process’s UID is 0.
There’s two approaches we can take to get the physical address:
- Add a syscall to the kernel that, given a virtual address, will return the physical address. However, modifying the kernel breaks the rule of doing everything from user space so we have to rule this out.
- Use the pagemap file for a process (added in kernel 2.6.25) to get the frame a page is mapped to and then use that to seek into
/dev/memand modify the buffer there.
Using this approach, it’s entirely possible to translate a virtual address to a physical address in user space. However, verfying our translation is correct requires reading
/dev/mem. This does require one small modifcation to the kernel (changing a config option), but more on that later.
As of August 2014, WebRTC is still a new and untamed beast. As such, I found that there is a lack of simple and easy to understand examples for someone getting started with WebRTC. My goal was to create my own, as simple as possible, proof of concept WebRTC video conference page that achieved the following goals:
- 1-to-1 video chat
- Pure WebRTC; no external libraries
- Works in current versions of Firefox and Chrome
Before getting into the actual WebRTC APIs, it’s best to understand a simple signaling server. For those unaware, WebRTC requires that peers exchange information on how to connect to one another before the actual connection can be begin. However, this exact method is left up to the developer. It could be anything from a very complicated server to peers emailing one another. For my purpose, I chose to write a short and sweet Node.js server that communicates with clients via websockets.
Note: The full example is available on GitHub. As WebRTC evolves the content on this page may become out of date. See the GitHub repo for the most up to date example.