sw-yx / ama

Ask me anything!

Ask me anything!

Ask a question     Read questions

I get a lot of questions by email. This way anyone can read the answer!

Anything means anything. Personal questions. Money. Work. Life. Code. Whatever.

---

Guidelines

• Ensure your question hasn't already been answered.
• Use a succinct title and description.
• Bugs & feature requests should be opened on the relevant issue tracker.
• Support questions are better asked on Stack Overflow.
• Be civil and polite.

Links

• Read more AMAs
• Create your own AMA
• What's an AMA?

ama's Issues

Applying the 20-80 rule, what resources and/or strategies do you recommend for learning finance as a developer?

How do I make sure I'm doing everything right?

Don't.

Hi,

I've been learning front end and react for like 3 months, and I don't have a well established workflow.

I sometimes forget doing things such as linting, validating my code, checking compatibility with different browsers, doing unit testing... Anything that is not purely putting the code together

There may be other things besides the ones above

So basically I'm looking for a workflow or "laundry list" for front end that I can use as a reminder for the things I need to do and in what order

in general - DONT WORRY about doing everything. you're just 3 months in. take it easy. figure out your priorities, focus, and get good at something. no point being mediocre at everything. for example, being able to take any design from Dribble and bang out a workable prototype in a few days is a great skill to have. has nothing to do with browser compatibility or unit testing. those are also important, but separate focuses. try to juggle too many balls and you may drop all of them.

What are some good ways for current students or new grads to connect with potential employers?

How did you get started in software development? What interested you about working in this industry?

What are some daily duties and responsibilities that someone working on developer experience (DX) has?

Netlify Prerendering feature with Create React App vs Gatsby

Hey Sean,

I am trying to wrap my head around Netlify Prerendering in context to Create React app, a server rendered React App (Next.js), and a static site (Gatsby). Does Netlify prerendering make Gatsby unnecessary? Is there an impact on SEO as well?

Thanks!

Name a few challenging aspects that you have encountered working in software development.

Any tips on post-bootcamp job search?

This question was asked by Claire through Slack.

disclaimer

I am probably the least qualified person to ask about a post bootcamp job search. I literally took a job with the first company I sat down with on my bootcamp Hiring Day (Two Sigma). Almost every part of the process went smoothly and I can talk about it in a separate question if needed. I did also interview seriously with Google, Moat, G2i and a couple other companies, while having some small chats with Spotify, MongoDB, and Stripe. Lastly, I had a few freelance opportunities come inbound due to my Twitter activity, two of which converted into actual paying remote jobs.

i have no experience with agencies like Triplebyte or Toptal so I cannot speak to that but I do have a good impression of them.

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 (here is my list of awesome dev 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: How do you do 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 is your read/write ratio? 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.
• make sure to spend some time learning peripheral stuff to coding. OSI model, the TCP 3 way handshake vs UDP, what happens when you type google.com into the search bar, the OWASP top 10, advanced git workflows, the pros and cons of functional programming, on and on. This is a tough one because there is no end to what you can learn but basically if someone talks about stuff you dont know you might want to make a note to follow up on it later. Just do your best and have a genuine curiosity to how the system works :)
• 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
• https://www.kalzumeus.com/2012/01/23/salary-negotiation/

salary data

• https://www.builtinnyc.com/salaries
• https://angel.co/salaries/growth-hacking/new-york-city
• https://www.levels.fyi/

other good reads

• Sophia Ciocca (GHA-1707): https://hackernoon.com/how-i-landed-my-post-bootcamp-software-developer-job-in-just-seven-weeks-7b213c1bb867?source=user_profile---------3----------------
• frontend interview prep guide: https://github.com/Jobeir/front-end-interview-preparation-guide
• Patio11's Don't Call Yourself a Programmer and other career advice: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

good luck!

What are some of your favorite podcasts for programmers?

Why those?

Describe your working environment and corporate culture. Would you say that these things vary drastically by company?

What are some factors that you consider important during the hiring practice?

Essentially, if you were interviewing a candidate, what would you look for? What would make them stand out in a good way?

What are your thoughts on Reason, Elm, and Purescript?

One company I spoke with is moving from JS to Reason. When do you think it would make sense to move to one of these languages or just use one of these languages from the get-go? Although I'm aware at least some (maybe all) of these can be used on the backend, where do you see the future of frontend languages (5-10 years from now)?