JavaScript Core 2 - Week 1 - More Coursework

[ChrisOwen101]

Which module(s) and week(s) does this change effect? Module(s): JS2 Week(s): 1

What is the work that needs to be done?

This week needs some more challenges to do with Objects. It can (and should) also cover the material that come in JS1.

Additional context

Thinking up challenges at this point can be quite hard since they have to push them and be interesting whilst also not using very much visual content since they don't have any DOM knowledge yet.

[illicitonion]

Right now the way we introduce objects feels a bit contrived, because we use hard-coded constant data for most of them. The water bottle exercise is by far the most interesting because it actually deals in state.

I think it could be useful for us to lean more into objects as a vehicle for state (and methods), rather than as a place to store static data.

If we introduce constructors (or enough of scope, for a factory function, I guess) there's plenty we can do here which is a bit more interesting; things like: "write an object which takes an array of arrays in its constructor, and has a method which lazily iterates across them". Example test:

let i = new LazyFlatIterator([0, 1], [2, 3]);
i.next(); // 0
i.next(); // 1
i.next(); // 2
i.next(); // 3
i.next(); // undefined

It's quite a ramp up in terms of problem solving, but maybe a useful one for seeing that objects are more than just a static dictionary.

In particular, I've noticed while doing technical interview prep that we haven't really set the trainees up for a framework for solving this kind of problem, and knowing how/where to store state in pure JS (not React), without using global variables is an important skill. That said, it is a big ramp up, and maybe JS2W1 isn't the right time.

[ChrisOwen101]

Idea: "Choose your own adventure" style game using either the command line inputs or a pre-built UI.

Students would have to code the "gameplay" of the app by storing the choices that are made and the resulting outcomes.

[ChrisOwen101]

Idea: Build a "Stack" of actions that have happened in the past. This could include Array Manipulation and Objects.

An example of this might be building the "Back", "Forward", "Refresh", "Navigate" features of a web browser

[40thieves]

I think it could be useful for us to lean more into objects as a vehicle for state (and methods), rather than as a place to store static data.

Maybe I'm being thrown off by your example a bit (which feels quite interview-test-y), but I worry that implementing stateful classes is relatively uncommon in the wild. Or at least is largely handled via libraries. I'm struggling to think of a time when I did this in my job. But I could be totally off, so if you have examples I'm happy to concede the point.

LazyFlatIterator

I must admit it took me a min to think of how I would handle something like this. The implementation in my head also depends on either the spread operator or arguments to work too. My feeling is that this would be a harsh question for a junior level interview, but I could be wrong?

[40thieves]

Idea: a spell checker? Pass it a string, split into individual words, check each word against a dictionary of "good" words.

It's not really about objects and more about arrays, but there's a possibility it could be extended into some DOM coursework: listen for changes in a textarea, spell check the text, render the "bad" words under the textarea.

[40thieves]

the way we introduce objects feels a bit contrived, because we use hard-coded constant data for most of them

Another thought: it looks like (and I must admit I haven't gone through all of the exercises) the objects that are used are defined directly in the file.

IME, objects are much more likely to "come from somewhere", e.g. a network fetch or a DB query. I wonder if a solution might be to provide a function which returns some semi-randomised data (as an object) and do something with that object. Having said that I'm struggling to come up with something more interesting than getUser.

[illicitonion]

I think you hit on the important point, that:

Another thought: it looks like (and I must admit I haven't gone through all of the exercises) the objects that are used are defined directly in the file.

IME, objects are much more likely to "come from somewhere", e.g. a network fetch or a DB query. I wonder if a solution might be to provide a function which returns some semi-randomised data (as an object) and do something with that object. Having said that I'm struggling to come up with something more interesting than getUser.

I think this is really the core of the problem - our examples would be equally served by having variables and functions not in an object. The object is purely for grouping related data, but because it's all in-line in one file anyway, it's not obvious that that grouping has any purpose, other than avoiding is writing the word const a few times.

Looking back through what you're saying, maybe the answer is that we shouldn't actually be teaching how to create objects at all in JS2 (or at least, not be teaching how to write methods), and just focus on consuming them (and maybe making object literals of plain data to pass to libraries)?

---

I think it could be useful for us to lean more into objects as a vehicle for state (and methods), rather than as a place to store static data.

Maybe I'm being thrown off by your example a bit (which feels quite interview-test-y)

Definitely very interview-test-y (in fact, documented as one of Google's worked example interview questions: https://techdevguide.withgoogle.com/resources/former-coding-interview-question-flatten-an-iterator-of-iterators/)

but I worry that implementing stateful classes is relatively uncommon in the wild [...] I'm struggling to think of a time when I did this in my job. But I could be totally off, so if you have examples I'm happy to concede the point.

I don't really work in JS very much (or frontend in general), so I can't really speak to that context, and that's probably the important context for JS2. But it's common enough in my day-to-day working on back-ends... One of my examples I've implemented at work is client-side load balancing, roughly: "Each time someone calls a method, send a request to one of a pool of servers, round-robin-ing between them, skipping servers which were recently observed by a response code of 5XX to be unhealthy", a simplified version of which I fairly often use as an coding interview question...

LazyFlatIterator

I must admit it took me a min to think of how I would handle something like this. The implementation in my head also depends on either the spread operator or arguments to work too.

Oh, sorry, there should have been one extra pair of brackets: let i = new LazyFlatIterator([[0, 1], [2, 3]]); - i.e. you're guaranteed to be given one argument, an array of arrays, and not doing recursive flattening :)

My feeling is that this would be a harsh question for a junior level interview, but I could be wrong?

I've frequently seen this and comparable things asked to new grads at Google/Facebook/...-style companies targeted at junior jobs, and I think that some portion of our graduates are competing for those kind of roles (assuming the company and team are well set up to be supportive towards learning and growth). Some teams at some of these companies (not as many as I'd like) are at least recognising that not being familiar with big-O notation is fine, but I'd still generally expect a junior hire to be able to write code to solve this kind of problem (with or without the comp-sci-style analysis).

That said, JS2 very probably isn't the place to be setting them up for this kind of interview!

[40thieves]

Sorry for just getting back to this.

we shouldn't actually be teaching how to create objects at all in JS2

Not sure I would go that far. As you point out, there are valid cases for making objects (one being passing into libraries), but more to the point, I think it would be distracting to only cover usage without creation. They'd inevitably find materials about this online anyway, so better to cover it off in the lesson.

My sense is that a lesson something like this would work:

1. Object creation
2. Object usage (from literals)
3. Discussion that objects "can come from anywhere" and so can be used just like literals. Doesn't have to be super in-depth, just mentioning that this is possible. We can then back this up via coursework.

not be teaching how to write methods

This I'm more on-board with, although I may be biased in that I avoid the this keyword like the plague based on my experience of trying to teach it.

there should have been one extra pair of brackets

Aha, that makes more sense to me :)

I've frequently seen this and comparable things asked to new grads at Google/Facebook/...-style companies targeted at junior jobs

I will defer to your greater experience, but I wonder if we should also talk to folks like Capgemini here. From what I understand of their interviews that are quite light on technical challenges.

EDIT: thinking through my point more, LazyFlatIterator is quite abstract, and so perhaps more difficult for a trainee to be interested in or understand the application of. Therefore my suggestion of a spell-checker might be more useful: it feels more "realistic", but has some interesting technical implications.

JS2 very probably isn't the place to be setting them up for this kind of interview!

Yes, overall that is my feeling from this particular question.

[illicitonion]

My sense is that a lesson something like this would work:

1. Object creation
2. Object usage (from literals)
3. Discussion that objects "can come from anywhere" and so can be used just like literals. Doesn't have to be super in-depth, just mentioning that this is possible. We can then back this up via coursework.

👍

not be teaching how to write methods

This I'm more on-board with, although I may be biased in that I avoid the this keyword like the plague based on my experience of trying to teach it.

👍

I've frequently seen this and comparable things asked to new grads at Google/Facebook/...-style companies targeted at junior jobs

I will defer to your greater experience, but I wonder if we should also talk to folks like Capgemini here. From what I understand of their interviews that are quite light on technical challenges.

For sure this isn't needed for all companies - if we want to set our target as our trainees being able to get jobs which don't require significant technical interviewing, I think that could be a reasonable (though imo slightly sad) decision we could make, but we should be very explicit about that if so, to the extent that we may want to actively discourage our trainees from applying to jobs at certain companies as a result (as we'd realistically be setting them up for failure)...

Surveying "minimum required interview skills" from a bunch of companies seems like a useful step we could take to try to work out how broad a segment to realistically target!

EDIT: thinking through my point more, LazyFlatIterator is quite abstract, and so perhaps more difficult for a trainee to be interested in or understand the application of.

Yeah, you're right that this isn't a very engaging question. It's probably a bad example while learning the building blocks, but I think it is the kind of question we should be making sure they have all of the building blocks to solve if they needed to - ideally a technical interview prep workshop could just focus on "how to approach the problem and interact with interviewers", without also having to teach actual JS techniques, and I think state management is an important technique for that kind of interview.

Therefore my suggestion of a spell-checker might be more useful: it feels more "realistic", but has some interesting technical implications.

With the caveat that (as discussed above) JS2 may not be the right place for this, this sounds great :) Ideally with an "add to dictionary" method (maybe as a follow-up exercise), so that state can change over time.

Some additional ideas for similar exercises we could set:

• Meal tracker - methods to input your meals one at a time, and it tells you how good you are at eating your 5 a day.
• Game state tracker for something like tic-tac-toe or hangman - methods to input players' moves, and it will tell you whose move is next, and if anyone won (if we decided methods/state are worth keeping in JS2, maybe this could be an end-of-JS2 mini-project to make the whole game, for two players sharing a browser session? Games are motivating...)

[40thieves]

if we want to set our target as our trainees being able to get jobs which don't require significant technical interviewing

Sorry, yes didn't mean to imply that we should be "lowering our expectations". More that we should gather a range of opinions on technical interviews.

I think we're off-topic a bit here. I think we should consider opening a ticket for a technical interviews workshop.

[illicitonion]

I think we're off-topic a bit here. I think we should consider opening a ticket for a technical interviews workshop.

Good call - I span out https://github.com/CodeYourFuture/syllabus/issues/175 to follow-up. I think the important thing we do need to work out for JS2 is: How deep do we want to go into methods and object state in JS2?

[40thieves]

Made a start on this. I think I'll try to knock out a few of the suggestions as separate PRs.

PR for the choose your own adventure exercise: https://github.com/CodeYourFuture/JavaScript-Core-2-Coursework-Week1/pull/27.

I also got a bit carried away and built a solution with a lot more features: https://repl.it/@40thieves/TrustingGuiltyTag#index.js. I think maybe it could be good as a challenge exercise? There's only a couple of concepts would be new, so maybe should be removed (e.g. early returns).

[illicitonion]

Some JS1 exercises that could be better formulated as objects, which could be useful for "recap these exercises, but see how Objects are a useful data structure":

https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week3/blob/main/2-mandatory/4-eligible-students.js https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week3/blob/main/2-mandatory/5-journey-planner.js Maybe https://github.com/CodeYourFuture/JavaScript-Core-1-Coursework-Week3/blob/main/2-mandatory/3-space-colonies.js