On Technical Assessments/Code Challenges

I find that coding by myself isn’t my preferred method of contributing to coding projects. I really like working with a team, partaking in the code review process, and improving my skills and those of others by working with other engineers.

Through work I’ve done on code challenges, I have been able to identify ways in which working on a code challenge feels different to me than writing code for a team.

1. I am more hesitant to ask questions

My typical coding process includes asking probing questions about the tickets that I am working on.

I’ve actually come up with a checklist of these questions, I ask myself and I ask the folks who assigned me the work. The questions tend to consist of the following:

  • What feature/aspect of this work is of greatest priority?
  • What code standards are in place in this repo?
  • What’s the deadline on this?
  • Who are the stakeholders?
  • Is there a ticket or card somewhere where I can track my progress of this work?
  • Does my manager or lead have a preference in how I implement this?
  • Who worked on this or something similar last?
  • Are there other examples of this in the code?
  • Is there a good pull request to use as a model?
  • Is this creating new code or modifying the legacy code?
  • Is there documentation for what I’m working on?
  • Are there design specifications for what I’m working on?
  • Who are the gatekeepers of the repo I’m working in?
  • Are there CONTRIBUTING guidelines for the repo I’m working on?

… etc.

Often times in coding challenges, I do not feel I have the opportunity to ask these questions.

For that reason, when I receive coding challenges I like to ask these questions. With the focus being, “Which of these is most important? If I could only deliver one of the asked for criteria within an hour what would it be? What if I could only deliver 2?”

2. As a software engineer, my goal is to learn from my team and solicit ongoing feedback.

When working on a coding challenge, particularly one where I’m not embedded in a code review process it feels more difficult to go ahead and get that ongoing feedback.

Within a code review process, I get ongoing feedback on my work in progress and not just the finalized product. While working on a code challenge, it feels much more focused on the end deliverable then how I got there.

I tend to agree with the idea that “software is never finished, only released.” In my work this means I balance iterating from an initial idea to a shipped piece of software, knowing that there is usually something I’m not happy with and hope to go back and improve upon.

My hope is that when I get started on a ticket, I will ask questions and from there begin to learn about the code that is present or find examples of this feature elsewhere. I’ll delve into where I think this code will go and mock up a simple test of it. Usually, this involves pushing up my current committed code, comments and all, and opening a work in progress branch.

After working on the intial proof of concept, I like to bring my idea to another engineer and chat with them about the work. See if they have any design suggestions or areas they think I’m not considering right off the bat. I think this process prevents me from veering off in the wrong direction early on.

3. Invested time versus finished project

When I work on a challenge, it is for a future employer. I feel I am being evaluated on the final bit of work that I am turning in. Not the steps I took to get there. Not the way I communicated about it along the way. Not the decisions I made. Not the research I did. It is not a holistic representation of the way I prefer to code.

Not to forget that time constraints seem to go out the window at this point, even if given a limited time frame on the work.

Would I rather turn in something that feels like not the best representation of my work in 1 hour, 3 hours? Or would I rather spend a greater amount of time and hope that the work looks good enough for the folks evaluating it?

This is a trap. I end up losing myself on smaller problems. I go way over my time. I lose confidence in my capacity to show my best work.

If I was in a production level environment and was told I have 1 hour to deliver something to production, I wouldn’t write pretty code, or probably even tests, it wouldn’t be accessible, and I would probably ignore most non-critically blocking aspects of a code review. This would be a something is on fire scenario and I would ship something that would “work”. I would communicate all of this, including the trade-offs of work of this sort, to my team, in my code, and in my pull request. Once it was delivered and nothing was broken, I’d prioritize following that work up with other improvements. I’d focus on adding tests, refactoring the code to look better, and adding the secondary features that were asked for.

The info above may not change the code that I wrote for a technical challenge. Hopefully, it gives you a clearer insight into the way that I contribute to a team. It also helps me to think about how I will work on technical assessments in the future.

What does a good company culture look like to you?

My work in technology has focused on solving problems, collaborating with high performing teams, building on actionable feedback, and delivering impactful incremental solutions. There’s a lot happening in that statement, let me break it down into key factors I look for.

Mindful growth - Technology falters on this difficult precipice of needing to move quickly without burning out. Mindful growth is a balancing act with the clear understanding of the drivers of the business, sustainable people practices, and industry best practices. I look for teams that value investment in their peers, seeing it as a way to drive the business forward. I check in with my connections about what work is like and how well a company retains talent. I hope to have conversations that are cognizant of the tradeoffs for decisions and reflective on ways to improve.

Empathetic communication - I recently read this great article by Cate Huston, Engineering manager at Automattic, about communication, https://qz.com/work/1587170/the-five-types-of-communication-problems-that-destroy-company-morale/. Empathetic communication shows up to me in careful code reviews that hope to educate while also ensure the company’s codebase improves. It’s part of speaking together rather than over each other in time-constrained meetings. Even going so far as to revolve around text-based discussions where context and tone are hopefully provided alongside information.

Methodical action - For a business to be sustainable it has to make money. Across my time in startups and as an engineer, I do my best not to forget that. For this reason, I appreciate companies that take action to integrate ongoing feedback relating to both quantitative and qualitative data. In the same vein, I want a transparent understanding of the metrics behind the goals of my work. This allows me to be innovative while comprehending how my work contributes to the performance of the organization.

These factors of company culture have come from a decade as an employee with 8 of those years embedded in high velocity technology companies. I am confident these factors build sustainably successful companies that attract, grow, and retain the types of teammates I want to collaborate with.

Strategies I use to level-up my git

This post was originally a TweetStorm. Read that tweetstorm.

This post is part of a group I’ve written about improving your version control skills.

I’ve had some serious level ups in my git workflow as I’ve continued working as a developer.

Currently my git workflow focuses on a few things:

  • Small staccato commits that come together to tell a story

  • Using feature branches

  • Writing great pull requests

No fear of committing

The habit of regular small (even trivial) commits, was baked into me while going through Dev Bootcamp in Chicago. This happened because our cohort would inevitable yell out “NIGHTHAWKS COMMIT!” at timed intervals to ensure we were iterating on our Version Control learning.

I then further systematized this by including a tool in my terminal prompt that told me the time since my last commit on my current branch, similar to what @Goles has written here for the Zsh terminal.

picture credit to Tuo Huang from this post

Eventually I learned of git commit patch and Gitx. I previously wrote about git committing interactively.

Some folks told me I was potentially making my commits too small! Commits tell a story. The story of your feature or your fix. The growth of your skill or your thought process. Sometimes that story needs to be editing, which is why you may want to add git squash to your git workflow.

If you’re a junior developer, picking up great VCS habits, demonstrates a certain level of skill that gives you an edge over other applicants. If you can show git skills you’re a step ahead.

Where I am today

My current git workflow will involve branching for my feature branch including a long descriptive branch name. This isn’t feature-branch, its jira-ticket-123-this-is-what-the-feature-does-simply-branch.

Start working. Then every 20 minutes, a max of an hour, I’ll commit. Usually with git commit patch or Gitx. My commits hope to explain why I made these changes and be less than 80 chars if possible

If I want to add more info, add a new line. With how you did something, though this should likely be evident from your code. Alternatively, you could split that commit into multiple commits.

Push your branch up, this gives it exposure and also helps people who might give it a look-see or to at least show your work. Some teams are comfortable with you opening a partial PR or a 30% PR for feedback or to provide guifance. Of course ask your team.

When you finish your work open a pull request. In my pull requests I like to include a lot context. Read more about how to write a great pull request.

All together these allow me to feel confident in my version control capabilities and work better as part of a agile develoment team.

Additional Resources

  1. Github : @goles zsh_git_timer

  2. Git tip: show current branch and time elapsed since last commit in command line by Tuo Huang