Take a breathe, fix it and try again! Part 2

tl;dr: Accidentally checking in credentials/Missed responsive look & feel for frontend repos/Not using the configuration service pattern/No README and screenshots/Not having repository reviewed by more experienced people

Disclaimer: I work with U.S. startups in Bay Area and NYC and vet their candidates from time to time. Below are some tips I figure would be useful to new comers (Bootcamp or college grads). Most of them are Node.JS related. I have received several repositories to review and give feedback on. I appreciate all of the review requests, and will refer and give tips on when applicable.

You can also read Part 1 here.

Background: The Hiring Process for full-stack developers is a mixed bag at the Startup scene in 2020.

The current process goes something like this:

Founders put together a MVP to get seed fund/first 100 users. Startup attempts to develop new features and acquire new clients. Having only 1–2 technical founders on the team, they begin to access the amount of work that is achievable given the time constraint. A deal or two is signed! New clients are interested to integrate or try the product. Since they are the early clients who is taking on the risk, they demand features and changes to the MVP to fit their use case. The technical founder realize that they lack the bandwidth to complete the asks, and reach out to hired.com/angellist/linkedin network/indeed and create job postings. Job postings contain the software stack that the current MVP is built with. Recruiters play arrange marriage match up with their internal network to find candidates. Resume PDFs come in, technical founder/first technical hire reviews it and have 30 minutes to hour long phone conversations to gauge the strength of the candidate, they then arrange for an on-site meeting. Candidate comes on-site, talks to company employees, and goes through coding exams (about an hour to demonstrate problem solving abilities).

To Hire or Not to Hire?

The spectrum of experiences and ability to troubleshoot is a large gap. Not all technical founders discriminate against newcomers either, because a handful of them are from bootcamps/fresh out of colleges themselves.

Here are 3 top filtering criteria:

Can they convert to the Startup working style? If the candidate has only worked with a fixed set of technology over the last 5 years, and that fixed set does not mesh with the current MVP stack, they are less preferable because they likely will need more time to change their existing working style. This can happen to candidates coming from med-large size companies after working there for the better part of a decade.

If the candidate has only worked with a fixed set of technology over the last 5 years, and that fixed set does not mesh with the current MVP stack, they are less preferable because they likely will need more time to change their existing working style. This can happen to candidates coming from med-large size companies after working there for the better part of a decade. Can they hit the ground running? If the candidate does not have much experiences (with running things in production) under their belt, they will receive homework which requires them to learn the MVP stack and implement a small fix or task to gauge if they are able to do the work or not.

If the candidate does not have much experiences (with running things in production) under their belt, they will receive homework which requires them to learn the MVP stack and implement a small fix or task to gauge if they are able to do the work or not. Are they Pioneers? — How fast and independent can they implement/troubleshoot/google to keep the show running? This is crucial to the technical founder/CTO/current tech lead for getting past the current deadline and client asks.

Not Everyone will have GitHub Repositories, but we appreciate it when available.

GitHub repositories give a bit of insight into the experience level of the applicant. Do they practice reasonable and good defaults? Are they careful? Is the codebase consistent in coding style and show that they understand enough about the programming language to be self-sufficient?

It helps greatly to us, really! Ok, here are 5 more avoidable mistakes that I have seen from programmers and their demo repositories:

Mistake 1: Checked in database/AWS/Api credentials

Most backend projects will connect to a database to perform CRUD (Create/Read/Update/Delete) operations. If the demo is a shopping cart, it will have Api credentials to Shopify or Stripe. If the project allows user to upload images of any kind, it will likely contain AWS S3 credentials. Seeing these values in the codebase is a warning sign to the interviewer.

It means either the applicants has not been told that this is an anti-pattern yet, or that they have been doing this for a while on their own.

We cover how to clean these credentials up by using a configuration service and load them from environment variables here.

Mistake 2: The Deployed Frontend Portion does not check for Mobile dimension or Responsiveness.

Source: Augustash. Mobile traffic has crossed over Desktop traffic since late 2016, and so far the trend has not reversed.

With the deployed demo site in the portal, we check a couple of things:

Is the demo site up?

Is the demo site functional? (Are there broken links or glitch in the UI)

Does it display reasonably well in the mobile dimension?

You can use Chrome Inspector or Safari Inspector to quickly view any website in the mobile dimension.

Note the blue icon next to the Element Tab, toggle it to see if your landing page holds up to this test.

For applicants who are looking to lend a helping hand in frontend feature development, seeing a functional responsive site tells the interviewer that they do have mobile usability in mind. This greatly reduces the amount of on-ramp time too!

(I should mention that my specialty is mostly in backend and integration, so I am not the best person to give advice on frontend and SEO work, I am only talking about things others and I check in this context)

There is no one right approach to solve mobile usability, depending on what you used to code the current demo, it is worth it to do a quick check yourself and make sure the site looks and behaves correctly in the mobile dimension!

Mistake 3: Not knowing what is/is not configuration in general

Similar to mistake 1, all static username/password/api keys are definitely in the configuration category. Therefore, they do belong in configuration server or files. However, they are not the only things that we can configure given a backend server.

Any value that you expect to change between local/staging/production environments is a configuration variable.

This includes (but is not limited to):

S3 Bucket ARN/Path

Environment Name

JWT Secrets

The main reply email address (E.G. info@teamzerolabs.com/hello@teamzerolabs.com)

Cron time strings (for running tasks in the background)

Web Hook Urls

Slack Channel Name

Database Host Name and Port Number

Database SSL settings

And more.

You can improve the readability of the repository by making sure that configurable values are never hard coded. Refer to the tutorial from #1 to clean it up before sending it out for review!

Mistake 4: Having no repository README.md or lacking screenshots for Mobile Application Demos

The interviewer rarely has enough bandwidth to clone the actual project to run it locally. It is not 0% chance, and we do do it for impressive repositories that are well put together and documented.

We do tend to dismiss the repositories that does not have a README.md or have a really bare one.

Having a README that points to the deployed demo site, and including some screenshots (in mobile dimension a bonus) goes a long way. There are many good examples out there, here is one example:

Credit to Richard Chu, code available at: https://github.com/rchu84/framagram

If you are in a hurry, a minimum Readme that mentions the following will help you reach more audiences:

Overview — 2 to 3 sentences on what the project is trying to accomplish, what problem it solves.

Demo site Link — For interviewer to try.

Tech Stack used — Interviewer care about stack fit with the company itself (with the current MVP). Node.JS programmers also have a shorter gap to transition to TypeScript compare to other types of programmers.

(Optionally) A short sentence on how to contact you: email/twitter/other social network profile

Mistake 5: [Non-technical Tip], do not be too afraid to reach out for a repository review!

It does not matter how far you have gotten on your developer journey. If you have something that you are proud of, you should share it with the world and send it to more experienced developers to gain insights.

We often hear harsh criticisms on amateurs from gate keepers in the CS community. They are in the minority, but they are the most vocal bunch. It is not new for gate keepers to read articles meant for beginners and dismiss the articles outright for not reaching arbitrary standards in their mind. (Instead of say take the chance to educate and provide better contexts)

But, you know what?

Everyone has to start from somewhere. Before we learn to build complex projects, we need to learn simpler ideas and write hello world scripts. No one is born knowing how to solve problems for others.

There is an estimated 4 Millions developers joining the market of software development by 2023. Bring it to 27.7 Million developers total in the entire world. By that projection, we will only have 3–4 developers per 1000 capita. We are far from having enough developers to take on the world’s need.

Source: www.daxx.com

You cannot stop people from trying. The open source community/stack overflow/Google and other search engines have all made the knowledge gap smaller and more attainable.

Great software has made the impossible difficult, and the difficult to commonplace. It is up to the rest of us to increase the minimum bar on developers by sharing our knowledge openly.