The Agape Red Interview

May 13, 2019 Life, Programming No comments ,

Anyone who knows me well has likely heard the “the difference between the GUI and the code” story. I think it’s because not only is it incredibly frustrating, but it outlines how you can be placed in a lot of different situations where someone in a position of power before you tells you you’re flat out wrong when really they either haven’t really thought about what they’re asking or they’re not educated enough to even understand the answer.

The Story

So I applied for a programming job at a place called Agape Red in Downtown Omaha. It was in the Old Market, right next to where I was living! I could literally walk out my door and within a block be at work – how cool would that be? So I head to the interview, and all seems to go pretty well until I get to the “technical question” portion.

This is where the guy interviewing me asks, “What’s the difference between the GUI and the code?” I immediately start remembering my experience designing GUIs using Netbeans and flipping back and forth between the generated code from the UI designer and the designer. Anyone who has used this before will know what I’m talking about, and non-programmers will have to simply take it on faith that a GUI is simply lines of code directing the computer how to draw lines, where to put checkboxes, and where to display whatever text at whatever coordinates.

Anyway, I’m thinking about all of these files of code and so perhaps rather obviously to me, I respond, “There is no difference. It’s all just code.” The interviewer’s face suddenly turns saddened and disappointed. “No. The GUI is where the user clicks things with their mouse and types things in. The code is the actual “code” behind the program.

Upon hearing this, I’m obviously in a complete state of shock and amusement. Being that I suffered from pretty severe anxiety at the time, I wasn’t going to cause a scene in the middle of an interview. Before I had much time to process what just happened, the guy stands up and says, “I think we’re done here.” Being a young, anxious kid and not knowing how to handle the situation, I’m led out of the building.

Later I receive a phone call from the staffing agency informing me that they weren’t interested because I didn’t seem to understand much about programming.

I think if there’s a lesson to be learned from this event, it’s that just because someone is in a position of power in a certain social setting (an interviewer, an instructor) doesn’t actually mean that they know what they’re talking about or understand really what they’re asking you. Without inflating my own ego too much, I’d like to say that it’s possible that you have more knowledge about the subject that is quite simply just beyond their understanding.

Fun & Educational IT-Related Challenges

October 28, 2017 Linux, Programming No comments

I’ve decided to compile a list of fun and educational IT challenges out there.  Any challenge on this list I have either completed, or I’m still trying to complete in my spare time 🙂

CryptopalsSolve cryptography challenges derived from weaknesses in real-world systems and modern cryptographic constructions. Use any programming language you wish.
BanditSolve Linux-related challenges as you try to find the location of the ssh key to get to the next level. Early levels are very easy, and beginner-friendly, but the difficulty ramps up as you get further into the game.

The Bash For Loop

July 15, 2017 Linux, Programming, Shell No comments

This week at work, I had been tasked to copy a directory in Linux 6 times, all with different names.

This, of course, is not that directory, but let’s pretend it is.

We want 6 copies of this, one for each employee

















Easy enough, just cp -r the directory 6 times, right?  Well, you could, but we always strive to be as clever and efficient as possible.

Let’s say for this example we need a copy of this directory for all 6 employees: David, Mark, Jeremy, Clyde, Warren, and Sam.

well, that won’t work






There’s a lot of things that surprisingly won’t work, mostly because the directories don’t exist.  We could make them, or, as my boss showed me, we could use a little for loop magic.

surprisingly simple!





Is it really all there?  Yes!  This is truncated, but you can see these users have a clone of the original directory.























So how do I use this?

Well, the items you want to iterate through go after for x in

The command you want to execute goes after do and you use the variable $x to iterate through the items.

If we wanted to create 10 files named each letter of the alphabet, we would use

for x in a b c d e f g h i j; do touch $x; done

and you will have those files.  You can remove them with an equally simple line:

for x in a b c d e f g h i j; do rm $x; done

Repulsive Java Coding Style

June 24, 2017 Programming No comments

I get that everybody has their own coding style, or that people follow different coding conventions, but I find the examples in my Data Structures book to be some of the most hideous Java I have ever seen.

awful java code style




























For the sake of comparison, here’s the converted code to what I believe to be textbook Oracle coding convention (the convention I have always followed).  The only exception is that I typically prefer to use 4 spaces instead of 8, but I’ve used both in the past.

java oracle coding convention style

Shelled-out Commands

May 20, 2017 Programming, Shell No comments

So I remember shelling out commands in Java, and it was quite a process.  It turns out it’s essentially the same for Go.

In interpreted scripting languages like python or ruby, it’s not really something you have to put any thought into.

So because bash is a shell you don’t have to do anything.


ls -l

Ruby supports backticks.

#!/usr/bin/env ruby

`ls -l`

In Python, you can call os.system()

#!/usr/bin/env python
import os

if __name__ == "__main__":
    os.system("ls -l")

So what about real programming languages? Well, there’s a little more involved to shell something out if you’re expecting the output much like an actual shell.

Using Go, I wrote this to shell out a command.

package main

import (

func main() {
    // create command and arguments
    cmd := "ls"
    args := []string { "-l" }
    command := exec.Command(cmd, args...)

    // connect to stdout and stderr
    stdOutReader, err := command.StdoutPipe()
    checkErr("Error creating stdout pipe", err)
    stdErrReader, err := command.StderrPipe()
    checkErr("Error creating stderr pipe", err)

    stdOutScanner := bufio.NewScanner(stdOutReader)
    stdErrScanner := bufio.NewScanner(stdErrReader)

    go func() {
        for stdOutScanner.Scan() {
            fmt.Printf("%s\n", stdOutScanner.Text())
    go func() {
        for stdErrScanner.Scan() {
            fmt.Printf("%s\n", stdErrScanner.Text())

    // run the command
    err = command.Start()
    checkErr("Error starting command", err)

    err = command.Wait()
    checkErr("Error waiting for command", err)

func checkErr(msg string, err error) {
    if err != nil {
        fmt.Fprintln(os.Stderr, msg, err)

Here’s the output of that program compared to ls -l






In reality, when simply using ls, we could have probably ignored stderr.  If you want stderr messages though, the code above will provide that output as well.