Cool! Before I read your article I took a stab at throwing together a quick progress bar. My approach was almost the same as yours except that I used css transform and animated on flex-basis. It's nice to see another approach though. Here's mine if you're interested.
EDIT: I've added some additional use cases that I've run into on occasion. First, using an integer input to determine the completion status as opposed to a static animation from incomplete to complete. Second, making the progress bar into a slider itself using the same css techniques.
Awesome! It's great to see a solution using React 😊. Those four colors are a nice mix.
See I think it depends on the role. If you're hiring a css oriented front-end developer, that's fine. If you're brining in my JS architecture oriented folks, the kind who are more adept at setting up a babel rc than a keyframe, well then it's unfair.
I will agree that these tests can be overly domain specific, but I also think that the desire to have engineers with great breadth of knowledge is a good one.
I'm with you, breadth of knowledge is important. That is certainly what my role demands of me and I like it, but in being broad I think we sacrifice depth in some of these categories. I think this particular test is incredibly general and is well suited to many full stack developers, I agree with the author that extending it to a sockets implementation would make it even more fun.
It would be great to see a solution that also incorporates some of the ARIA markup to make the progressbar accessible for all users and the JS to handle that, too:
That's very true. Great solution 👍
For the final option, there's still another option that is likely more peformant?
Using the transitionend event would allow you to use the code from the second example and then just set the width of the inner bar back to 0 if the queued length > 0.
This prevents you from having to setTimeout, manually animate, and have that width value be global-ish.
This is an awesome idea. I suspected that something like this would be possible. It definitely sounds more performant.
I knew the community would have some cool ideas about this problem. I’d love to see this coded up ☺️
It would make a huge difference if the time requirement was removed completely and the candidate was asked to architect a progress bar based off some sort of input value that is variable. This would actually require some level of problem solving and the interviewer could observe how the problem is solved. It is also based off a real problem, could start a discussion of event based architectural patterns like Redux, and reflects component based design patterns.
I agree! It does seem a little far removed from a real world problem. I think the time aspect is so that setTimeout/Interval is used, which introduces some basic scoping problems.
FWIW given the conditions of the test if someone were to use setInterval I wouldn’t be that impressed. requestAnimationFrame would be way better and even more so Web Animations API. Even then the test is still hunting for a very specific answer that amounts to trivia which should be avoided in test scenarios.
That's a great point Steve. I went ahead and added a requestAnimationFrame version too! 😊
I'm ashamed to say I'd have failed that interview as I rarely think of animations in CSS ...
That's one aspect that seems unfair about this question. Remembering the correct animation syntax on the spot.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.