Essential Guide to Take-home Coding Challenges

Johdanto

Hei, olen Jane. Kirjoitin tämän oppaan, koska haluan auttaa muita, joilla ei ole perinteistä taustaa, menestymään kotikoodauksen haasteissa. Lue se, tee muistiinpanoja, käytä materiaalia ja ilmoita minulle tuloksistasi. Voit tavoittaa minut sähköpostitse osoitteesta [email protected]

Tämä opas on tarkoitettu kaikille, jotka ovat saaneet kotikoodauksen haasteen osana teknistä haastatteluprosessia ja haluavat hyökätä siihen parhaalla mahdollisella tavalla. Tämä Essential Guide on tislattu versio pidemmästä Ultimate Guide to Take-home Coding Challenges -oppaasta, joka menee paljon yksityiskohtaisemmin ja käy läpi esimerkkihaasteen alusta loppuun.

Joten, jos olet juuri saanut haasteen ja haluaa aloittaa, aloita tästä ja tutustu sitten täydelliseen oppaaseen, kun haluat oppia materiaalia syvemmälle. Onnea!

Virheitä, joita ei tarvitse tehdä, kun työskentelet kotona tapahtuvan koodauksen haasteen parissa

Koti-haasteissa voi tehdä useita virheitä. Jotkut näistä ovat pieniä virheitä, jotka on helppo korjata, kun taas toiset jättävät sinut turhautuneeksi ja kykenemättömäksi suorittamaan tehtävääsi. Haluan korjata nämä virheet ensin, joten kun sinulle annetaan kotiin haastaminen, tiedät tarkalleen, mitä ei pidä tehdä.

Tässä on neljä virhettä, joita voit tehdä:

1. Ajanhallinta ja soveltamisala hiipivät

2. Yritetään oppia liikaa uusia asioita kerralla

3. Liian monien oletusten tekeminen

4. Aloitetaan koodaus heti

Katsotaanpa kutakin yksityiskohtaisesti.

1. Ajanhallinta ja soveltamisala hiipivät

Ajan arviointi on yksi vaikeimmista ohjelmoinnin ongelmista, ja jopa kokeneet insinöörit kamppailevat sen kanssa. Tämä tuo mukanaan kotiin haastamista muutamalla tavalla.

Ensinnäkin joihinkin haasteisiin liittyy "arvioitu aika". En yleensä sivuuttaa näitä, koska ne perustuvat harvoin todellisuuteen. Toiseksi jotkut haasteet ovat avoimia. Monet ihmiset, varsinkin uudemmat kehittäjät, haluavat lisätä paljon ominaisuuksia, koska heidän mielestään se on vaikuttava. Oikeastaan ​​se on vaikuttavampaa, jos pidät soveltamisalaa suhteellisen kapeana, mutta saat kaiken päätökseen tekemäsi. Tässä tilanteessa on parempi tehdä yksi asia todella hyvin kuin tehdä miljoona asiaa huonosti.

Hyvä kysymys olisi: mitä lasketaan "ylittämiselle ja ylittämiselle" verrattuna "laajuuden hiipimiseen"? Nyrkkisääntöni olisi, että jos ideasi saavuttaa tai parantaa tehtävän vaatimuksia, se on todennäköisesti hyvä idea, mutta jos se näyttää tangentiaalisesti liittyvältä tai "vain siistiltä", se on todennäköisesti hiipivä. Mutta kuten kuvaan myöhemmin, saat aina sen toimimaan ensin.

2. Yritetään oppia liikaa uusia asioita kerralla

Vaikka kodin koodaamisen haaste voi olla erinomainen mahdollisuus oppimiseen, on mahdollista ottaa liikaa oppimista. Jos sinulle annetaan haaste, jossa sinun on käytettävä tiettyä kieltä tai kehystä, mutta et ole perehtynyt siihen, älä lisää monimutkaisuutta asettamalla oppimaan jotain uutta sen lisäksi. Esimerkiksi, jos käytät uutta taustakehystä koko pinon sovellukseen, pidä kiinni käyttöliittymäkehyksestä, johon olet jo tyytyväinen.

Jos haasteesi on kieli / kehys-agnostinen, mutta olet halunnut kokeilla uutta tekniikkaa, valitse JUST ONE kokeilemaan. Asiakirjojen lukemisen, haasteen asettamisen ja uuden syntaksin totuttamisen välillä sinulla on kädet täynnä. Jopa yhden asian oppiminen syö paljon aikaa, joten suosittelen, että rajoitat itsesi vain yhteen uuteen tekniikkaan haastetta kohti.

3. Liian monien oletusten tekeminen

Kehittäjänä, jos teet liian monta oletusta, sinun on pakko rakentaa sovellus, jossa vaatimukset eivät täyty tai käyttökokemus on huono. Kun koti-haasteelle annetaan joukko vaatimuksia, käytä AINA aikaa tarkistaa vaatimukset ja varmistaa, että ymmärrät ne täysin. Ja jos sinulla on kysyttävää, kysy aina.

Ensinnäkin tämä osoittaa, että olet valmis pyytämään apua, kun et ymmärrä jotain, mikä on tärkeä piirre kehittäjälle osoitettavaksi. Toiseksi monet yritykset antavat sinulle tarkoituksellisesti epämääräisiä tai täysin täyttämättömiä tuotevaatimuksia, jotta näet, miten reagoit näissä tilanteissa. He todella testaavat kykyäsi ymmärtää vaatimuksia, joissa voi olla aukkoja.

Joten, jos olet epävarma, esitä kysymyksiä. Kysymysten esittäminen on myös merkki siitä, että olet mukana ja kiinnostunut haasteesta.

4. Aloitetaan koodaus heti

Viimeinen virhe, jonka voit tehdä, on hypätä sisään ja aloittaa koodaus heti. Takaan, että jos teet tämän, tulet katumaan sitä. Miksi? Kaksi syytä:

Ilman asianmukaista suunnittelua koodisi kärsii

Järjestelemättä ensin ja varmistamalla, että ymmärrät KAIKKI tekniset vaatimukset, saatat löytää itsellesi puuttuvia reunakoteloita tai kirjoittaa osan toiminnoista uudelleen. Tiedän, että se näyttää vasta-intuitiiviselta, mutta säästät itsellesi aikaa, jos suunnittelet eteenpäin.

Pyörität pyöriäsi yrittäessäsi saada sovelluksesi oikein

Erityisesti uudemmille kehittäjille sovelluksen alkuasennus voi olla yksi vaikeimmista osista kotiin viemisen koodaushaastetta. Se ei ole jotain, jota teet päivittäin, joten usein tarvitaan jonkin verran tutkimusta ja asiakirjojen lukemista, jotta tutustut prosessiin ja varmistat, että jatkat sitä parhaalla mahdollisella tavalla.

Joten, sinulla on se - yhteenveto virheistä tekemisen välttämiseksi. Tulet huomaamaan, että monet näistä koskevat myös päivittäistä työtäsi kehittäjänä. Seuraavassa osiossa kerromme tarkemmin organisoinnista ennen yhden koodirivin kirjoittamista.

Järjestä: miten suunnitella ennen koodirivin kirjoittamista

Nyt on aika päästä töihin! Mutta EI ole aika kirjoittaa mitään koodia.

Miksi?

Koska kuten näette, paljon työtä tapahtuu ennen kuin kirjoitat yhden rivin koodia. Tämä saattaa tuntua epäluuloiselta, mutta jälleen kerran - mitä enemmän aikaa vietät etukäteissuunnitteluun, sitä vähemmän aikaa vietät koodin kirjoittamiseen.

Joten nyt sinulla on koodaushaaste käsilläsi ja olet valmis aloittamaan suunnitteluprosessin. Tässä ovat kuusi ehdotettua vaihettani:

1. Ymmärrä vaatimukset ja kysy kysymyksiä

2. Tunnista tekemäsi tekniset päätökset

3. Tekninen suunnittelu ja valkotaulu

4. Testisuunnitelma

5. Sovelluksen asennussuunnitelma

6. Järjestä tehtävät

1. Ymmärrä vaatimukset ja kysy kysymyksiä

Ensinnäkin sinun on varmistettava, että ymmärrät täysin, täysin, 100% projektin vaatimukset. Jos jokin vaatimuksista on epäselvä, sinun on voitava ottaa yhteyttä yhteyshenkilöösi ja esittää kysymyksiä.

Joskus yritykset tekevät tarkoituksellisesti epämääräisiä saadakseen selville, miten lähestyt ongelmaa. Näissä tapauksissa on aina parasta esittää kysymyksiä, koska se osoittaa, että ajattelet ongelmaa eikä vain tee oletuksia ja rakenna sovellusta epämääräisiin ominaisuuksiin.

2. Tunnista tekemäsi tekniset päätökset

Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time.

3. Technical design & whiteboarding

Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes:

  • You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes.
  • Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions.

Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources.

4. Test plan

Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later.

5. App setup plan

If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly.

If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck.

6. Organize your tasks

The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road.

Here is an example task list for a classic Tic Tac Toe app:

- Understand requirements- Choose technologies- Brainstorm test plan- Hello World app setup- Build board with HTML/CSS- Implement Tic Tac Toe gameplay with Javascript- Add reset button- Make board responsive- Add ability to add additional boards- Error handling & tests- Code cleanup- README

Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks:

- Add a click handler to each square that logs a message- Get click handler to add an X to the square that is clicked- Get clicks to alternate between X and O- Don’t allow a square to be clicked more than once- Implement a function to find the winner and end the game- Handle a tie game

3. Writing tests: just do it!

Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing.

Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine.

First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook.

Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more!

How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases:

1. Test the happy path

For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins.

2. Think about variations on the happy path

A variation on the happy path would be if O wins, or if there is a tie game.

3. Think of edge cases

An edge case would be if a player tries to play a move in the same square more than once.

4. Test anything that is complex

The algorithm to find the winner is the most complex part of this example.

Here’s a sample test plan:

- Test that the initial state of the board is correct (i.e. board is visible and empty)- Test that a move can be played- Test that moves alternate between X and O- Test that a move can be played to a square only once- Test that a winner can be found in a row- Test that a winner can be found in a column- Test that a winner can be found in a diagonal- Test that a draw can be found

So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write.

4. Make it work, then make it pretty, then make it fast

The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER:

1. Make it work

2. Make it pretty

3. Make it fast

1. Make it work

When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else.

This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components.

So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization.

Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing.

2. Make it pretty

Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it.

If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature.

For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks.

3. Make it fast

Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy.

You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long?

If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things.

How to make your code shine

When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine.

When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files.

There are several things you can do to make your code stand out. You want your code to be:

  • Readable
  • Easy to follow
  • Well organized
  • Clean (properly indented, free of syntax errors and unnecessary whitespace)

These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations:

1. How to name things

2. How to use comments effectively

3. How to format your code as you write it

1. How to name things

Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand.

For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick.

One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them.

2. How to use comments effectively

Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it.

Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments.

Here is where you most likely do not need comments:

  • When you declare a variable
  • When you declare a function

Don’t do this:

The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name!

Here are some examples of where comments can be useful:

  • HTML
  • CSS
  • Technically tricky lines of code

First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of iv>s. Comments can be a good way to signal which tags close which sections.

In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update.

Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application.

One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment.

You are almost done learning how to make your code shine! Just one more step.

3. How to format your code as you write it

I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal.

So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything.

  • Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others)
  • Indent your code properly as you go so that it stays readable and isn’t all over the place
  • Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code.
  • Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it!
  • Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app.
  • Always leave a newline at the end of every file

That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward!

Here’s an example of badly formatted code:

Here’s an example of the same code, but cleanly formatted and MUCH more readable:

How to take your challenge to the next level

Here are 3 ideas for how you can take your coding challenge to the next level:

1. Bonuses

2. UI/UX design (for front-end or full-stack challenges)

3. Data validation and error handling

1. Bonuses

Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer.

2. UI/UX design (for front-end or full-stack challenges)

Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it.

3. Data validation and error handling

Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations.

How to write an awesome README

You may be done writing code, but you’re not done writing yet — it’s time to write your README.

Why you should include a README

READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation.

Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games.

Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge.

How to write your README

Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include:

1. Installation instructions

2. Discussion of technologies used

3. A section demonstrating that you met the requirements

4. If there are bonuses, a section demonstrating that you met them

5. For algorithms and data structures, time and space complexity

1. Installation instructions

When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README.

2. Discussion of technologies used

This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs.

3. A section demonstrating that you met the requirements

Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it.

4. If there are bonuses, a section demonstrating that you met them

Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work.

5. For algorithms and data structures, time and space complexity

If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation.

One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer.

Here is an example README for a Tic Tac Toe app:

Final steps before you hit send

Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist:

  • Re-read the take-home challenge instructions to make sure you didn’t miss any requirements
  • Review your app’s code to ensure that it shines
  • Run your app’s automated tests and make sure they are all passing
  • Test your app manually and make sure everything is working properly
  • Test your app installation instructions from your README
  • Start an email draft and copy your README into it for convenience
  • If requested, make sure to attach a zip file of your code
  • Write an email to your contact at the company

Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example:

Hi ,
I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions.
Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at , so I’m looking forward to hearing from you!
Thanks,

Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time.

Now, finally, hit send!

Conclusion

I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at [email protected]

Also, if you enjoyed this guide and want to learn more, feel free to sign up for my email list: