A dev job after junior year

At the end of June, I finished my second semester of my third year at university, and I’m reflecting on the results of my job search as a web front-end developer. To start with the results, I applied to four companies, interviewed at three, and received offers from all three companies I interviewed with.

I was thankfully given the opportunity to interview at all of the companies I sent my resume to, and I didn’t get to interview at one company because they hired before I did. The companies I applied to were all startups, I applied for both internships and full-time positions, and I applied to companies through Rocketpunch and referrals from friends and acquaintances. The size of the companies I applied to ranged from large startups with fairly well-known apps to early-stage startups that were funded by my school’s startup space.

Rather than describe and evaluate each company and interview experience, I’m going to focus on what I was prepared for during my first job search, what I found lacking, and how I ultimately chose my company.

Oh, and it’s going to be focused on finding a front-end developer job at a startup. I’ll warn you up front that this story may not be applicable to finding a job at a large company or SI.

🤷🏻 Why job search now?

• I’ve been studying development for about a year and a half now, and I was wondering how I’ve been doing so far.
• I started later than most development majors, so I didn’t feel confident about graduating straight into my senior year. I wanted to get a job now and learn more about development before graduating.
• I thought that when I graduate, the size and conditions of the company will be very important, so I wanted to experience the fast growth, decision-making, and creation of a startup while I was still a little bit pure(?).

📝 Resume preparation

I think the key to a developer resume is proof more than a story or theme - it should focus on proving your skills or experience with objective documents or links. Personally, I think a resume that has a lot of links in its content is more likely to be a good resume.

After you’re done with the proofs, you’ll want to make sure that your resume is selling yourself well. Here are some tips for organizing a few items.

I have a public resume on my GitHub profile, so you can refer to it. I mainly used Junghee Won’s post Writing a developer resume (feat. public resume) and Dongwook Lee’s post Writing a junior developer resume to help me write it.

About me.

• I don’t think you need that much.
• Personally, I think your name, education, current residence, contact info, and your personal blog or GitHub profile address would be fine.

Technology stack

• I’ve only listed things that I can definitely use today.
• I don’t think a stack that you’ve only dabbled with or used a little bit is a great addition to your resume, and if you’re asked about it in an interview, it doesn’t look good to say that you don’t know it because it’s been a while or you haven’t studied it in depth.
• Listing the stacks you’re currently studying doesn’t seem to help much either, I think it confuses the company who needs to validate what exactly you can do well. I think it would be better to focus on stacks that are relevant to the job that the company needs to validate.

Project History

• I tried to keep this short and to the point.
• I think the parts that should be included are 1) a few lines about what technology was used and how + **2) a link to a repository or service to prove the project **3) a picture if necessary**.
• If there is a well-organized project repository and the project has been deployed, I don’t think a photo is necessary.
• If you worked on a collaborative project, you should describe what part you played.
• Personally, I think if you can’t attach a link to the service where the project is deployed (like if it was an outsourced project that got delayed), you should be able to justify why in an interview.

Resume Photos

• I feel like this is a real company difference… For this job search, I didn’t feel like I had to think too much about it.
• Some developers prefer to use a photo that shows a little more of themselves than a headshot.
• I used my GitHub profile picture.

Other than that

• I submitted two repositories where I keep track of my learning and tutorials, and a link to my personal organization where I upload tutorial repositories.
• I described my development-related extracurricular activities and included a link to the presentation of a session I gave as a speaker at my extracurricular. It was written in colab and notations.
• I don’t think it’s necessary to include non-development activities on your resume if you’re looking for a job as a developer.
• After writing it like this, I realized that my resume is too dry; so I wrote a little bio at the beginning, which is more of a supplement to what I think the company should know about me based on what I’ve written so far.

Submit

• I wrote in Notations and attached a PDF and a link to each application.
• A PDF or a link to a notation is perfect for resume submission because it can be viewed on any computer. As long as you don’t attach it as a Word or Korean file, it should be fine.

🙋🏻 Interview (technical, personality)

Preparation

• I wrote interview scripts by category. I wrote scripts for both technical and personality interviews.
• I organized my front-end knowledge, as well as my project experience and expected questions.
• I practiced the images over and over again. Once I thought I had the script down, I practiced saying it out loud, and even if I couldn’t say it exactly as scripted, I tried to get the flow of what I needed to include when talking about the topic.
• Organizing these scripts was the hardest part of the job search… I’m the type of person who is comfortable studying organized… I remember organizing like crazy during finals week.

Practice.

• **It’s never too late to explain something after you’ve answered the question fully.
• I always have something I want to say (storm TMI ;)), so when I hear a question and answer it, I often start my explanation first, but I tried to fix it during image training. ex) If the question can be answered with yes or no, give the conclusion/answer first, and then give the explanation.
• I felt it was pretty important to say I don’t know what I don’t know If you talk like you know what you don’t know, it’s too obvious (of course, if you don’t know something critical that’s a basic skill, you’re screwed…)
• I have a protocol for answering when something comes up that I don’t know: say I don’t know, but explain what I do know in a simple way. Just be sure to answer concisely. I don’t need to say I don’t know at length, so…

I’m not sure about A (from the conclusion) + But I think B, which is related to A, is this/that/but I understand C, which is necessary to understand A, to be (briefly) + I think I need to study more about the A you asked about.

• I think being able to clearly distinguish between what you don’t know and what you do know is also an ability

🧐 What I lacked.

Improvisational (hand) coding

Some of the coding problems I encountered in interviews were “sorting array elements by frequency”, “shuffling array elements completely randomly”, and “console log ordering problems”. Some interviews asked me to write down the numbers by hand and explain them, while others provided me with a computer and asked me to code on the fly. I’m not good at coding on the fly. I find that I can’t solve something quickly because I’m overthinking it to make it more perfect.

Since I can’t solve all the problems well at once, I think it would be good to give a somewhat correct answer quickly, and explain the flow chart of what I’m going to explain to the interviewers after I have a bit of a clearer idea of what I’m going to explain, and tell them in advance that I will proceed with the explanation while fixing any bugs and optimizing it. Of course, I think it’s better to code quickly and accurately in the first place. Practice… Practice…

Backend

This is a front-end developer interview review, and the reason I write about my lack of backend knowledge is because it was asked in the interview.

I was also asked about REST API design, database model design, and infrastructure. I think it was mainly to evaluate various competencies in an early startup that doesn’t have many engineers. If you have time, I think it wouldn’t be a bad idea to study backend and database a little more.

Non-technical interview

For the technical interview, I prepared well enough to be able to answer most of the questions related to the front-end. However, it was the non-technical questions that were more difficult than I expected, especially the ones that asked me to think about engineering.

They asked about what makes a good engineer and how to be more productive. I think I was a little flustered at the time, but I realized that you can’t prepare and script for all of these questions, but it’s good to think about how you think about development, engineering, collaboration, and growth in general.

🤝 Choose a company

I think my biggest concern was whether there are seniors. I’ve been doing development on my own, whether it’s outsourcing or projects, and there have been many moments where I’ve wondered “is this really the right way to do things” or “is there a better structure” but couldn’t find the answer. I felt that if I went to a place where there were only juniors at my level, I wouldn’t be able to find a clear breakthrough in that struggle. So I chose to intern at a company where there were senior developers that I could definitely watch and learn from.

If I had gone to another company, I could have gotten a full-time position, and I could have worked on a technology stack that I wanted to challenge myself a little bit more… I wanted to grow in a slightly different way, so I put it on the back burner for the next opportunity. My criteria for choosing a company was broadly as follows.

• Does the company have senior developers that I could watch and learn from in the position I applied for?
• Is the company funded: This was my biggest concern when applying to early stage startups. Personally, I think there is a pretty big difference between startups that have raised investment and those that have not.
• Does the company conduct code reviews?
• Is the company engineer-friendly?

🎯 Some things I realized.

There are a lot of companies hiring developers, and the quality of applicants varies widely.

In other words, it’s okay to try here and there. I realized a lot that it doesn’t matter if you don’t graduate, as long as you have the skills + time to work. If you’ve been studying hard, I think job hunting is always a good way to test yourself, and you can always learn a lot from interviews and on-the-fly coding, because it forces you to confront what you don’t know intuitively.

Managing your personal GitHub account is really, really important

I’ve talked a lot about the importance of proof in this article, and managing your GitHub account is an integral part of creating demonstrable content. Repositories of your projects, TIL repositories where you organize what you’ve learned on a day-to-day basis, etc. are great references of how much you’ve studied and what you’ve done.

I’m not saying that you should commit every day, but I think it’s more about quality than quantity when it comes to maintaining your GitHub profile. It’s important to create metrics on GitHub that showcase your integrity and skills. Interviewers look at this quite closely. I’ve had interviewers look at not only project leads, but also internal code, and some have looked at the little things I’ve written in my TILs, and they’ve asked me more in-depth questions based on what I’ve written on my development blog.

Personally, I think it would be great to have either a dev blog or a TIL repository.