A lot of people want to start a business while they're working but refrain from doing so because of blockers that are usually the same three things, not knowing where to begin, not feeling like you have anything worth selling, and just being too burnt out from the day job to have energy left for anything else

You should start with figuring out whether you're selling your time or your insights, because that one choice ends up shaping pretty much everything else, how you price your products, how the business is structured, what your actual day to day looks like once it's running, time based work is easier to get moving but it caps out fast, insight based stuff takes longer to build trust around but scales a lot better once it does.

after that it's less about having a perfect plan and more about being intentional with time and energy so you don't just burn out trying to do two jobs at once, one way to think about it, everything kind of boils down to cash coming in, clients you're actually serving, and content that brings new people in. If you're trading on insights, you don't really have a business until there's revenue from actual clients, the rest is just motion.

burnout normally will come up at some point since you're basically working two full time jobs, if you're already switching between five things at your day job, adding a side business where you're also switching constantly just speeds that up, picking one thing to focus on each day instead of touching all three at once made a bigger difference than i thought it would.

A lot usually quit their jobs as soon as they get a stable income which can take a looong time but with time and gained experience, a person can eventually find success, although I advise against quitting your job right after your business has taken off, rather look for something part-time or freelance that you can fall back on.

Generally, css has a reputation for being unpredictable but it's generally doing exactly what it's supposed to, the disconnect is usually a mental model that doesn't match how the browser calculates layout.

From what I have seen, a lot start by copying examples which works for simple cases but when something breaks there's no foundation to reason from and fixing it becomes a process of trying different things until one of them works

When it comes to box models, every element is a box with content, padding, border, and margin, by default width and height apply to the content area only, which means padding and border get added on top of whatever size was specified, a div set to 200px wide with 20px padding on each side renders at 240px, setting box-sizing to border-box globally makes width and height include padding and border, which is the intended behavior for most cases.

It is specificity and the cascade what makes css feel inconsistent until the underlying rules become clear since the browser follows a consistent hierarchy for deciding which style wins when multiple rules apply to the same element. Inline styles take priority over everything, ids outweigh classes and classes outweigh element selectors, when two rules carry equal specificity the one appearing later in the stylesheet wins, to say it simply, a system is logical once it's mapped out.

There is also flexbox and grid cause persistent confusion because flexbox tends to get used for everything regardless of whether it's the right tool, it handles one dimensional layout, either a row or a column, grid handles two dimensional layout, both rows and columns simultaneously, properties like justify-content and align-items also belong on the container not the children, which is counterintuitive at first and causes a specific category of layout bugs until it clicks.

To put it simply, working with the browser's natural flow rather than overriding it produces more stable layouts, forcing elements into position with absolute positioning and negative margins tends to work until the content or viewport changes and then requires constant adjustment, understanding how elements naturally stack, wrap, and collapse makes layouts easier to build and significantly easier to debug.

css becomes considerably more manageable once there's a coherent model to reason from, from what I have seen most of the frustration comes from not having that foundation early enough.

When it comes to job boards applying through them means your application passes through an intermediary before it reaches anyone, as in formatting gets stripped, fields get auto-populated incorrectly, and what arrives on the other end sometimes looks nothing like what you sent, applying through the company's careers page removes that, they get what you give.

A role on linkedin gets seen by everyone scrolling their feed, the same role on the company's website gets found by people who went looking for it, who searched the company, went to their careers page, and applied there which is a smaller pool.

some roles never make it to job boards at all, companies post on their own site first and the listing reaches linkedin later, sometimes after the position is already close to filled, checking careers pages directly on companies you're actually interested in is worth doing for this reason alone.

the friction of applying through a company site, such as making an account, filling out fields manually, filters out people who won't bother, it's useful when you think about who you're competing with.

the job board is fine for finding roles, it doesn't have to be where the application comes from.

Local environments are deceptive since everything runs because the machine has a specific configuration built up over time such as particular package versions, global installs from months ago, or config files sitting in directories that aren't part of the project, the code works because all of that is there, a deployment server or a teammate's machine has none of that and the failures that result aren't always easy to trace back to the actual cause.

the .env situation is probably the most common version of this, api keys and config values go in a .env file, it gets added to .gitignore which is correct, but when someone clones the repo, the app doesn't run, the fix is a .env.example file which should have the same keys as the real one, no actual values but just placeholders, it'll live in the repo, won't get gitignored, and tells anyone setting up the project exactly what environment variables are needed without having to reverse engineer it from the codebase.

node versions produce the same category of the problem, for example: one machine on node 18, another on node 16, certain things behave differently and the resulting error has nothing to do with the version mismatch, the way you can fix the error is a .nvmrc file in the project root specifying the node version doesn't cost much to add and removes that variable entirely.

Though the best solution is docker, containerizing the entire environment so it runs the same way everywhere, it's worth learning eventually but it's a significant thing to set up, the .env.example and .nvmrc habits handle the most common cases with almost no overhead and are probably the better starting point.

Lots of, if not the majority of people, don't apply for a job unless they're 90% qualified for it and it might also be the thing keeping them from finding a job.

the 90% qualified thing is the one that costs people the most, job postings are wishlists for the ideal candidate, since they're not exactly put out by peole who understand the role offered completely, the person who wrote it listed everything they could possibly want and they know they're not getting all of it, applying when you meet 70% of the requirements is what you should be doing.

The resume is never going to feel perfect, there's always something to edit, at some point you're just delaying because applying is scary and rejection is unpleasant and editing a resume is neither of those things, a resume you're not totally happy with that actually gets sent is more useful than a perfect one you're still working on in three weeks.

Genuine excitement matters but it's also not always there from the outside looking at a posting, some of the jobs people end up loving started as something they applied to because the timing was right, not because they were fired up about it, a posting tells you almost nothing about what it's actually like to work somewhere and most people don't find that out until they're already in the interview.

the other thing about being very selective is that interviewing is a skill and you only get better at it by doing it, people who interview frequently get better at it fas, people who are waiting for the perfect opportunity before they apply anywhere are also not practicing and it shows when they finally do get in front of someone, the early interviews for jobs you're not sure about are not wasted, they're reps.

the version of selectivity that feels like having standards is sometimes just not wanting to get rejected which is understandable, rejection is awful but, you can't get good at interviews without doing interviews and you can't get offers without applications and at some point the math just is what it is.

A lot of people hear "contribute to open source" and picture themselves submitting pull requests to react or kubernetes or something equally intimidating and immediately decide it's not for them, which is understandable, also a shame because they're missing something that actually moves the needle.

Most of open source is not writing complex features for massive codebases, a huge part of what actually needs doing is fixing typos in documentation, improving error messages, adding missing examples to readmes, writing tests for functions that don't have them yet, and that is completely approachable and shouldn't intimidate anyone.

the reason it matters for the job search specifically is that it's real code in a real codebase that real people reviewed and merged, which is a completely different thing to show someone than a project you built by yourself following along with a YT vid, when you link a merged pull request in an interview you're showing that someone else found it satisfactory enough to ship.

finding something to contribute to is the part that feels hard but isn't. The easiest starting point is whatever tools and libraries you're already using. if you built something with a particular library during bootcamp, go look at its github issues, filter by "good first issue" or "help wanted"; most active projects tag beginner friendly issues specifically because they want contributors and they know new people need a way in, read a few, find one that makes sense to you, and just try it.

the first contribution is where you're figuring out how the project is structured, how they want things formatted, what their PR process looks like, after that it gets easier fast, and maintainers are generally way more welcoming than people expect, especially on smaller projects that actually need the help.

You don't have to contribute code at all to start. finding a genuine bug and writing a clear detailed issue report is a contribution, improving documentation that confused you is a contribution, these count, they show up on your github, and they get you comfortable with the workflow before you're touching actual code.

most people coming out of either a bootcamps or are college grads are all doing the same things. same linkedin applications, same leetcode, same portfolio, open source is the gap, most of them aren't touching it and it's the thing that keeps coming up when people actually get interviews.

What day a posting goes up actually matters. postings that go up monday or tuesday get flooded fast because that's when most job seekers are checking job boards after the weekend. applying within the first 48 hours of a posting going live matters a lot because a lot of recruiters start reviewing applications as they come in rather than waiting for the posting to close, especially at smaller companies, by the time a posting has been up two weeks there can be hundreds of applications and yours is just one more in a pile that's already being skimmed instead of read.

Also, January gets treated like the best month to apply because of new year new job energy and it's true that hiring picks up, but it also means everyone else has the same idea at the same time. the competition spikes in january, the weeks right before major holidays (late november, mid december) tend to have less competition because most people assume nobody's hiring then, which means the people who are still applying have way better odds against a much smaller applicant pool, companies are often still trying to fill roles before year end budget resets too.

There's also end of quarter, companies sometimes have budget that needs to be used before it disappears and roles that have been open for a while suddenly get prioritized in the last few weeks of a quarter, I can't promise this holds at every company, it's more of a pattern than a rule, but enough people have mentioned it that it seems worth knowing.

even what hour you hit submit makes a small difference, applying first thing in the morning when a recruiter's inbox is fresh tends to get more attention than applying at 11pm when your application just becomes one more thing in a pile they'll get to eventually, doesn't change your odds dramatically on its own but combined with applying early in the posting's life it adds up.

none of this means a great application at a bad time loses to a mediocre one at a good time, the actual content still matters most but, if you're applying to two similar roles and can only realistically do one well today, the one that was posted yesterday is probably worth prioritizing over the one that's been up for three weeks.

most people treat the job search like it's just about how good their materials are, it's just not something most people think to even try, costs nothing to do, unlike literally everything else about job searching.

It's almost never the bootcamp on the resume that's the problem. that's what everyone assumes, it's usually a bunch of smaller stuff happening at each stage that's completely fixable but nobody points it out directly so people just keep doing the same thing and wondering why nothing's working.

starting with the resume, the issue isn't that it looks like a bootcamp resume, it's that it looks identical to every other bootcamp grad's resume, same projects, same tech stack list formatted the same way, bullet points that describe what the app does instead of anything about actually building it. hiring managers who look at a lot of these genuinely cannot tell them apart after a while, it's not about making it look nicer, it's just bullet points specific enough that they couldn't have been written by anyone else. what was hard about it. what broke. what you figured out, not "built a full stack app using react and node" because that's on literally everyone's resume (you can still do them for experience but you need to be more unique about the projects that you want to showcase)

GitHub is minor but worth mentioning. not because anyone's sitting there reading your code, but because a profile with three repos that all have the default readme and a commit history that's just one panicked week six months ago looks like someone who built things to show people and then stopped which is not great, even small consistent commits over time look like someone who actually codes, it takes like ten minutes a week and it matters more than it should. Also, a lot of people waste months without realising it, applying to series a startups and big tech and local agencies all at the same time with the same resume makes no sense.,those are completely different contexts that want completely different things from a junior hire, it feels like more applications equals more chances but it usually just means worse applications everywhere, just pick something and go deeper on it for a while. the response rate changes.

With the interviews the CS fundamentals gap is real, it's not that bootcamp grads get a question wrong, it's the reaction to the question, this visible anxiety the second something comes up that feels outside bootcamp territory, interviewers notice that immediately, you don't need to know everything, genuinely, but you need to be able to say here's what i know, here's where my thinking goes, here's where I’m not sure, without falling apart. a wrong answer where you're visibly working through it beats a right answer delivered like you're about to pass out, moreover, you need to explain your project in a way that doesn't leave anything out, the default answer is a summary of what the project is and what it uses. which is fine but it sounds like a demo, what interviewers actually want to know is what was hard, what didn't work, what you'd change, what you learned from the thing that broke.

anyway, a bit of a long post, sorry but I feel like some people in this sub are a bit too hard on those who want to take the bootcamp path instead of the CS path.

I've been in this situation and the way people react to it is almost always wrong, they assume they're saying something bad in the interview so they go home and watch more prep videos and practice their answers until they can recite them perfectly and then go back in and the same thing happens. because it's usually not the answers.

But, interviewers are not just checking whether you can do the job, they're asking themselves something they'd never actually say out loud which is do I want to sit near this person for the next two years, and that question gets answered by a bunch of small things that has nothing to do with your qualifications.

energy is a big one, not fake enthusiasm, not performing excitement you don't feel, just the basic sense that you actually want to be there, interviews where someone is technically fine but a little flat or guarded leave this weird vague feeling that's hard to pin down, and then the feedback is "we went with someone who was a stronger culture fit" which is a sentence that means nothing and also means everything, the other person just felt more alive in the room somehow.

the questions you ask at the end matter more than most people think too and that is by asking something genuinely specific to their situation, something you noticed about the company or the role that made you curious, it just sounds like a real person asked it rather than someone going through a checklist. interviewers actually remember it because most candidates ask the same four questions every single time.

the over rehearsed thing is also real and a bit counterintuitive, if you've practiced your answers so many times that they come out perfectly structured with a clear beginning middle and end, that's actually a problem, interviewers talk to enough people that they can feel the difference between someone who's thinking and someone who's reciting, a slightly messy answer where you visibly work through something in real time will land better than a polished one that sounds like you've said it forty times. which is annoying because all the advice tells you to practice more.

and sometimes honestly it's just nothing you did. internal candidate they were always going to hire, budget thing that happened mid process, someone on the panel who just clicked more with another person for no real reason. that's real and it happens and it's genuinely out of your control.

but if it's consistent, multiple companies, multiple final rounds, same result, something in the overall impression is probably slightly off somewhere. the fastest way to figure out what is to record yourself doing a mock interview and actually watch it back. it's deeply uncomfortable and you'll want to stop watching after thirty seconds but it's the only way to see what the interview will be seeing.

So, I actually talked about this briefly in another post (which I would look for later and link here) and I thought that I should expand more on the matter since it's a pretty important step to getting a job but unfortunately, a lot of people ignore or don't even know about it.

almost every company with more than like 50 people is running applications through software before a human ever opens anything; it's called an applicant tracking system and what it actually does is parse your resume, pull out information, and in a lot of cases score it against the job posting automatically. if you don't clear whatever threshold they've set, your application just sits there, not rejected, not reviewed, just discarded, you never get an email. you just never hear anything.

The way it scores you is keyword matching, not concepts, not the general idea of what you're describing, actual specific words from the job posting, so if the posting says "project management" and your resume says "managed multiple projects across teams" those are not the same thing to the software even though any human reading both would immediately understand they mean the same thing, which is kind of insane and a little frustrating when you think about it but that's how it works.

So, the thing that actually helps is just reading the job description carefully before you apply and noting the specific language they use, then go through your resume and where it's accurate, use their words not yours. "stakeholder management" instead of however you naturally describe that, "agile methodology" if that's what they called it, not randomly stuffing keywords in, just making sure your legitimate experience is described in language the system actually recognises. it takes maybe 20 extra minutes per application and it makes a real difference.

the formatting is also genuinely worth knowing and it's counterintuitive, the more visually designed your resume is the worse it tends to do with these systems. columns, text boxes, graphics, tables; all of that gets mangled when the software tries to parse it, a resume that looks really clean and impressive as a pdf can come out as complete nonsense on the other end, boring linear formatting that a machine can read easily is more useful than something that looks nice on screen, at least until it gets to an actual person.

Also, a lot of systems have a hard cut-off, below a certain score your application doesn't go to the bottom of the pile, it gets filtered out entirely and no human makes a decision about it at all, ever, so you can be genuinely qualified, have done the exact job they're describing, and still never get considered because three phrases were missing from your resume.

it's a weird system and honestly kind of a frustrating one to find out exists after the fact, and I'll say it again, one of the issues that most people disregard is that their resume is never making it to a person who could actually evaluate those things.

okay so there's this version of the career switch story that's everywhere online. person hates their job, teaches themselves to code for a few months, lands a role, posts about it on linkedin, gets 50k likes. and I’m not saying that doesn't happen because it does. but there's so much that gets left out of that version that i think genuinely messes with people's heads when their experience doesn't match it.

so here's the things that actually matter, some of this is going to sound obvious and some of it genuinely isn't:

first thing, the coding is not the hard part. i know that sounds insane if you're just starting out and struggling with basic python but I promise the technical stuff is learnable. there is more free material available right now than any human could get through. the hard part is everything that doesn't have a tutorial, like knowing whether you're actually learning the right things or just staying busy, knowing when you're ready to start applying versus when you're just delaying because you don't feel confident enough to apply, nobody makes content about those kind of things because it doesn't have a clean answer.

When it comes to learning, pick one thing and actually learn it before you touch anything else. doesn't matter that much whether it's javascript or python for most entry level paths, both are fine. what kills people is jumping to something new every few weeks because they saw a post saying rust is the future or whatever. you end up knowing a little about a lot of things and that's almost useless for getting hired, depth is what matters the most, also, on a side note, if you keep dropping learning a language then restarting from the beginning later, if that process repeats a lot of times, it's best to pick another language, me for example, kept watching python tutorials through the course of months, I would drop it, then forget about it then have to re-learn the whole thing, now I'm learning Javascript and HTML.

the project thing is also genuinely important and i feel like it gets said but not explained properly, build something that has a reason to exist, not a todo app. not a weather app, not the exact project the tutorial walked you through because hiring managers have seen that project literally hundreds of times and it tells them nothing about you; build something you'd actually use or something that solves a problem you've actually run into, it doesn't need to be technically impressive, it needs to feel like a real person made it for a real reason. "i built this because i was annoyed that no tool did x" is something an interviewer can engage with; "i built this to practice my crud operations" is a conversation ender.

your background from whatever you did before, retail, service, etc, whatever non-tech background, is more useful than you're probably giving it credit for but you have to do the work of connecting it yourself because nobody's going to do that for you. years of working with difficult customers under pressure, understaffed, on your feet, dealing with stuff going wrong constantly, that's actually relevant in a team environment and most people just leave it sitting there on their resume with no attempt to explain why it matters, don't do that, there are podcasts of people from non-tech background who went into tech which you could inspire from.

apply before you feel ready, it's common but important advice because ready never arrives, it's not a feeling you're going to wake up with one day, it's something that gets constructed slowly through doing interviews and getting rejected and doing more interviews. the rejections early on are genuinely useful, they tell you things about your gaps that no amount of studying alone would surface. and they cost you nothing except an afternoon of feeling bad about yourself which is unpleasant but survivable.

the timeline thing is probably the most important thing in this whole post honestly. the people who post about landing their first role in four months are real but they are not the median experience, they're also usually not accounting for the six months of learning they did before they started counting, most people doing this while working full time are looking at a year to eighteen months before they're getting consistent interviews, maybe more, also, it's more depending on the path you want to go, for example, learning ML isn't the same web devs, ML can take a looong time to grasp and that is a completely normal. it doesn't mean you're failing or slow or that you chose the wrong path. it just means it takes time and the internet has a selection bias toward the fast success stories because they get views and exposure.

anyway that's most of it. none of this is meant to be discouraging btw, another thing, when choosing the path that you wanna delve into, make sure that it's compatible with the device that you're using, I remember learning backend only to discover that the RAM of my laptop wasn't enough for some necessary softwares, frontend and web dev are more lightweight generally.

Hello,

I’ve been in the job market recently, and after a lot of trial and error, I stumbled upon a strategy that helped me land interviews and, eventually, a job. I thought I’d share my approach in hopes it might help someone else navigating this daunting process.

Targeted Research: First off, I took the time to research companies I genuinely liked, made a list of companies whose values aligned with mine, and I followed their work culture, recent projects, and even leadership changes on LinkedIn. This gave me insight into what they value and how to tailor my application.

Customising My Applications: For each application, I wrote a cover letter that spoke directly to the company’s mission and how my experiences related to their recent initiatives. This took time, but it helped my application stand out.

LinkedIn Networking: I took the time to reach out to connections (and even friends of friends) at the companies I was interested in. I sent personalised messages, asking for a chat about their experience at the company, a lot of people are happy to help or at least offer insights, and it allowed me to build some solid connections. I often mentioned that I was open to exploring opportunities, but I made it more about learning rather than direct asking.

Follow-Up with Purpose: After applying, a week or so after submitting my application, I’d find the hiring manager or a recruiter on LinkedIn and send a brief note. I’d mention how excited I was about the position and my genuine interest in being part of their team.

Showcase Your Personality: During the initial rounds of interviews, I made an effort to inject a little bit of my personality into the conversation. Instead of just rattling off skills and experiences, I shared stories that highlighted my values and character. It became less about proving I could do the job and more about showing them I’d be a good fit for the team culture.

Be Open to Roles Beyond Your Title: To widen my net, I began looking at roles that were adjacent to my skills but not exactly what I had done before. This helped me keep my options open and led to an unexpected opportunity. Sometimes, companies are looking for potential and cultural fit rather than a perfect match to a job description.

Feedback and Iteration: Lastly, after interviews, I’d often follow up and ask for any constructive feedback on my application or performance (got ghosted by some not gonna lie lol). I learned a lot this way and was able to adjust my approach for future opportunities.

I hope some of these resonate with you! Job searching can feel overwhelming, but taking a more targeted and personalised approach made a huge difference for me.

I’m seriously thinking about jumping into a coding bootcamp soon with summer coming up and wanting to use that time, and I know quite a few of you might be in the same boat. Before making such a commitment especially if it involves your money, you should ask what you're exactly getting into, here’s what I’ve got so far:

What does the curriculum look like?
You want to know what I’ll actually be learning. Some bootcamps focus heavily on front-end stuff, while others might be all about back-end or full-stack. "Are the projects hands-on?" "How many real-world projects will I complete?"

Who are the instructors?
It’s so vital to know who will be teaching you. "What’s their background?" "Have they worked in the industry?" "Do they have any teaching experience?" I think it helps to learn from people who really know their stuff.

What’s the job placement rate?
I’ve noticed that many bootcamps boast about high job placement numbers, but you still need to search up reviews. "How many grads actually land jobs in tech?" "What kinds of support do they provide for job hunting?"

Are there any prerequisites?
Some bootcamps expect you to have a little coding knowledge before joining. you want to make sure you're clear on what’s expected, so you're not blindsided!

What kind of support is offered?
you should value mentorship, so it’s important to know what kind of support you’ll get during and after the bootcamp. "Will there be one-on-one help?" "Networking opportunities?" "Access to alumni for advice?"

How is the bootcamp structured?
you want to know if it’s full-time or part-time and whether classes are in-person, online, or a mix. This is really important for fitting it into your life.

What’s the community like?
The people you learn with can make a huge difference in your experience. "Is collaboration emphasized?" "Are there student-led groups or meetups to connect outside of class?"

What do alumni say?
Hearing from grads can really highlight what to expect. "What have their experiences been like?" "Are they happy with where they ended up after the bootcamp?"

Does this fit with my career goals?
Last but not least, you want to ensure that the bootcamp aligns with what I ultimately want to achieve in your career. "Are there specializations that cater to my interests?"

On a side note, you can use Perplixity (or any other research assistant chatbots that give you the resources that it used to give you an answer) and have him answer these questions regarding a specific bootcamp.

Hey everyone,

I wanted to share some strategies that actually made a difference for me when it came to searching for a job, you might've seen some of these already but I hope they help !

First, go beyond job boards, While platforms like LinkedIn and Indeed are great, I found that sending speculative applications directly to companies of interest yielded surprising results. Instead of waiting for a job to be posted, I researched companies that aligned with my values and goals, then crafted tailored emails showcasing how my skills could benefit them. I focused on smaller companies or startups where the hiring process might be less rigid. On one occasion, I reached out to a company I admired, even though they weren’t advertising roles, and ended up getting a meeting for a position they were considering creating.

Engage with company cultures, while researching companies, I paid close attention to their culture and values, especially through their social media and employee reviews. I made a habit of following companies on Instagram or Twitter to see how they interacted with their community and the type of content they shared. When I applied, I incorporated these insights to tailor my application and interviews. For instance, I referenced a community initiative they had recently launched and suggested how I could contribute based on my previous volunteer experience. This not only made me feel more engaged in my applications but also allowed me to demonstrate genuine interest in the company.

Network Beyond LinkedIn, networking doesn’t have to be confined to LinkedIn. I started attending local meetups, webinars, and even workshops related to my field. These events were often smaller, allowing for more intimate conversations. I found that approaching someone during a casual break or after an event led to more meaningful connections than those I’d sent requests to online. Plus, the conversations felt more genuine and often resulted in referrals or insightful advice specific to my situation.

Showcase your skills over resumes, instead of solely relying on my resume, I created a portfolio website that showcased my work, side projects, and expertise. This was particularly effective in creative roles or tech-focused positions. Many employers were impressed and took time to explore my projects rather than only skimming through a traditional resume. I also included a blog section where I wrote about industry trends or solutions to common problems in my field.

Try to experiment with micro-Internships, I started pursuing short-term projects or micro-internships. This approach allowed me to gain relevant experience and build my network while still job hunting. Apps like Handshake and even local community boards often have listings for these kinds of gigs. Not only did I expand my skill set, but I also met people who later referred me for full-time roles. These shorter commitments can help fill gaps in your resume and give you talking points in interviews.

Seek mentorship wisely, while having a mentor can be valuable, I learned to be strategic about seeking mentorship. Instead of looking for one “perfect” mentor, I reached out to several people for specific questions or advice, creating a mini-board of advisers for my job search. This approach allowed me to gain diverse perspectives and insights without putting pressure on a single relationship. One mentor even helped me prep for a specific interview by conducting a mock where we role-played potential questions I hadn’t considered before.

I hope some of these can help you as you navigate your job search, don't loose hope if you feel stuck, thousands are going through the same thing just believe that it'll all work out in the end.

​

Hey! Having spent some time in the tech industry, I’d like to share some advice that I wish I had when I was starting out. Whether you’re a new graduate, a career changer, or someone looking to advance, these insights might help you navigate your journey.

Master Git and version control: If you haven’t already, become proficient with Git. Understanding version control is crucial for collaboration. Start contributing to open-source projects on GitHub. Not only does this improve your Git skills, but it also showcases your work to potential employers.

Pick a framework and stick to it: In web development, pick a popular framework (like React, Angular, or Django) and master it thoroughly. Build real projects that showcase your understanding of that framework. Employers often look for depth in a specific technology rather than superficial knowledge of many.

Get comfortable with API integration: Learn how to work effectively with RESTful APIs. Create small projects that consume public APIs (like the Twitter API or a weather service). This practical experience is invaluable, as most applications rely on integrating various services.

Understand databases: Learn SQL and how to interact with databases. Build simple applications that store and retrieve data. Familiarity with both SQL (like PostgreSQL or MySQL) and NoSQL (like MongoDB) databases can set you apart, as many companies use a mix of both.

Code reviews are your friend: If you’re in a job, actively seek feedback on your code through code reviews. Learn to also review others’ code. This process teaches you different coding styles and practices and helps you grow tremendously as a developer.

Create and share side projects: Develop side projects that align with your interests or solve a problem you’re passionate about, having tangible projects on your resume shows initiative and practical skills.

Learn the basics of devOps: Understanding the basics of CI/CD (Continuous Integration/Continuous Deployment) and containerization (like Docker) can be a huge advantage. Familiarizing yourself with DevOps practices demonstrates that you can deliver code efficiently and responsibly.

Always make sure to stay informed!

Follow tech news and blogs like TechCrunch, Wired, or Hacker Noon. Understanding industry trends can help you make informed career decisions and allow you to engage in professional discussions with confidence.