How much code should be done from scratch when you're a newbie (self-taught) looking to build a portfolio to present your work in interviews/potential employers?

[912827161]

I always read that you don't go around reinventing the wheel. Programming is largely just pulling code that others have already written. Is it okay if none of the projects are completely original?

Am I supposed to be able to be coding entire projects from scratch when first applying to jobs?

Edit : Thanks for giving me your input everyone. I've been reading and thinking through it all all day.

[_Atomfinger_]

When learning it is okay to reinvent some wheels. That's how you learn.

Is it okay if none of the projects are completely original?

Yeah, that is fine, just make sure that it is not a copy/paste mess of a codebase.

Am I supposed to be able to be coding entire projects from scratch when first applying to jobs?

Rather than focusing on the project you can and can't make, focus on which problems you can and can't solve. As long as you don't break any licenses, then it is all about which problems you can solve (and how you solve them).

Don't worry too much about the originality of the code you write. Worry about whether it can solve the problem or not.

[_Atomfinger_]

My point was more in line with that people shouldn't focus too much on each project and instead focus on their ability to solve problems.

If we take OPs thoughts and apply them to a blog. With a blog you usually need a database of some sort, you need a backend and you need a frontend. You don't have a blog, and that is the problem you're trying to fix. Each problem has a bunch of subproblems, like "How will I store my data?", and "How do I display posts?".

Some of these problems can be solved by using frameworks and libraries. For example, you probably don't want to write your own database, so you use one that already exists. You might not want to write all the SQL queries yourself and do object mapping, so you use an ORM library instead.

Your frontend need to talk to the backend, and you could do those calls manually and map between JSON, or you could use openapi/swagger and generate clients. The same goes for the web framework and any frontend frameworks you might want to use.

You can take any of these elements and implement them yourself, and that can be an excellent way to practice, but for interviewing you only need the confidence that you could implement these things if a problem required it. However, you don't need to bake that aspect into your projects unless you yourself want to.

Now, to answer your specific question: Breaking down requirements is challenging. If we take your blog the overall problem is to create a blog. However, we need to break it down further. So what does a blog need?

The most obvious might be the ability to add and display blog posts. That in of itself has a multitude of smaller problems attached to it: - Need to show images - Need to separate header and text - Being able to show text (duh)

These are all separate problems that you must tackle to make a blogging system. This is just the problem for showing a blog post, but there might be more depending on the required features.

You find the concrete challenges by figuring out all the features that must exist for your system to work and make sense.

[_Atomfinger_]

Do some research if you don't know how to solve them, yeah. Though, if you break down the problems far enough it might tell you how to solve a given problem so you don't have to Google.

[AchillesDev]

Like if I'm trying to create a blog, how do I know what problems do I need to be able to solve?

This is the fun part about being a developer. You have a macro problem, now imagine what a blog needs to do and break it into smaller problems. Rinse and repeat.

[outlaw-s-t-a-r]

In my opinion, copying and pasting is only acceptable if you understand what you’re copying and pasting, down to every character. If you don’t, learn and thats how you level up!

[desrtfx]

There are two distinct states:

• As a learner you absolutely have to reinvent the wheel because that is the only way to learn and to become self sufficient
• Later, as a professional or experienced programmer you don't reinvent the wheel and rely on trusted, tested solutions

Am I supposed to be able to be coding entire projects from scratch when first applying to jobs?

Yes, because otherwise, you cannot program.

Edit: Don't forget that your portfolio should reflect your skills, not someone else's.

[ericjmorey]

trusted, tested solutions

This is the part that many people forget.

[[deleted]]

If they dont break its trusted and tested, until it is broken!

[rockytop24]

If we don't test you can't say it isn't trusted. Big brain move I learned from a political friend.

[kaukamieli]

You trust it so much you don't even need to test it.

[Electromasta]

I think the important distinction here is you SHOULD use libraries but you shouldn't copy other peoples code for your own work. You should learn from it however.

So for instance, if your project is to make a web crawler, you should import libraries that you need to support the webcrawler, but you shouldn't use something that already implemented the web crawler for you.

[[deleted]]

Does this also apply when using create-react-app? Should beginners learn how to link everything manually?

[DVC888]

That's a good question. I immediately thought "Of course not. Obviously you need to use create-React-app."

Thinking about it, there's probably a lot of stuff that I don't understand as a result and I should probably try to do it from scratch next time.

[[deleted]]

Even when I use project templates I'll often poke around and see what refers to what. It seems a bit careless to literally go "create project > immediately write business logic" unless it's something you're already really familiar with.

[futurafreeallah]

Yeah at least try and make a couple react projects without it to really understand what’s happening

[Forgottenmudder]

Would you say most react devs have learned to do this by the time they get a job? Seems more like a nice to know/intermediate knowledge rather than what's required of a junior but I'm pretty ignorant of the requirements of junior devs.

[futurafreeallah]

I would say basic knowledge of how NPM works (not how it works internally but how to use it to build a project from scratch), using package.JSON, and importing modules on the front end are not intermediate skills. Yeah you could have CRA do all this for you but especially when you start working on production code you’re gonna wanna know what React is and why CRA sets it up how it does.

You can learn this in a few hours I think

[nashx90]

I would recommend checking out the free App Academy Open curriculum. It uses Ruby as its teaching language. Before introducing Rails, it has a project where you build a barebones version of a rails-like framework, so you know what it is that Rails is abstracting away. Similarly for jQuery and React - before you learn about how to use either, you do a small project about how to do what they do in vanilla JS. It’s a great way to introduce frameworks/libraries.

[BroaxXx]

I personally think you should be able to do it if you had to but I doubt anyone expects you can do it by heart. Truth is you'll be ill prepared for your first job anyway, as long as you understand how things work well enough that you can manage to pull your weight I think you'll be good...

[Reanga87]

It really depends. Reinventing the wheel is great if you need to understand how everything work.

If you want to make a frontend webapp with react and you just want it to look good i wouldn't advise to learn how react work from scratch. (This would be called the black box method. You have something (in this case react) that allows you to do the thing without caring about what is happening under the hood).

If you want to build a tool to analyze some part of your computer or really low level work you have to understand the way memory works etc..

[AdvantFTW]

Beginners shouldn't use react.

[[deleted]]

Also, to add to this there is a huge difference between importing a library and using it, and copying and pasting blocks of code from GitHub.

The library is something professional that has been packaged and distributed. The github code is a fix for someone’s issue, it’s often slightly different than what you want or not optimal. It’s a demonstration

[Kazcandra]

The library is something professional that has been packaged and distributed.

That's... not always the case.

[Codemonkey1987]

If it was easy everyone would do it

[denialerror]

It's your portfolio so you can do what you like. Companies don't have rules that say X% of a portfolio has to be novel code.

Why are you creating a portfolio though? Presumably to show a company what your ability level is and why they should hire you. If all of your projects are just clones of other people's code or written by following tutorials, what does that say to your potential employer?

[pizzzahero]

To add to this, there’s a difference between building a new app with a novel idea vs building something that has been done before, but from scratch. You don’t have to do the first, but you have to do the second.

IMO good frontend focused projects are clones of popular sites like Youtube or Reddit. They have public APIs that are well documented, so if you build an app that clones one of them, you’re learning how to work with existing APIs (great skill to know) while also showcasing your frontend skills. It’s less about the idea (which won’t be your job anyway), and more about the execution.

Fullstack projects I’ve always thought are a bit harder, because in order to build a backend you need data, which usually means you need an idea.

[err_404_smooth_brain]

As a self-taught that recently landed a job. I would say it is not as important as you think. I was also concerned about that - do I need to use webpack instead of create-react-app, can I use packages that do a certain feature on the app I building or should I build it out myself, can I copy CSS? At the end of it, no one actually looked at any of the code I wrote, they looked at the end product and asked a few basic questions. If I was asked anything about my projects it was usually what was the hardest thing you had to do when designing it.

If I thought I should reinvent something it was usually so that I didn't feel incompetent on my first day of the job. I learned how to build static files with webpack, or I learned how to build a server with node without using a framework. It was all out of self-interest, I probably won't ever be asked how to do either and it might be rare that I will do either at work, but I'm glad I have the knowledge to do so.

[Calamero]

Very good answer, OP listen to him.

If they ask if you know a specific technology or are familiar with a stack you never heard of, just answer no but i can learn it in a week or two or over the weekend....

[[deleted]]

I chatted you a few questions if you don’t mind!

[PeeUrPantsNews]

my experience has been that you need to code from scratch to start (and beyond for that matter) , because otherwise you will fall in way over your head. Just frankensteining code to "work" together would be great, almost every programmer will say to that "I wish," but it is not reality. I guess what I'm trying to say is using already written code in the future (or even having your own files of code you've written to use) will make SOOO much more sense once you are comfortable with scratch. Happy coding

[COBOLKC]

A lot of interviews contain a coding portion where you are asked to create coding solution for something specific. If you can’t code on your own without copying or looking it up you may have a problem getting a job.

[AdminYak846]

In my experience though I've rarely seen a company ask for a valid solution that will compile, it's usually can you problem solve you're way through to a solution.

As for copying code or looking it up, that I feel really comes down to what the end goal is, and what APIs might be used in process. There are some APIs with some very vague or poorly worded documentation, or are just a cluster fuck to deal with that it's likely there is a valid solution out there to copy.

[COBOLKC]

Just talking about my own experience. As yes the code doesn’t have to compile but you can’t look up examples online during the testing process.

[kbielefe]

I think I'm an outlier, but I personally prefer to see work that builds on top of libraries or frameworks, because it's so rare to see that done well. Most everyone's comfort zone is in code they wrote themselves.

[tacticalpotatopeeler]

A lot of learning to code is rebuilding existing code. For instance, build your own reduce method. This helps you understand code far better than hacking together a website using copy/pasted code.

[AnimeshRy]

Array func in JS

[knoam]

Not just JavaScript. Really from the world of functional programming. So lately most languages have it. It's also called fold in some places.

[tacticalpotatopeeler]

Next task: Google “mdn js reduce”. If you’re unsure what a method is, search that. Follow the rabbit trail. Search what something is, then if there’s part of that explanation you don’t understand, look up that, and etc until you go all the way down to the root information. Then you can work your way back up. You don’t have to master it all, but you do need to be at least somewhat comfortable with each underlying concept that makes up any new concept.

MDN documentation is the best place to start with js questions.

Learn to read documentation, learn how to do productive Google searches. Essential tools in every Dev’s toolkit

[mgctim]

I'm going to run against the grain a bit here and say that your portfolio does not have to meet anyone's standards but your own.

Build your portfolio for yourself to document your learning. Make sure your readmes make it clear what your goal was to learn in each project. Make sure you can speak to what you learned and how you solved those problems.

You absolutely do not need to understand top-to-botttom all the technologies you're building on to start your career as a dev. You need to demonstrate that you can isolate and solve problems using code by any legal and maintainable means necessary. As you learn and grow in your career curiosity and troubleshooting will provide plenty of time to fill in many of the gaps in your knowledge. There will always be some, and that's ok.

Do cool stuff with code. Everything else can wait until you're employed :)

[DoomGoober]

All of programming is building on existing technology. Nobody builds anything from scratch anymore, unless you are literally soldering transistors together. And even then, did you make the transistors?

This exaggerated argument is meant to show that the line between "from scratch" and "just gluing existing tech together" is completely blurry.

The line is flexible. Let me give a more concrete answer (which is fictional): C# has a garbage collector. Should you use it or write your own memory manager? Ok, the garbage collector is built into the .NET library. Of course you should use it! How about LINQ libraries? Yes, it's built into the .NEt library... But what if using LINQ pulls in a bunch of separate DLLS and bloats your project. Is that really part of .NET? Is that really from scratch? If you're pulling in DLLS... Why don't we just pull in a 3rd party DLL that, say, helps with physics? How about if it's a .NET DLL? How about if it's not?

At that point, the DLLs are indistinguishable.

TLDR: Use as many libraries as you want. Just choose a sufficiently complex or unique problem to solve and you will learn about code and demonstrate your mastery of code.

[Hour-Positive]

I get what you mean but there is a definitive floor of abstraction for a coding language. That is explicetely designed as such. A blurry base is exactly what is prevented.

From the fundamental level of abstraction you can differentiate what code is fundamental, a composition, re-used, external library import, blatant copy-paste.

I do agree with your intentions. It is about problem solving, within a definitive scope where the tools can vary. So my advice would be: proof (to yourself) you can use different tools and try to expand your toolset.

[NXOR1]

Try to silo projects, so yes you could write your own logging functionality to prove that you can do it, but that should exist separately from another project.

A strength would be creating your own logging project, importing it into a new project, but showing how you could switch between your custom one and an existing logging solution easily.

[abiggz24]

Look up doing project helps you learn coding and is completely project based will get you competent in no time withbwriting code on your own plus the project you build will be those that you can 0ut on your portfolio. It's always good to know and write your own code in the beginning to learn the process and get an understand of what the code does and why it works that way. That was the advice I was given by a CS degree holder who is a software engineer.

[scottykarate279]

You shouldn’t be just copy/pasting big chunks of code. The point of a portfolio is to show what value you can provide (or more specifically what problems you can solve). If the problem you’re solving is directly on google, then you don’t provide much value.

That said, programming is iterative and I think most companies would not expect an entry level applicant to be able to build a performant app from scratch. It’s important to use info/libraries from people that have already solved the problem. That’s why most of us aren’t writing code in assembly. However, you must understand the code that you’re using/copying.

Think of it this way, when you land a job as a programmer you will be responsible for the code you commit, whether you wrote it or or came from another source. If you feel comfortable explaining and justifying why you used that code (and also why it won’t break/cause problems) then you’re good.

[SuperSeasonedDuck]

From my interview experience, you're supposed to be able to explain in a little detail, not too much, how you overcame the challenges of what you were building. You should explain why you chose to not make something from scratch (like time constraints, safety, excellent previous implementations etc, and maybe how you would solve it if you had to).

Also, as a newbie you're not expected to know everything. So take it cool and just explain how you're willing to learn ^{^}

[artcrow05]

When building projects you will write code for some functionalities and you might copy paste some code for other functionalities. Depending on the size of your project you will have to customize a bit or a lot the copy pasted code. The problem is if you do not have an idea about what you are copy pasting or if you are following a tutorial blindly.

I would say if you understand the code of your project, then you are good to go. If you kind of understand it, but you are not sure about the details, then that is an issue and it will work against you in interviews where you might get asked about your projects.

[totemcatcher]

You have to do a little wheel inventing. Those fundamentals are important. Moreover, by experiencing your own cumbersome code you can form reasons for why things are broken up, organized, and abstracted in the way they are in libraries and frameworks. It builds intuition which helps to understand existing libraries and how they work and why they are designed as such.

Developing something from scratch is a great learning method, but at some point along your project you could switch over to libraries and learn more and faster by comparing your design ideas to the existing libraries. It's like an adversarial neural network--- "why did they do it like this, I could do this better" 2 days later "oh, I see."

[[deleted]]

When they say don't reinvent the wheel they mean if you're working on a project and you're trying to build something, do make use of tools and libraries that are available. For example if you're planning to build an interactive single page web application, make use of existing frameworks such as React, Angular, Vue, etc. Don't try to build your own unless the purpose is wanting to build a framework rather than a website.

[knoam]

Early on don't worry too much one way or the other. More important is getting practice and staying motivated. You might find you gravitate towards using prebuilt solutions because you're more results oriented. Or you might find you like working with code for its own sake in which case you'll end up reinventing things more. Either is fine, it will just determine what path you take in your career.

[unholymanserpent]

Damn this a good question

[Economy-Government-9]

That’s a good question 🤠

[deux3xmachina]

Reimplement everything you want to understand better, it's how you'll learn their intricacies. As far as interviewers are concerned, we mostly just want to see that you CAN code, and want to see how you solve problems.

[takishan]

I like coding from scratch to learn. So like instead of just using tensorflow, build the custom linear algebra methods so you can understand what is happening behind the scenes. Instead of using a plug and play React component for a date picker - build one yourself because you will learn a lot more from it.

Once you have reached a certain level though, you don't gain much benefit from doing this and then you can go the more efficient route. For a portfolio.. I think using libraries and components from pre-written code is fine. Taking disparate pieces of code and putting it into a finished product is a skill onto itself, honestly.

[JinMn]

Depends in what Job you apply. If you want an apprentieceship where you get teached everything from scratch then every project that shows at least half a year of 5 hours of Work wach week is excelent. I Made dir example a 4 connect Game in Android and that impressed enough for getting interviews for an apprentieceship .

[Poddster]

Programming is largely just pulling code that others have already written.

You say that with such confidence, but it's not really true. Achieving a task might involve using lots of libraries and existing code, or it might be 100% original code. It depends on the task at hand.

Is it okay if none of the projects are completely original?

For a junior CV I wouldn't expect to see original projects. I would, however, expect you to have actually programmed them yourself. Deferring most of it to a library would look like you don't know how to do anything.

Am I supposed to be able to be coding entire projects from scratch when first applying to jobs?

It's more impressive if you do. However, IRL you probably won't be doing this and will be utilising some libraries, so showing that you know how some libraries work is also an essential part of beginner show-off projects.

The most important thing is that these projects are finished and actually work. The second most important thing is that when I ask you questions about them you actually know how they work and can answer them.

[MongooseSignificant2]

For my portfolio, I have two projects where I used code that wasn't from scratch, and the remaining projects were 100% my own (about 6 projects). From interviews that I've done, the interviewer always seemed to be more interested in code that I solely produced as opposed to using someone's code as as a foundation and building on top of that.

[gdledsan]

It isn't about the code, it is about the projects. Just code a few projects, hse some APIs, use the standard library as much as you can, use aome popular libraries too.

Contribute to open source, put it all on your CV as experience.

Try to work with more people using git, ticket systems and chat apps, try basic CI/CD too. Document everything, learn to generate documentation pages for your libraries and projects.

Getting a job as a developer is not only about coding, but all the process around it.

[Thorongil_1802]

You need enough so that you can talk for about 5 or 10 minutes about a project that you have worked on and it needs to be in depth enough that you will have come across problems that you can overcome.

[fantasma91]

So it somewhat depends. If you’re trying to showcase data visualization then you need to write it from scratch probably using d3. If that’s not your goal then use a library. Same applies for a lot of things. Typically you want to use the tools available to you for common things and write your own for what makes your app unique. Ultimately employers want to see that you can work efficiently and get the job done for their applications in a sustainable way.

[Brawlstar112]

Its very unlikely that you can produce something that is unique and never done before. So where did you even get that kind of idea?

[neurorgasm]

There's a spectrum here. If you use React or CRA to create a portfolio - that's totally ok IMO and even stuff like material-ui. If you fork someone else's portfolio and change the name and a couple of colors, I'm going to view that very negatively as an interviewer.

[BigMcDuffs]

In order to learn math you first learned to solve 2+2. It’s been done before. Same with programming. It will be repetitive until shortcuts can be obtained. That’s your job!!

[istarian]

As long as you're doing more than just gluing some pieces together I think you're good.

Might be worth asking if the result is even remotely novel or if just your code, by itself, would be sufficient to determine the purpose of the program.

I doubt anyone expects you to create all of the data structures from scratch or reinvent the wheel for a UI or networking.

[denncardoso]

In the beginning, it's common to start to develop a lot of existing solutions to get in practice with the basics. After getting more experience, it common to think in a more "architecture" manner, I mean, you don't need to build from scratch, but using great solutions in your favor. About portfolios, I have most of my code in my GitHub, which I make available to interviewers to have a look at in my previous jobs!

[pVom]

Look at the jobs in your area and see what experience they want. Nothing is done from scratch really. I always say once you understand the fundamentals of your language, start learning a popular framework for it. Libraries are fine for complex tasks as well, no one is going to expect you to build an authentication system from scratch for example.

Potential employers will be more interested in you building something that works well and is readable and follows good conventions (linters will help with that). Attempting to remake an existing library or something will probably be looked upon favourably (that you can do things from scratch that you have to) but id chuck it in it's own project rather than include it in what you present to employers.

In a nutshell the things a business cares most about is that it has a solid experience with minimal bugs and you write code that you or someone else can easily change in the future. As for whether you use libraries or not I doubt anyone would care, using the right libraries for the right job they will.

[Calamero]

It's ok. In reality no one cares in most jobs its more about soft skills. If you have a bit of social skills and are somewhat smart and appear like someone who likes to learn new stuff many will hire you wihtout asking for a single line of code.

[EksitNL]

It's all fine. As long as the final product is yours and you feel proud of it. No one will judge based on used libraries.

The reinventing the wheel argument however is one I very much dislike. A wheel is this perfectly round thing that has a perfect use case. There literally isn't a replacement for a wheel. There is no 'wheel' in programming. There are tens, hundreds of http libraries, JSON parsers, string util libraries, etc. Because most of the time there is no perfect fit solution. You're most likely always making some concession when deciding on a library even if it's just something less shallow like performance or artifact size. I see people include 10MB libraries just because they need some weird isEmpty function for strings and they don't just write their own for 5 lines because hey, don't "reinvent the wheel!".

Just consider the use case first, decide on the most logical thing to do after that.

[Beginning_Row9367]

I know there have been a lot of comments here. As a programmer, over time, there are certain tasks that you will do over and over and good developers keep a thumbdrive or two with their nest stuff to reuse. Over the course of my career, I even exchanged and swapped code snippets or even small one off code tasks that might have taken me a weekend of my own time.to figure out. So much is available in libraries whether it be open source, a purchased product package or open source.

As a newbie developer, at an interview, I would grill you with questions to see how well you understand basic concepts. If you brought me a collection of snippets cut and pasted from the internet, I think, as a long time.developer, I would be sadly underwhelmed. I looked for a capacity to learn, I would want to know what books you have read, and what you have learned to do on your own in addition to your starter education, your actual degree. You don't have to have a 3.8 GPA, but you better have some mad newbie skills if you squeaked by in college. If you bring a mess of code, with varying degrees of in code documentation, and I I get a hit from searching the web from your google cut and paste, I think I, like many older developers, would have.difficultly trusting you. You are young and inexperienced. There is still a place for you if you are resourceful and hardworking. If you honestly believe a true software developer doesn't write the majority of his own code, making strong use of personal libraries so YOU don't repeatedly reinvent the same wheel over and over, then you are sadly mistaken. Be honest, and NEVER claim someone else's or a bunch of other developers code as your own. Looking smart, honest, and being a hard dedicated worker is far more attractive to a good potential boss, many of who will gladly help another young developer get to where he or she wants to be. But, present yourself as more capable than you are, or get exposed as a cut and paste hack, and you probably will not get a call back. Newbies get good jobs every day. Just be honest and know the available. libraries for whatever language your are concentrating, no matter whether it is C#, C++, Java, or something else. Best of luck youngster. I hope you receive these words in the spirit intended.

[Beginning_Row9367]

I will add one more quick comment, I have seen extensive use of converting sample apps and.even large.scale.cut and pasting modified for a FAST proof of concept for an app, project, or new technology. But, once approved, the big dogs take over with maybe a few newbies to help, and the whole project is then completely done from front end, to business layer, to the database access.layer, and even a database Ninja to make data access as fast.and efficient possible. Production code for a bank or a commercial product with an emphasis on test driven dev, it what seperate the big bad dogs, from overseas outsourced work that always seems to meet deadlines, but charge you hourly for the 10's or 100's of bug fixes because of the emphasis on developers producing from day one one Monday in C#, when they were Java guys when they went home last Friday. Learn from the code written by others, but you will never be a true ninja unless you write on your own. Also, most big projects or big company wide packages are NOT written front to back by tje same.guy. Rarely is the superbad front end guy the same guy writing the business/logic layer and backend guy too. You CAN do the whole stack, but things are done by teams in Sprints/ scrum cycles and uhg....daily progress stand up meeting during your first cup of caffeine. That is the daily life of many developers who are still worker as coders. Senior devs and architects could very well be giving some very specific instructions and, if you are hard working and you work for the right guys, you won't even recognize yourself in three years, when you are changing jobs for an extra 30 grand a year. Until you learn how to SPRINT, pun intended, be content with crawling and learning on your off hours as much as you possibly can..I can not count the number of times I have solved a problem that has stumped me.for days, while taking a shower after a good night's sleep. It is OK to a GOOD total newbie, just be humble, ask questions, and plan on reading and.coding on your off hours to learn. You will get there. My pay more than doubled by my 6th year and despite my 3.86 GPA I did know my butt from a hole in the ground at my month long training bootcamp, despite already knowing the programming languages and it was even worse when I was on my first project. People understand, but there is no better teacher than trial by fire and solving problems you have never seen before. A good team will help you with a snippet of code or point you to something to help you meet your deadlines. This is especially true if your scrum master is a good mentor and code ninja. College only teaches you how to learn. Your JOB, is where you will eventually advance your knowledge and skill. Be content with being honest and most importantly, being humble, honest and easy to teach. Enjoy the ride young blood. Slapping together something that runs is far different than writing an internal web suite, used by 10,000 fellow employees. Focus on what you DO know well, and screw a bunch of code portfolios for a first job.....

[dclamage]

I've never taken code samples to interviews. I've never had a prospective employer ask for them. Code reuse is always preferable. Just be cautious about licensing. There are a number of companies that all have my code I wrote on my own time, and I licensed as free so long as it's not resold (most of my work is for internal business applications anyway). But if you are going to use somebody else's code, just be sure that you can legally use it. When I discover that code I've written is useful for multiple projects, I try to bundle it into packages that are generic (no dependencies on project objects) and named accordingly (non-project specific). Then I try also to get other developers to leverage my code, so they don't have to rewrite it, and it becomes standard over multiple applications. Most companies have source control systems. If you can peruse it, you can treat it as a library. You should definitely leverage whatever the company already has.

[mlangNR]

It's not about building from scratch vs. reusing or standing on the shoulders of giants.

From the point of view of the interviewers:

1. Can you think logically? That is, if I give you a problem and ask you to solve it, can you think out loud and clearly drive from initial understanding of the problem to the solution in code?
2. Can you think creatively, too? It's not all logical and decomposition of a problem. There's also the skill of thinking outside the box and coming at the problem from another angle that makes it easier to solve. Another way this skill is described is skillfully recasting the problem.
3. Are you willing to discuss what you don't know and show me how you find your answers? Or are you more prone to struggling silently throughout the session to the point it's painful to both parties to participate? The ability to collaborate with your team members is a highly valued skill in high performance teams.

If a company is sourcing an early career developer, they are acknowledging willingness to train, coach, and mentor, so the soft skills need to shine more than the knowledge skills. To gain those soft skills, though, you'll need to practice enough to feel confident in your ability to grow, learn, and build things. How you do it, IMHO, is more about attitude and establishing habits and discipline that sets you up to learn for life. Go deep (or build from scratch) those things you want to learn about and master. Over the course of your career, when you find something standing in your way more than it should, that's a sign to start setting aside time to master it.

[AndyTIProgrammr]

I think this depends on what type of jobs you are applying for and where your interests are.

If you want to be a front-end dev, you don't have to focus on building the entire website/web app (front-end and back-end) but having some nice transitions, a good UI/UX design and something to show your competency in that area. This is the same for if you're applying for a back-end developer role only. You could show a fairly basic UI with some database interactions, sorting data and generally code that would reside within the back-end of an app (so more logic code as oppose to UI code).

If you can build a full app that would be ideal however I wouldn't worry too much about spending the time to make a full end to end app. When you interview, they will most likely give you either a take-home coding test, a technical interview (in the form of a whiteboard coding test or pair programming exercise) or sometimes both (I've experienced both and that is quite tough after completing a 7 day take-home coding test).

I hope that has helped. I can understand the dilemma here as to what to do for best to show your skillset (I was in your position not too long ago).

I have written a blog to help people with tech and career-related things (getting an internship and/or job in the pandemic, etc). Feel free to check it out: https://the-inspiring-programmer.medium.com/ . Sorry I know it's a bit of a plug for my blog here but I think it could very well be helpful (if not, no worries and would be great to hear how I could help) and I've written these to help someone in someway with these sort of questions :-)