DEV Community

Discussion on: 10 Hiring Practices That Will Keep Me From Working for You

Collapse
 
anasauce profile image
anasauce

I always get a pit in my stomach when someone mentions a coderpad link in the interview process. Unfortunately we are in the middle of a recession and I (only) have about three years of experience when right now everyone can be picky enough to say they only want 5+ years of experience, SO I don't feel comfortable turning down an interview. But if the circumstances were different I most certainly would.

Tech screens that I think are productive:

1) Take home assignment: This should be something that is applicable to a task that would be required on the job (not a timed algo test). Also, the assignment should take no more than 3-4 hours to finish (four hours is pushing it) but allow the candidate a few days to complete. Don't give me a project where I'm actually doing unpaid work for your company but something that allows me to show off my ability to complete a ticket and then follow up with a code review in the final interview. I think this type of technical assessment makes the most sense for mid-junior candidates (I'm not senior level yet so no suggestion on that)

2) A project review/ code walk through. Have the candidate find a project they have worked on/contributed to. Just be mindful that many of our former/current companies won't just let us share proprietary code in an interview but sometimes I can show a redacted version of a project I worked on or my contributions to open source work. I have talked about the overall architecture of the project and show my specific contributions and how I made certain decisions with code.

3) Live coding/pair coding on an APPLIED logic problem. What do I mean by "applied logic"? Something that I might actually do if I worked for you. For example I'm interviewing for a frontend dev position: "build a form in react with form validation", "pull from this API and render a list in dropdown menu." For backend: "here's our database schema, write an SQL query that returns X" or "heres a model for 'users' of an application, write an endpoint in x framework that returns all users with x properties"

Even better? Make this a pair-coding exercise...and when I mean pair I actually mean PAIRING. Not someone creepily breathing into a the video chat and watching me code, only to audibly sigh and jump in when they don't like a choice I've made. Actually pairing to solve a problem together, talking through the approach to tackle the problem can double as a "culture fit" because it shows how someone works with someone else.