undefined | Better HN

0 pointsspacebanana73y ago0 comments

Yeah even a basic to do list or calculator web app can take several hours if it’s your first time with the specified framework, build tool or CSS library.

Given the diversity of FE it’s quite likely for a take home project to hit one of those criteria.

0 comments

3 comments · 1 top-level

OldManRyan3y ago· 2 in thread

> ... if it’s your first time with the specified framework, build tool or CSS library.

Depending on the position they may been testing specifically to filter people out who are using a tool for the first time. If I'm hiring a Senior Flutter Developer then it better not be their first time using Flutter.

calvinmorrison3y ago

Unless we're talking about something truly enterprise (Magento at 4 million lines of PHP dependency injected MVVC hell comes to mind) or very obtuse (hiring ocaml devs to work on their compiler) senior means senior engineer, I don't care what you worked on to be honest. Senior perl engineers can flip to ruby in month and be totally proficient. A good Java programmer with 10 years experience will have plenty to bring to the table in C++ .

If you are a senior developer and haven't seen half a dozen frameworks, tool sets, or languages under your belt. What value are you in 2 years when we shift gears

3oH2y8693y ago

I don't know about Flutter, but my issue with these takehomes in a React world is that React is extremely basic. It is only a view renderer, and leaves up to you all difficult questions of: routing, CSS, components, data fetching, state management, even things like how files are organized and named are up to you. As a React candidate, your takehome probably touches on all of these topics, and you (rightfully) probably want to express some kind of proficiency in most/all of these areas. The more senior you are, the more likely you have opinionated ways of doing these things. But in an hour long span, you are left with two uncomfortable options:

1. Write it all yourself. Express those opinions as clearly and bug free as you can. Try to get it all in as much as you can and give up on finishing all the features in the spec. Definitely give up on the UI looking nice -- despite what anyone says, default HTML is not pretty.

2. Use OSS libraries. Are you actively up to date on OSS libraries handling these things? If you're a working React professional, you probably are not, because you're using whatever system your company uses. Do those OSS libraries properly express what you think is good code? And what does it say about you to use those OSS libraries? Do you look like someone who actually understands React and understands those tradeoffs, or do you look like the kind of person that creates the type of React app that HN is always complaining about, one with a billion dependencies?

Sorry if I sound ranty. It's not directed at you. I've just been dealing with a lot of these this week.

j / k navigate · click thread line to collapse