So there are problems with hiring engineers that no one is working on. Those problems are: The engineers who create bad resumes The hiring managers who write bad job descriptions The entire HR process, which has no feedback, and relies…
Bugs. Theyâ€™re the bane of your existence, arenâ€™t they? Over the last few years, Iâ€™ve finally gotten to a point where Iâ€™m happy with how my team is dealing with bugs. Weâ€™re spending less time in the bug database and more time fixing bugs.
So I decided to spread the word to help others.
In honor of Jeff Weiner, the CEO of LinkedIn coming to visit Chegg, I decided to write up a post for Linked In. It’s called The Best Career Advice I’ve Ever Received.
Ok, so you’ve got a small technology company and you’ve hit that threshold of about 4 people where it becomes glaringly obvious that you need to institute some process. Or perhaps your engineering team is smaller than that, but you realize that if you don’t spent at least a minimal amount of time on planning your work, you’re going to spend a lot more time doing the wrong work, the less important work, or delivering the wrong thing.
This article will help you bootstrap some minimal processes that will enable you to be much more effective. It should be enough to carry you to the point that you have to split engineering into multiple groups at about 10-20 people.
I was talking with a recruiter about a position at their company the other day and after reading the job requisition I commented to her that it was a “Bigfoot” requisition; the kind of req that reads “Must be a…