Senior front end dev here, ask me anything!

Hey Shivanand,

I think the best advice is to start small and build up. Play to your strengths and how you like to learn and don't overwhelm yourself.

I see too many new developers become desperate to learn every single thing out there; they do a million courses and videos, and they're simultaneously trying to master HTML, CSS, JS and then bounce straight into Vue, React, and start slapping back end things in there and databases.

Focus on the basics: HTML, CSS, JavaScript. Find one or maybe two different courses that you like and stick with them.

I always recommend Free Code Camp to people because it's free, it's well structured and you'll get a well-recognised certification at the end of it.

Oh, and like any skill, you have to practice! If you're learning about HTML forms, build a couple outside of the lesson and see how you can adapt them. If you're learning about Promises in JS, try building a few different mini-apps that use them.

I think it's important to know the boundaries and limitations of the scope of your role, but I think the design and development worlds are a series of large Venn Diagrams where there are a lot of overlaps depending on where you sit within your role.

But either way, I think it's useful to have at least some level of knowledge and understanding of UX, UI design, and wireframing/mockups, both the tools involved and the processes.

At the end of the day, design, UX/UI work and mockups/wireframes are all different means of communicating ideas. The more understanding you have, the easier you'll be able to communicate with your team, your users, etc.

I've given a pretty comprehensive structure answer in one of the other threads on here, so check that out 😊👍🏻

But generally, it's about not writing more than you have to and sticking to DRY (Don't Repeat Yourself) and KISS (Keep It Simple Stupid) as much as possible. Components and utilities should have single responsibilities and break longer components into smaller, reusable ones. I also like to abstract as much as possible to avoid needless repetition.

Emma Bostian and I are talking about this very thing on Monday’s The Front End podcast (thefeontendpodcast.site).

It’s not absolutely necessary, no. However, it depends on what you’re doing and the company you’re working for (or want to work for). There are lots of top devs who don’t come from a CS background and don’t have that knowledge of data structures and algorithms.

That said, you can always learn the basics or gain a little exposure via something like Free Code Camp.

I’m going to hold my hands up here and admit I don’t have enough experience to recommend anything here. D3 is super popular and probably for a reason.

But, happy to open the floor here if anyone can help answer this for you?

It depends on the project and how it’s structured and things like are you using approaches like css-in-js or utility css.

But, in general, for larger teams with large, complex projects, I think you want a few things in place:

1. Agreement or consensus on how we’re tackling styling in the project
2. Some sort of design system that defines how certain UI elements will be styled (usually as a result of 1.)
3. Lots of clear documentation on how we write the styles, using what approach, and methodologies
4. Use linting to highlight deviations away from agreed guidelines before committing the code
5. Code reviews to make sure everyone’s happy with new code being submitted

In terms of scale ability, I think that’s where utility-driven css (e.g. Tailwind) is quite helpful. But really, keeping things as simple as possible means you don’t end up in a styles soup where you’re fighting specificity and the cascade

I see this question a lot (or a variation on it), and unfortunately the answer really is 'it depends'...

If you're aiming for a role that's very React heavy, then you're going to need at least some exposure to it. Do you absolutely need to know React or Gatsby? No, not necessarily. For example (although my website uses it), I don't have much experience with Gatsby. It's a specific tool for a specific job and I've no use for it (at the moment) in my day to day work. There's nothing to stop me learning it, but if I don't use it then I know that knowledge will be lost to me.

I think hireable developers are flexible and adaptable. Having some exposure to different frameworks and toolsets will help you in the long run, but you don't necessarily have to learn absolutely everything out there, and in so much depth.

I think, ultimately, having a solid level of knowledge and experience in JavaScript will stand you in much better stead than doubling down on a particular framework. After all, even React is just JS, right? It has it's own quirks and ways of doing things, but it's all JS. It's easier to pick up a new framework (e.g. Vue) if you have a solid foundation.

Great question!

In a nutshell, for me, it's about the knowledge and experience in designing and building successful, accessible user interfaces, using a variety and combination of the right tools for the right job.

However, I think people get bogged down in talking about the tools that define the term, rather than the role, i.e. what it is the front end developer needs to achieve.

We've talked in this thread about changing the term and because the tools involved in modern front end are blurring a lot, the title itself almost needs to become something like 'user-driven developer' or 'interface developer' — something beyond this idea of a 'front end'.

But think about it in terms of other jobs out in the world, like, say a plumber. A plumber deals with your waterworks and pipes, right? We don't talk about, 'oh, you have to know how to use a blow torch, or this shiny new spanner to be a plumber' do we? We talk about the processes and skills involved instead.

Development is such a broad collection of venn diagrams to me, all overlapping, and you can choose where you live in those diagrams depending on your passion, depending on your role. You absolutely can be a FE dev without touching a line of CSS, but you're likely going to be fairly niche. Similarly, you can be a successful FE developer that specialises in HTML and CSS, but with fairly little JS. It all depends on what your doing...

Without trying to shirk the answer, I’ve answered that kind of question a few times in the thread.

Have a read through and you’ll find it ☺️ But it comes down to experience and leadership duties for me.

That’s a lot to take in so let me fire some quick answers at cha:

1. Structure wise, I don’t overthink it. Just get started, you can always change it. I like to keep various assets together, styles in their own folder, and separate out by areas of responsibility. So I have a helpers folder, constants, components and dat handling.

2. For complex react projects, I lean on react router, and the redux toolkit for state management.

3. I’m familiar with the event emitter pattern and have used it in the past. But I’ve not found too much place for it in React projects I’ve been a part of, especially with Redux. I do, however, like to introduce data handlers as middle men that handle interaction between the API and Redux. This reduces complexity in my controlling components.

4. I don’t like css-in-is. It muddies the waters for me; maybe I’m too old school. However, that shouldn’t stop anyone from trying it and seeing if it’s a fit for them. I hear good things about Styled Components (for React)

Nothing in particular but you might also be applying for the wrong jobs. If they’re all measuring standards by abilities on HackerRank then the company is going to miss out on a lot of potential.

I’m talking with Emma Bostian about this on Mondays podcast episode (The Front End, check it out!). All about the technical interviews.

From a more practical point of view though, take the failures as opportunities to learn. It sounds like you have some good experience behind you but if you’re having trouble around algorithmic tests, that’s something to work on. If you’ve not come from a CS background (I haven’t either), then you can miss out on those sorts of areas of knowledge.

Take some practice tests, find out what gaps you have and learn learn learn. Take the tests again and measure how you’ve improved. ☺️👍🏻

You got this!

I actually started full stack. I was a C# dev and made e-commerce sites in asp.net 2.0 with good ok’ MS SQL Server.

I’ll be moving back to a full stack role shortly where it’ll still be very JavaScript heavy but with React on the front, Node, and all the goodness AWS has to offer ☺️

It’s not always clear cut but I would say a junior is someone at the start of their career. They have less experience. It’s not all about knowledge, but they may have less overall experience in a number of areas and are just starting out. They need more guidance and mentoring.

Mid-level is your average developer. They’re comfortable in their role and can function more autonomously but don’t have more managerial or team leading responsibilities and perhaps don’t have any decision making power.

Seniors I would say are more experienced developers with some leadership duties and decision making power.

They’re just titles at the end of the day and there is overlap of course that blurs the lines a little.

Ooo now that's a tough one. So, in essence, the MVC model is Model, View, Controller, where 'Model' is the data model or shape of the object that the 'Controller' (which usually accepts some sort of input or otherwise processes a request) provides to the 'View'.

In terms of structural stuff, I'd look to start small, with one aspect of the API and break it down into the component parts. So, what should the controller do when we hit something like '/users'? Then, if it should return a list of users, what should the data model of a 'user' look like? Take that approach and build on it. Starting is the hardest part, sometimes because the task seems enormous, partly because we want it perfect from the start.

Don't be afraid to ask for help internally for advice on that too. Ideally, you should have some senior devs who will be willing to help guide you and share their knowledge, especially if they've got working knowledge of the API you're dealing with too 😄

There's also a good article on Sitepoint that walks through building an MVC-based Node app that might give you some direction.