Interlude: A Mock Interview About Developer Workflow

TIME LIMIT: 1 HOUR

Many software companies post job descriptions like the one above. They describe their perfect dream candidate. But it’s pretty rare for programmers to ever fit so neatly into a list of buzzwords! And, in fact, many of us are driven to take jobs by the fact that we’re going to get paid to do something we’ve never done before.

Let’s take a look at how you could talk about what you’ve learned so far in this chapter in a job interview.

The Interview

The Setting: You’re in a small conference room, maybe 200 square feet, with your interviewer. There’s a table in between the two of you, and a whiteboard on the wall. One wall, facing out to the rest of the office, is made out of glass. You’re dressed in business casual.

. . .

Interviewer: Hello, great to meet you.

You: Great to meet you as well. I looked up your LinkedIn account - it says you’re a senior software engineer?

Interviewer: That’s right. Looks like you’re new to coding?

You: That’s right… but I know how to build products!

Interviewer: Really? Tell me how you would start a project.

You: From scratch?

Interviewer: Sure.

You: Do I already have a list of features to build?

Interviewer: Sure.

You: OK. To start a greenfield project, the first thing I would do is create a new folder for all of the project files. You know, the project root.

Then I would immediately place it under version control using git. I would create a remote repository on GitHub.com. I would connect that remote repo to my local repo.

Interviewer: On the command line?

You: Yes. The commands would look something like this:

  cd ~/Desktop
  mkdir PROJECT && cd PROJECT
  git init
  # Go create repo on GitHub.com
  git remote add origin GH_URL_FOR_PROJECT
  git status  

You could check what remotes repos are connected with git remote -v.

Interviewer: Sounds good. OK, so now you move onto feature building time. What would your git strategy be?

You: I would probably do my first few commits on the master branch - setting up .gitignore file and my initial file structure, etc.

After that, I would start developing the features in order of their priority. I would cut feature branches off the master branch for each set of features. As I completed coding each feature, I would merge the feature branches back into master. Finally, I would delete old feature branches just as a matter of housekeeping.

Interviewer: That’s a pretty good answer. If you were on a team, would you use pull requests and code reviews to merge code?

You: …yes…

Interviewer: Good.

Interviewer: What shell is your command line program using?

You: I use a Mac. It uses the standard Bourne Again Shell, aka “bash”.

Interviewer: Is that UNIX-like?

You: …yes…

Interviewer: What is a shell?

You: A Unix shell is a command-line interpreter or shell that provides a traditional Unix-like command line user interface. Users direct the operation of the computer by entering commands as text for a command line interpreter to execute, or by creating text scripts of one or more such commands.

Interviewer: …did you memorize the Wikipedia entry for “Unix shell”?

You: ….no…. yes.

Interviewer: That’s great.

Interviewer: What code editor do you use?

You: I use Atom as my text editor. I like it because it’s open-source, free, visually pleasing, and has an active plugin ecosystem.

Interviewer: So I noticed you’ve been very active on GitHub the last few months. Actually, that’s a big part of why we decided to bring you in here. I’m impressed by your answers. It definitely sounds like you know what you are doing.

Interviewer: One thing I will note, though, is that it seems like there are a lot of tutorials amongst your repositories.

You: You are correct. Coding has been a hobby for me up to this point.

Interviewer: Can you summarize what you know how to do?

You: Well. I’ve taught myself HTML, CSS, JavaScript, version control, the command line, and some basic principles of deployment in the last few months. I know how to build webpages. I am familiar with some basic principles of design. I go to MeetUps - the local Web Dev Weekly one is where I attend most often. I know how to Google and Stack Overflow my way through most basic problems.

Interviewer: What are you looking to do?

You: I am looking for a job where I can get development experience and mentorship from smart people. Building a compelling product like yours is like the icing on top.

Interviewer: Hot damn. That’s exactly the attitude we look for in our junior hires.

You: nods silently

Interviewer: Let’s walk through a scenario, to get a better idea of how your minute-to-minute coding workflow works (as opposed to your git workflow).

Interviewer: You’re building a webpage. You’re in the middle of development. You’ve written some HTML and all of a sudden your page is no longer appearing in Google Chrome. The browser’s screen has gone blank - oh no! What’s the first thing you do?

You: I open the browser’s JavaScript console to see if there is an error in there.

Interviewer: There is an error.

You: First, I read the error and consider it carefully. If it’s not too cryptic, maybe I can figure it out really quickly on my own.

Interviewer: It’s too cryptic.

You: Well, if my code was working a few minutes ago, I might play back and forth through my changes (using the hot key control-Z) really quick to see if I can spot the problem. Since I am using git (and I try to commit every 5-10 lines of code or so), it should be easy for me

Interviewer: That’s valid, and a good solution.

Interviewer: What else could you do with the cryptic error message from the JavaScript console?

You: I would search for the error message using a search engine like DuckDuckGo or Google. I could search for an answer on Stack Overflow. I could read some background information - like the documentation - on the technology I’m using, to see if I am architecting something incorrectly.

Interviewer: For how long would you do that? You know, before you asked for help from a more senior co-worker.

You: I might ask the question on Stack Overflow. Or I might work on it for 20 minutes to an hour before I asked a colleague, depending on what our culture is like here.

Interviewer: I like you a lot. I think you should meet with our CEO. We might hire you as a junior frontend employee.

You silent marvel at the disparity between the job description and what the company was actually looking for.

Exercises

Write down every term you didn’t understand in this interlude. Spend a few minutes researching each term.
What is a .gitignore file? Look for an answer on StackOverflow.com and at https://git-scm.com

CHAPTER 14