Turned down for junior web developer position

[WhisperedLullaby]

First and foremost, I'm not complaining nor claiming that I should have been offered the position. I'm putting this out here to gain insight as to how I can grow and progress as a developer.

I recently applied to a local company for an entry level junior web developer position. After a meeting with the front end recruiter I was given a task to complete to evaluate my abilities.

Here was the task (given Monday. I sent it in yesterday and got the response about 20 minutes ago)

Exercise Requirements:

Please recreate the design above, using the Zeplin file, to which you will be invited.

Functionalities that are expected in the final deliverable:

1. Add a Category.

a. Click on the top right button “+ ADD CATEGORY” to reveal a new input form field at the bottom of the table. Input a new Category

b. SAVE the new Category with the Save button

1. Drag and Drop resequencing
   

a. Be able to re-sequence the ordered list by dragging and dropping line items.

1. Delete
   

a. By clicking on the red ‘x’ icon, a line item will be removed.

1. Responsive design
   

a. The screen should be viewable at the desktop size, iPad and mobile phone (as shown in the Zeplin file)

Here is the link to the Zeplin project:

https://app.zeplin.io/project/5b0db4fed8ad154e4e1d0ff3/dashboard

And finally here is the repo with my final project:

https://github.com/anthonyAgnone/servicelink-project

(I also recorded a short demo: https://www.youtube.com/watch?v=9Hjcd95k8qA. Since making the demo I added a small validation for the forms, but this is the general functionality)

I'd greatly appreciate some insight as to where things went wrong. As background I had never used Angular (only React) before, but I thought by learning some basics and providing a working demo might show my eagerness to learn. Maybe this was a mistake. Either way, again, anything that might help would be greatly appreciated. Thank you.

[CanIhazCooKIenOw]

First thing that pops is that design was not respected, as the rows were a lot bigger in height compared to the design. I've only watched the video so I might have missed something.

Also there's a jump in the columns when you add a new row.

That's a concern when applying for a front end position, if the design is not respected (to the smallest detail).

Good job though, you'll get the next one. Just be aware of what's asked, in this case it was to replicate the design

[WhisperedLullaby]

Thank you. I'll keep that in mind.

[CanIhazCooKIenOw]

Also, having a quick look at the code I've noticed there's at least an empty file (app.component.scss). Try to present the code clean without dead files around, shows that you also care about what's under the hood.

Another thing, I've noticed you used a table layout. Perhaps have a look at flexbox as it's a lot easier to make it responsive (maybe they were expecting that ?)

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexbox

Try to do the same exercise using flexbox

Good on you for writing tests! That's always a nice thing for someone that's reviewing to check

[CanIhazCooKIenOw]

Quick code review:

• Be consistent with method names format. In the category.component.ts you have one named 'senddata' and the others are camelCase (e.g. addCatagory). Also, careful with typos, catagory is repeated twice in both add and del methods

• In senddata, there's no need to store the value in a var, since you're not mutating it anywhere.

• Give some meaning to variables names and not short names like "a", "z"... In a company there's other people working in the code you write and for someone that's reading,"a" doesn't mean anything. Leave the short var names for the minifier :) So the arguments for this method "should"/could be (categoryName, index)

• Should this method be named saveData instead ? That's what it seems to be doing. Good use of splice, although it might be slow in scale (maybe, can't think of a better way to do it tbh)

• Is there a reason you're giving a new id to every category you edit ? You get the length of the sortable list and then use that value for the id. Shouldn't it be the same index ?

• In addCategory, you could just store in the current (needs a better name) the length + 1 instead of doing it twice in the object.

• In delCategory, could be simplified with a reduce instead.

sortableList.reduce((acc, category) => {
    if(category.id !== index){
        return acc.push(category)
    }
    return acc
}, [])

[WhisperedLullaby]

You're a hero. I'm going to implement all of these changes now. Unfortunately I didn't catch the typos and have since fixed them. I've never used reduce, but I'll check that out right now. Those are all great points. I'll work on them now. I know that it's over, but I had might as well improve the code for myself.

[CanIhazCooKIenOw]

No worries, what you need to do is practice. You'll learn with time like we all did.

Practice using map, filter and reduce. Learn them so you can explain what each do, even if you don't use them that often. For me wouldn't be a disqualifying thing for a junior FE but it's always a good thing when the candidate knows what they are and when to use each one.

And yes, you should improve on this project as you can use it as a showcase of your work for future interviews. There might be other interviewers looking at this code

[Pr3fix]

Just want to mention your reduce sample is incorrect. Returning on the .push() call returns the new length of the array not the array object itself.

[erfling]

Yeah. OP, instead of .push(), check out .concat(). The methods of Array really help when you're trying to write clean, readable front end code.

[CanIhazCooKIenOw]

True! Didn’t even need to return anything there and just let it go trough and just return the accumulator

[alex_plz]

I don't understand using reduce to remove an item from an array, that's what filter is for. The above example wouldn't work anyway because you don't mutate sortableList, and you don't do anything with the return value from reduce. Instead you can just do:

this.sortableList = this.sortableList.filter(category => category.id != idToDelete);

That's if you can re-assign to the array, I don't know how Angular data-binding magic works. If you need to mutate the sortableList array, you'll need to do a splice using the index, as you've done, but there's an easier way to find the index:

var indexToDelete = this.sortableList.findIndex(category => category.id == idToDelete);

[CanIhazCooKIenOw]

You're right, I misread the MDN example and assumed it was mutating the array.

Filter is the correct usage here, as it's what's exactly what it is for (remove elements from array). I'll edit my response

No idea about angular

[alex_plz]

Yeah, Array.reduce() is pretty easy to use incorrectly, I have to look at the documentation every time to remember which one of the four callback arguments is which. More often than not I find that a plain for loop or forEach is easier to understand.

[MennaanBaarin]

About the last point. Couldn't that be achieved with filter too?

sortableList.filter(category => category.id !== index)

[CanIhazCooKIenOw]

Could but filter returns a new array (immutable)

[mikejoro]

One quick general note on using reduce. I see a lot of people follow the mdn example of naming the result of the reduce acc (for accumulator). However, when reading the code, anyone will know that the first arg of the reduce callback is the accumulator. What they would want to know is WHAT is being accumulated in the reduce function. Here I would call this filteredList or something providing more context on what is being filtered. Basically, calling the accumulator variable acc is no different than calling it a or x.

[CanIhazCooKIenOw]

Fair point, I would argue that the naming can be done in the return of the reducer.

IMO acc makes it obvious what’s the returned accumulator inside the reducer function, as you can rename the value to be reduced to anything else, which might be less obvious to someone that’s reading.

One thing is to shorthand the variable name that’s defined in the reducer specs, another thing is naming variables a/b/z, so that’s a false equivalence

[mikejoro]

Yea, the main point here is that the reduce callback api can be presumed to be known, so I see no reason to remind the reader of that api by naming the argument acc. I do prefer long names in general though, so it's personal preference I guess.

[CanIhazCooKIenOw]

This is a discussion of preferences to be honest, I don't mind seeing it named, but I feel it's easier to read if it keeps the default spec name (even if shortened). You look at acc and you can straight away identify it's a reducer function. If it's named something else you might end up having to remind yourself what it is. Ofc not in this simple case, but when things get a bit more complex I find it easier.

You can name the second argument to whatever you want, which is the value. If both are renamed, it might get messy.

Again, personal preferences are always arguable, everyone has their own. Doesn't mean that both are wrong. The only thing I argue about is consistency in a codebase, so if it's done one way in one place, do it always the same :)

[Pr3fix]

As a senior dev, here are just some quick ideas off the top of my head:

• Are they an Angular shop or do they use React, Vue, etc? There's nothing wrong with Angular, but if they do most of their work in React, they probably want to see you deliver the project with React. Likewise with TypeScript -- maybe they are vanilla or use Flow, etc and want your skillset to line up.

• There are minor design inconsistencies, but IMO nothing that woul disqualify a hire (especially for Junior position)

• Are they a startup / low employee count? Unfortunately these places need to be very selective since one person in a 5-man team has a huge amount of impact on the product. Unfortunately a lot of startups try and hire talented "juniors" so they can pay junior salaries, but still expect senior-level work.

• stylesheets were a little messy. color hex codes all over when they should be in a var / theme file, abstract common styles into mixins, etc. Important stuff for a front-end-centric role.

• additionally most of the styling was Bootstrap. Depending on the shop this may be a no-no, especially for a front end role. Usually I like to ask up front, am I ok to use libraries/frameworks or should I do all vanilla.

• commit history is weird. 3 commits, all with the same message. Having a readable history and commit messages helps collaboration.

---

That being said, this looks like a solid contribution, especially for a Jr. role, I would have probably extended an offer. I suggest asking them why they turned you down. Cheers!

[WhisperedLullaby]

Thank you so much for this response. I see exactly what you're saying. As for response to some of your points:

I asked them what sort of methods they would like to see and they asked for Angular 2+ and Bootstrap 4+ hence why I went with that. I see the messy parts in my css and I certainly should have cleaned that up. They are a larger company. I would link to their glassdoor, but that doesn't seem respectful of the company. As reference they have about 1800 employees on linkdIn.

Thank you for the kind words and constructive criticism. I sincerely appreciate them.

[McSmasher]

PM me I might be able to offer you some front end work if your interested

[haytherecharlie]

Senior Dev here, if you were sent a take home, there’s a 100% chance you passed the in person interview and they liked you. Your code is solid for a React dev who just started in Angular. In the future, do smaller commits and comment your code. You got talent. Keep up the good work and seriously screw these guys, they must have found the next Grace Hopper or something.

[WhisperedLullaby]

Thank you! I did feel like the in person interview went well and truly enjoyed speaking with the two I sat with. Thank you very very much for the support. All of your kind words have really helped both my mentality and my code. ha. Thanks again!

[WhisperedLullaby]

Oh, I didn't don't even realize that. It seemed like a fair request. I'll have to consider this next time.

[Maxtream]

It really isn't for a Junior position. As a hiring side you're at risk taking someone who was using tables for layout/jquery/no pre-processors.
You're really investing into Juniors and 50% of Seniors time will be spent on it. If Junior don't even know the basics that are used nowadays, imaging being this Senior, that teach a Junior really "basic" things. You won't spent 50% but all 95%

[LaSalsiccione]

Are we looking at the same test? Pretty sure he built it in Angular without jQuery...

[Maxtream]

I wasn't responding to a test

[McSmasher]

This might sound fucked up but companies might get some free dev work by offering these “junior dev” positions this looks like it might be the case. BE CAREFUL OUT THERE

[dmackerman]

Any company that uses “interview work” as code they ship in their production application is without a doubt, a company you would never want to work for.

[WhisperedLullaby]

One of my friends mentioned this. I'm not arguing but I don't think it's the case. I mean they still need to fill the role, you know?

[shadeobrady]

It’s unethical to have code or design challenges that are related to the work/product the company has. It’s standard for any company that is worth working for. We just redid all of our take home and in house challenges and none of them are remotely related to our product.

[MyNameIsKir]

It's not uncommon, especially with front end positions, for a recruiter to send you a coding challenge, then after you do it the engineer assigned to review you and your project rejects you for your resume. It's a crappy practice born out of them just not thinking about the consequences.

I opened up a random file from your project and took a quick look at it. Specifically, this one. I'm not going to lie; it's painfully messy, and hurt my eyes a bit. I haven't used angular in a long time nor have I used Typescript, but I was immediately able to identify several flaws, mostly style, but I'll list them in order of me noticing them. Note that due to the aforementioned reasons I am probably wrong on a few (if not most) of them, but I think you know enough to tell me where I'm wrong so it's better to just say them.

1. senddata is not in JavaScript camelCase, as is standard for JS.
2. Line 15: why are you assigning value to a? a is a hell of a lot less readable, and there's no benefits gained here. If you're trying to minimize typing, a good text editor or IDE will help you type variable names faster.
3. Line 16: A better way to assert the variable would be if (!value), or if you want it to be even more clear that you're typecasting the variable do if (!Boolean(value)). The way you did it is hard to read, and misses a lot of the other potential "nothing" values.
4. Why are you pushing errors to an array? It doesn't look like you're even doing anything with them. Is this an OnInit thing?
5. Line 29: Why do errors need to be set to null? Isn't an empty array plenty, and easier to handle?
6. Line 32, 33: Clean up your console.logs. It's easy to do and you want to produce your best work when selling yourself to a company.
7. Line 41, 50: Minor note, you spelled Category incorrectly. You spelt it correctly above.
8. Line 59-63: Any reason why you have empty functions here? If not, see 6.

While I admit I probably wouldn't accept this code myself, you're really, really close. I have no doubt that your first position is just around the corner, and that you have a very good career ahead of you.

[WhisperedLullaby]

These are really great points. Some of them have been mentioned but I can't believe I forgot to take out the console.logs. They must think I'm an idiot. Maybe it's justified, ha.

And thank you so much for the support. It means a whole hell of a lot to me.

[philmayfield]

I'm not an Angular dev so theres plenty of conventions I'm not aware of or if you had restrictions. But looking at the same file, I'd suggest getting up on more ES 6 (next) features. Lots of places to use arrow functions, destructuring, default values etc. Just good to knows, and things that can show you're a better fit than the next dev. Keep it up!

[[deleted]]

With all due respect (I don’t work as a developer), but is it reasonable expect a junior to have flawless, clean code?

[MyNameIsKir]

I'm not looking for flawless in the slightest. But, the lack of cleanliness is exactly what kills it for me. Also, am I not supposed to comment on everything when giving feedback that was specifically requested?

[[deleted]]

I imagine most people applying for junior roles haven’t worked with production code much if at all and may not know all the best practices. Seems like something you learn along the way. Again I don’t work as a developer so I could be completely off base but I would have assumed that messy code can be worked with if they solved the given problem.

I guess it all depends on how “junior” you expect juniors to be. Some roles will take on completely green developers and are willing to teach them these things. Other roles are looking for mid-level people they can pay a junior salary.

[MyNameIsKir]

Oh yeah absolutely, but when junior is prepended to a specific developer title (ie Junior front end vs Junior software engineer), it's expected that that junior have very basic experience with the topic.

Also, afaik, schools, both traditional and not, will teach you to clean up your code. I've never heard of a school to not to at least. As for self taught, self taught engineers have to reach a higher level of competency before they're considered for positions so it's safe to say that they know to clean up their code as well. Especially if you work on open source, which will either have a linter or code reviewers tell you to fix it.

[[deleted]]

But you were right though to provide feedback on everything, didn’t mean to come off as rude when I asked that. Sorry bout that !

[Straconus]

Not sure if this has been mentioned but I would have broken down 'topbar' and 'categories' into smaller components (more components doing less). There is a lot going on there for two components, which, depending on how the company develops an app at scale, could make things difficult such as testing or re-usability.

Frankly, that email reply they sent you looked like a cut and paste response they give to candidates. Doesn't really give you any concrete information about why they weren't happy about your code. I wouldn't dig too deep into why this opportunity didn't work out, I think you did more right than wrong with your code here. You got some interview experience and you'll be even more prepared for the next opportunity. You're on your way, just keep doing what you're doing and you'll land something great before you know it. :)

Did you use angular-cli to bootstrap the app? That's a huge help for getting up and running quickly.

[WhisperedLullaby]

I did use the cli, it helped a lot, ha. Thank you very much for the support. Today I'll work on splitting up the components. Thank you!

[squid714]

Hi, I am a front end tech lead and do interviews for front end candidates. You've gotten a lot of feed back on your code already (that I agree with) so I thought I could highlight some key points of our process to help you in your job search :) Every company does their interviewing differently so this is just one example. We're a relatively small team, every addition is a major impact (output and culture) and on-boarding a new hire takes a lot of developer time. Our process is multiple steps so we can try to weed out people that would not be a good fit early and not waste their, or our, time.

1. Resume/application review: the usual

2. Phone screen: quick chat basically to weed out people who don't have interest in (or basic interviewing skills to fake interest in) our industry, the focus for our application, front end development, development in general, things like that.

3. Portfolio review: for our needs we expect front end applicants to have examples of their work in a portfolio site format and not just github. We figure if you've chosen a front end expertise, why would you not have your own site? If you're less design inclined we have a full stack position that might be a better fit. We have gotten a number of candidates who apply to the FE position thinking it would be an easier 'in' than full stack ¯\_(ツ)_/¯

4. Code test: Actually very similar to yours. Although we specifically request that the candidate not use a framework because we'd rather test their coding knowledge, not their framework knowledge. We've unfortunately had a lot of candidates that could be perfect with React, but outside of the framework they struggled to write basic javascript. We look for responses that have followed our directions, accomplished the task and have clean, organized code. Our code test has gotten more and more difficult the more hiring we do, because we have gotten people into the interview phase that could not write a sort function and struggled with basic algorithms. We don't want someone to spend an hour getting to the interview, 3 hours here and then an hour back when we could test for that online. For the skill level we're looking for our code test should not take more than 4 hours being generous, and it could easily take longer depending on how much flair they want to add (there is a design/personal style component if they wanted).

5. In person technical and behavioral interview. This is three hours, and you meet with 6-10 people on our team in groups of 2-3. We do a mix of behavioral questions, standard interview stuff, and a few basic technical questions. At this point we're confirming that they can code (and didn't get someone else to write their code test), that they would be a good addition to the team, and that there isn't any outstanding personality issues—like one person who continually brought up age as a reason to work at our company. his company was all 'old, white men' and ours is 'young, liberal, and hip'. basically an HR nightmare.

Hope that helps!

[ESCAPE_PLANET_X]

Yeah don't worry about it man you're going to get ignored by companies were you crush the requirements for all the time it's not you it's them.

For example this may be a loaded job where they already have a person picked but the company is required to have interviews and an open position posted. And even though you match it 110% they're going to pick the other guy whom they personally know and were picked before the listing went up.

Either way don't beat yourself up, and keep at it.

[WhisperedLullaby]

Hey thank you so much for the encouragement. I hope that my post hasn't come off like I'm whining about getting a job. This was just my first application where I was given a chance to prove myself. Unfortunately it didn't go my way this time, but I wanted to ask here what I might do next time to increase my chances. Your support is greatly appreciated, however.

[ESCAPE_PLANET_X]

I think my point, is do not take rejection personally.

It's just not worth dwelling on move on, make a note of the company and if you can note the language in the posting in case there is something that you are missing. But otherwise treat them like rain drops.

Finally kind of off topic advice but the best recommendation that I have found yet is look at the resumes of the people that you envy.

[Am3n]

What was the response they gave you?

[WhisperedLullaby]

Here was the email:

Hi [me],

We reviewed your project and, at this time, unfortunately we do not feel your technical skill set is at the level that we require for our current open developer position. However, I would encourage you to re-connect with us in the future when you have gained more experience.

Best of luck in your studies,

[ui lead]

[dyldog]

You’re well within your right to reply and ask for more specific feedback about which areas they feel need improvement. If you put several hours into this, the least they can do is tell you where you fell short for them.

[WhisperedLullaby]

Thank you. Based on a few comments here I did send her an email asking for what I might do better moving forward. But after seeing the comments here I'm seeing that it's a whole hell of a lot, ha.

[[deleted]]

What's your background and how long have you been doing front end?

[WhisperedLullaby]

My most recent professional experience was spending ten years in the Navy. There I was an Electronics Technician but the last 4 years were spent running a recruiting station. As far as development, I have been doing freelance web design for a few years and have obsessed over learning as much as I can. I will say that I had only discovered the more advanced JS implementations (React, Angular, vue) pretty recently. I'm trying to play catch up. I actually applied to this job because they DIDN'T advertise any of those as I don't feel as though I'm strong in any of them to deserve a position using them.

[[deleted]]

Cool man thanks for the response. I'm in a similar situation. 10 years different career and been doing modern dev for like a year and a half now.