My tips on job search AFTER finishing a bootcamp/freecodecamp

sw-yx · January 25, 2018, 8:24pm

Hey! i recently answered this for a friend (from my bootcamp, not from freecodecamp). I thought it might be helpful for some campers so I am sharing it here. Hope it helps someone out there. hang in there, I’m rooting for you!

The job search

My rough thoughts on the job search:

getting the interview

in general you should focus on systems (what you are doing to get the job) rather than goals (getting the job). The former is within your control, the latter is not.
recognize that the job search is highly random. There really is not that much separating you from an average Google programmer. see: Steve Yegge
but the great thing about jobs is you only need one.
So the probability of getting 1 job is higher if you apply to more things. I know this sounds obvious but when you get discouraged (and I have felt it - spent a whole week not doing any applications because I didnt feel motivated) you have to remember to keep things moving.
However spamming 200 applications a week is also not great
beyond the obvious reason, you also need to know what kind of job you want
i know the temptation to say ANY JOB WILL DO. This is harmful. Your first dev job will help you build expertise and reputation for your next job. If you end up hating your first job you may find it a lot harder to get onto a different career track. This is called path dependence and if you paid for a bootcamp you likely have already felt this pain.
Instead, try to figure out the intersection of what you like, what you can be good at, and what the world values (preferably, the world is -increasingly- valuing this thing so you have a tailwind behind you).
You are most likely to get hired, be valued, and love your work when you find the company(/ies) that closest match those three things.
The problem with this generic advice when you have no experience is of course you don’t really know what you like or are good at.
so: Talk.
Talk to alums. Talk to friends. Ask for intros, then Talk to friends of friends. Ask for more intros, then Talk to friends of friends of friends. Talk to people at meetups and coffee chats. Listen to podcasts. Chat on reddit, slack communities, twitter.
THIS is why you network. Not with the sole intention of “hey can you put me in as a referral if I buy you a coffee”. Rather, you truly want to find out what people really do, what people think of the industry and their company, and where you fit.
Developer jobs are not all the same, of course. Does the job have more frontend or backend or are you -truly- fullstack (rare)? Do you open source work? Have your own version of the Joel Test and think through what -you- care about.
Frontend: Do you work with CSS? What browsers do you have to support? What design resources are available to you? Do you support mobile native apps too? What is the product development cycle?
Backend: What’s the stack? What are the CAP theorem tradeoffs you’ve made? What reliability guarantees are you held to? What security issues do you have? I’m not a backend guy so I cant think of more questions but you get the idea.
more broadly: what’s the company mission/vision/values/culture? Here’s how to ask good questions about company culture
Your goal is to have LESS companies to apply to, but to have REALLY FREAKING GOOD reasons for each company because you’ve done your homework.
This way, when you are asked Why you want the job you have a reason. When you need to write a cover letter, the words flow from you instead of being forced. When you meet your interviewer face to face, you wont need to fake interest.
Do a weekly standup with a small group of friends. Go around and say what you did that week and what results you’ve had. Then your plans for next week. Humans are social animals. Exploit your instinct to live up to what you said you would do by saying what you will do to people you like. Bonus if they are going through the same thing at the same time.

smaller thoughts

recruiters are worthless. no matter how nice they are. keep in mind their business model is to throw as many viable bodies at their client as possible in the hope one sticks. they don’t give two shits about -you-, they just want to use you for their ends. Yes, it sometimes works out. But don’t celebrate a positive recruiter call.
you don’t need an all singing, all dancing portfolio page. you don’t need a verdant green github. people barely look at that. they dont have time. it just needs to be Good Enough. highly subjective.
you do need to be able to talk well about whatever you put on your resume so make sure everything on there is legit. For whatever reason, people still print out resumes and bring it to your interview and then stare at it instead of talking to you like a normal human being.
have 2-3 different versions of your resume on hand to tell the story that you want to tell. ditto your email draft and/or self intro and/or cover letter. learn from modern internet advertising: MORE TARGETING IS ALWAYS GOOD.
remote jobs are probably not good first jobs. you want to optimize for building a network and finding mentors in your early career and that is rough for remote jobs.
being active on twitter has been rewarding for me. I keep informed about what senior devs think about when they talk amongst themselves, and all I have to do is parrot them. As I engage in discussions and/or share my own work, people look into me as well and opportunities come my way from there.
Twitter is not the only dev community - Reactiflux is on Discord, Spectrum.chat has a lot of React folk because of Max Stoiber, Stackoverflow is obvious of course. Then there are smaller newbie-friendly communities like dev.to and codenewbies where the objective is maybe not so much talking to senior devs but practicing teaching people who are newer than you, which is also nice
I dislike putting the fact that you are jobhunting on your Linkedin. it looks desperate. I know career services people disagree with me but hey this is just me.
but you can tell your friends about the kind of opportunities that you are looking for. Friends LOVE helping their friends get jobs! Especially if drinks are on you

time split while on the job hunt

Maximum I found I could handle 4 hours of algorithms a day, usually 2-3. AlgoExpert and Leetcode help. Honestly it seems like algos are going away for interview job screens, but they are simply a rite of passage in this industry and you don’t want to lose a job opp just because you didn’t cover your bases. Rant against it all you like. It happens.
saving grace: only skim the “hard” algorithms eg knapsack problem or heap sort. even the toughest algo interviews at Google only last max 45 minutes. the secret is nobody really has the time to give you the truly hard algos. This means you can get by just being able to outline the general approach. This frees you up to actually memorize the “easy” stuff. I was expected to rattle off the Big O of sorting algos cold.
1-2 hours of job opp finding and emailing. If you can’t finish all your opps in your pipeline, good. This is a marathon, not a sprint.
put everything into a tracker like Asana or Trello. Keep juggling those balls.
Don’t rely on your own memory for deadlines. track them, set alerts.
2-3 hours of learning. Subscribe to Pluralsight (free 3month trial), Frontend masters, egghead.io. Scan through Cracking the Coding Interview. Watch all the things. Watch conference talks. These things are worth thousands and are all free on youtube. Focus in particular on raw javascript, aka everything that Kyle Simpson teaches (all available on frontend masters, or you can read his free YDKJS book but i prefer the video). Even if you think you already know some stuff, LOOK for the things that you skimmed over or only sorta kinda know. Mastery = picking up on the tidbits and nuances and the historical context and the abstract philosophy behind what is being done. Look to go from WHAT you are coding to HOW you are coding to WHY you are coding this way to WHO is coding this way to WHEN did this way start and what existed before it.
there are real interview questions on system design (eg How would you build a spam filter). I didnt focus on it and probably did badly on all of them. Podcasts like Software Engineering Daily and some Youtube channels help to explain them how real companies do it but absorbing all that info is hit and miss because it is so unstructured. I did try to though.
rest of your time: build. Set a reasonable deadline (1 week or 1 month) and then just build your idea as best as you can by that deadline. Resist the urge to perfect it. Just get it to launch, then get feedback. Build fun stuff, or explorations, or clones. still dont know what to build? try https://javascript30.com/ or https://github.com/melanierichards/just-build-websites. Try max 1-2 big new libraries each time to see how you like them. This can include contributing to open source.
optionally, teach. livestream yourself on twitch or do a meetup talk. in particular try to get practice talking while you code. this is great practice for algos as its a bit like walking and chewing gum.

The interview

technical interviews

see above re: “hard” algos
talk, overcommunicate. comment freely in code
REACTO: Repeat the question, come up with Examples, outline your Approach, Code, Test your Code, then and only then Optimize.
you are not supposed to write code that compiles. dont sweat the small stuff. the interviewer is at least as smart as you and knows what you mean.
sometimes you ARE supposed to write code that compiles. in which case you have a real coding environment and REPL. if they are watching you code, then it may be a good idea to do TDD for your code. People are somehow always impressed by that because a lot of people dont do that in an interview setting. I specifically got an offer because I instinctively chose to do TDD while trying to understand the question (wasnt a conscious decision).
people are generally moving away from whiteboarding. so you dont have to practice it, just type like you normally would but without syntax highlighting or a REPL.
JS is a fast moving field. a lot of people havent even adopted es6. there is EVERY chance you are more knowledgeable about JS than your interviewer. if you see the opportunity to teach your interviewer something, GO FOR IT. take a detour to MDN if you have to and just talk about the thing. your interviewer will remember nothing else. i’m dead serious: in each of my last 3 company interviews I repeated verbatim Kyle Simpson’s explanations of ES6 generators and people loved it even though this thing has been out for years, AND my question in particular didnt really need generators to solve. ES6 is huge.
shameless plug: https://www.impostor-syndrome.org/episodes/23-technical-interview-prep-with-clement-mihailescu

take home projects

i think my job offer pretty much hinged on this one. you can choose to go all out and risk being messy but shows how you would work in a real project, or do a minimal, super clean project that just checks all the user stories. the judgment call relies on what they are really hiring you to do. i went for a risky option which was messier but it was the right call based on what the job was looking for. so i guess always rememebr that their goal is to see you in a simulated “real” environment
people raise a stink about “working for free” on take home projects but honestly you could use the practice so whatever

fit interviews

arrive early
think of the most confident person you know. channel him/her just for this interview. you are on a stage. you are not just interviewing for a role, you are playing a role.
smile
have your self intro rehearsed and under a minute
eye contact
try to research your interviewers beforehand
lean forward
aim to talk the least (unless they are actively trying to get you to talk, then just gab their ear off. most people love talking about themselves)
smile
as a way of extending the conversation, ask some variant of “Why?” after anything substantial being said. “5 whys” always gets you somewhere interesting.
have some backup questions for “do you have any questions for me?” Good backup is the Joel Test (see above)
no matter what, you ALWAYS say you have other opportunities you are also working on in the next 1-2 weeks.

Negotiations

https://medium.freecodecamp.org/ten-rules-for-negotiating-a-job-offer-ee17cccbdab6