Forem: Michael B

Writing and Asking (Tech) Interview Questions That Capture Culture

Michael B — Tue, 13 Oct 2020 18:46:16 +0000

Original post here: Writing and Asking (Tech) Interview Questions That Capture Culture
Useful? Feedback? Have your own questions you ask? Let me know in the comments!

You did it! You got an interview invitation. Now it’s time to start thinking about preparation, especially what questions you’re going to ask. Interviewing is not only an opportunity for you to share yourself, but to learn about the company you’re interviewing with. It can sometimes be challenging coming up with questions that will get right to the point of what you’re looking for, especially if what you’re trying to evaluate is company culture.

Getting a read on company culture means it’s important to craft thoughtful, well-worded questions that will really get to the answers you’re looking for about a company’s culture. Here are a few tips for creating questions that will really get down to the heart of things.

First, get clear on what answers you’re looking for. What values are important to you? What are some ways your ideal company might act on those values? Think about past experiences, and what worked and didn’t work for you. Knowing this information will help you process an interviewer’s answer more quickly.
Get specific. Ask questions that require examples. For instance, if community engagement at a company-wide level is important to you, instead of asking “How does Company contribute to its community?” ask “When was the last time Company’s staff participated in a community engagement or volunteer event, and what were the outcomes?” If the interviewer can’t remember or it was a long time ago, that gives you even more insight on how this value is or is not practiced by this company.
Get context. Rather than asking, “Can you tell me about Company’s tech stack?” ask “Can you tell me about the evolution of Company’s tech stack since Company started (or if it’s been a few years, maybe ask about the past year or so)?” This gives you not only a historical look at what this company has used and is using, but insight into the decision making process, and what this company’s tech needs and priorities are now.
Get creative. Especially if you’re interviewing with folks who you might work directly with, this is a great opportunity to get to know people and how they’re championing company culture. Creative questions like, “If you were a food, what food would you be?” and “If this team was a rock band, who’s playing on what instruments and why?” are fun, and they can give you an opportunity to connect with people you may get to work with.
Get technical. Asking questions like “What processes are in place for measuring employee growth and goal-setting?” will give you insight into a company’s organization, requirements for management, and how they facilitate employee growth.

Company culture is sometimes an elusive thing to get a full picture on, and it should be noted that during an interview is certainly not the only time you can investigate a company’s cultural landscape. Chatting with friends, mentors, or connections who work or have worked at a company is a great way to more intimately understand the details of what it’s really like working there. It’s also worth looking into the company’s website, seeing if they have a blog, what their online presence looks like on various social media sites, etc. It’s hard to ever really get a full picture of a company’s culture before actually working there yourself, but with these questions and other research techniques you can be off to a great start.

Original post here: Writing and Asking (Tech) Interview Questions That Capture Culture

5 questions to ask before learning a new JS framework

Michael B — Thu, 24 Sep 2020 21:05:53 +0000

Original post here: 5 questions to ask before learning JavaSript frameworks
Useful? Feedback? Let me know in the comments!

Have you been working with one JavaScript framework for a while, and started feeling ready for learning something new? This is the guide for you! Learning a new framework or library can be an exciting opportunity, one that’s ripe with chances to advance your knowledge in new areas and reinforce existing knowledge. To set yourself up for success, it’s helpful to ask yourself a few questions about the new material you’re choosing to dive into. While this article will mostly showcase examples related specifically to JavaScript libraries and frameworks, these questions can be applied to any transition from one framework or library to another.

1. What makes this framework or library special?

You could also look at this as “What problems did the creators set out to solve?” Maybe you’ve already selected your framework or library and want to build a project around it to get practice with it, or maybe you’re looking to accomplish a specific task and need to find the right tool for the job. Either way, it helps to deeply understand the key features of what you’re working with vs. its competitors. For example, if you’ve been working with Angular, you might choose to work with React next because you’re interested in learning
about one-way binding or using a virtual DOM. Knowing the key features of the technology you’re using will help ensure you’re designing features and functionalities that work well within the bounds that you’ve chosen.

2. What is the general structure of an application or project built with this framework?

Gaining insight into a project’s structure helps inform what tools and learning opportunities are available to you, as well as how you may integrate it into existing projects. Look for differeces as well as similarities between what you know and the new tool you’re using. In both Vue and React (using create-react-app), creating a default application will generate a ‘public’ directory, which tells you both technologies work similarly when it comes to storing and referencing publicly available assets.

3. How are key features typically handled?

There’s likely more than one way you’ll see key features handled in a JS framework or library. For example, re-rendering happens after using setState in React, and after a change detection cycle in Angular. Being aware of the different ways key features of the framework are handled will not only inform the choices you make within the project, but it will help you in the hunt to answer any questions documented on the framework’s site or sources like Stack Overflow.

4. How large is this community and how well-documented is this framework?

This is mostly an expectation-setting question - it may be more difficult to find answers to unique or specific questions when working with a less common framework. If that’s the type of challenge you’re up for, go for it! And if you’re able to contribute to the development of the framework, that’s icing on the cake. React has a large following with solid documentation, and is quite a popular framework, but some folks in tech cite Vue as being better-documented. It helps to sometimes seek out opinions on documentation, especially if you’re looking to do something specific with a library or framework, but not to hold any one opinion as the ultimate source of truth. The best approach is to take a
look at the documentation for tools you’re considering and decide for yourself how comfortable you feel with it, and if it meets the goals you’re setting for yourself.

5. What adjacent libraries or frameworks should I know about?

Knowing what else to look out for will not only inform additional features or new directions you can incorporate into a project, but it will give you a sense of what other pieces of code may make an appearance in answers to common questions. With large React projects, for example, you may want to incorporate Redux for state management. If you’re looking to foray into mobile development, it may be worth your time to also look into React Native and or Ionic. It may also serve your project’s needs better to go with a library or framework-agnostic choice, like Cordova for mobile development, but it’s worth knowing what’s out there and what’s been developed with your tool of choice in mind. This is by no means the end-all-be-all list of questions to ask yourself before jumping into a new JS library or framework, but it’s a great place to start and prepare for your next JS adventure!

Original post here: 5 questions to ask before learning JavaSript frameworks

7 rules for designing your first database schema or data model

Michael B — Tue, 15 Sep 2020 20:37:55 +0000

Original post: 7 rules for designing your first database schema or data model
Do you have any tips or rules of thumb for designing your database model? Love to hear pros/cons in the comments!
Are you a novice or intermediate web developer, starting a brand new project that uses a database? Not sure where to begin in terms of your table design (schema) or ORM models? I've advised quite a few students on this exact topic before, so I assembled these tips as a "check list" to use when you are designing your database:

Think about "nouns" - your models (tables) should be the main "nouns" of data that you have to keep track of (e.g. Book, Author, BlogPost, etc). The methods (functions) should be the "verbs" (e.g. get_latest or update_messages) and the properties (columns) should be adjectives or relationships (e.g. popularity or color for adjectives, or creator for a relationship)
Combine similar models - If two models (tables) seem almost the same, with maybe just one or two fields (columns) that are used only on one but not the other, just make them the same, and just skip using the fields (columns) that are specific to one when adding data for the other. For example, when developing the LiveSyllabus LMS, I was originally going to have separate models for Homework Assignments and for Reading Assignments.... but pretty quickly I realized they are almost identical, so it makes sense to store them in the same model (table) and have a category field to distinguish them. Another example: Don't have books_romance and books_horror as your tables, instead just have a books table and have genre be a column.
Simple and stable - No one likes lots of database migrations. So, try to design your models to last and not have to be changed often.
Think visually - If it helps, think about how your application might function if it were in a spreadsheet. What columns do you need? Which values could be computed from other values?
Compute what you can - Avoid storing things that change or are computed in your models. For example, even if the design requirements need to show "how many days until we want this to be published", what we really want to store is the unchanging "publish date". The publish date doesn't ever change, it simply is used to show or hide the article depending on the current time.
Match what you present - Think in terms of "data" vs "presentation". Often, what's stored in your models might be pretty close to what's presented, a 1:1 relationship. Other times, the database will be simpler than what's presented (frontend), and it won't match. In this case, think in terms of putting on a "show" for the user.
Don't over-engineer it - Start small. Don't think of every possibility, just cover the top ones. In some cases you might need a n:n or "Many to Many" relationship (e.g. for a Twitter clone: "friendships", "followers", "likes"). But in other cases, resist the urge to model all possible features at once. As an example, maybe you could think of a future feature where a Tweet might have many User author -- but unless that feature is a "must have" for your product now, start with each Tweet having only one User (One to Many or 1:n) until you finish other aspects of your software. Keep your product's design short and sweet. Most software products won't ever even get used, let alone improved upon.

Bonus (Django specific) rule: Avoid "Generic Foreign Keys" if you can!

Background: A student recently asked me what is the best practice for designing data models. While the question was originally for the Django ORM on PostgreSQL, I've given the exact same advice while teaching classes on JavaScript / Node / Express stack using SQLize and MySQL, and in another course, Mongoose for MongoDB. While I've never taught a class on Ruby on Rails, the same advice also goes for ActiveRecord. These tips are pretty universal! In fact, as a Star Trek fan, I'll point out that even Star Fleet needs good database design:

Originally post: 7 rules for designing your first database schema or data model

How we decided to upgrade our JavaScript curriculum to use React Hooks

Michael B — Wed, 19 Aug 2020 21:18:49 +0000

Original post: How we decided to upgrade our JavaScript curriculum to use React Hooks
Have you been considering the switch to using React functional components with the useState hook? Would love to hear your reasons for / against in the comments!

Several months ago we started talking about whether or not to update our React curriculum to use the new React Hooks syntax over the old class-based syntax.

It was a challenging decision. In addition to getting familiar with hooks ourselves, if we made the switch, we would need to update the curriculum’s in-class activities, homework assignments, quizzes, code examples, and cheatsheets. In addition, we would need to find or create new tutorials and reading materials. To be sure that work would be worth it, we had to answer some questions:

How easy or difficult will hooks be for students to learn and use compared to the class-based way?
How many people are actually using hooks in practice? That is, will learning hooks put our students at a competitive advantage, knowing the latest and greatest tools? Or will it hurt them to be less familiar with the older, more established, and (we imagined at the time) still more commonly used class syntax?
Will there be enough good learning resources available? How many guides, tutorials, and other resources are out there for students to be able to find answers to their questions and explanations of the bugs they would run into in hooks-style React?

Question One: Ease of Learning

As we learned the ins and outs of hooks ourselves, it quickly became clear that switching to hooks-based syntax from class-based syntax almost always made our examples and exercises shorter and easier to read. From a teaching and learning standpoint, the advantage was hooks’.

A counter the old way:


class Counter extends Component {
  constructor() {
    super();
    this.state = {
      count: 0
    };

    this.increment = this.increment.bind(this);
  }

  increment() {
    this.setState({ count: this.state.count + 1});
  }

  render() {
    return (
      <div>
        <button onClick={this.increment}>add 1</button>
        <p>{this.state.count}</p>
      </div>
    );
  }
}

A counter the new way:

function Counter() {
  const [count, setCount] = useState(0);

  function increment() {
    setCount(count + 1);
  }

  return (
    <div>
      <button onClick={increment}>add 1</button>
      <p>{count}</p>
    </div>
  );
}

Simpler, shorter, and as an added bonus: no more having to introduce the concept of this at the same time as we introduce React.

Question Two: Adoption

Ease of learning is a major plus, but are companies actually using hooks in practice? We asked around a few different coding communities, and we were surprised by how consistently the answer turned out to be either ”Yes, we’ve moved entirely to hooks”, or ”Our older React code is still using class syntax, but we are writing all of our new components in hooks”. Almost everyone who responded was in one of those two groups.

“My team decided hooks are the bee’s knees and switched the entire codebase over to it.”

“We are 100% [hooks] with our clients”

“We've been updating our codebase and utilizing hooks for greenfield work. Super nice.”

“We're using them in any new components.”

“We use hooks exclusively.”

While we did get a couple of responses from people at companies who had not made the switch, quotes like the above were the overwhelming majority. Given that hooks is still pretty new and also a significant departure from the old way of doing things, we were surprised by how consistently people said they had already made a partial or total switch.

Question Three: Resources

With concerns about ease of learning and industry adoption out of the way, our last concern was the availability of resources. For years and years, all of the blog posts, tutorials, Stack Overflow questions and answers, etc., for React have been written with class-style React in mind. Would there be enough resources written for hooks-style React that our students would be able to find answers to the questions and bugs that would inevitably come up?

The resources question turned out harder to answer than the other two. While there is a fair amount of material written for hooks-style React at this point, most of it is written with the assumption that its audience already knows React. The guides are from the perspective of ”How to switch from class-style React to hooks-style React”, not “How to learn hooks-style React from scratch”. With students learning the hooks way of doing things from the start, analogies to the class way of doing things weren’t going to be that helpful.

This is changing, slowly. Increasingly more of the intro docs and tutorials for various React libraries are being written with hooks in mind, and new resources and Stack Overflow answers continue to pop up.

That said, to really feel confident that enough resources would be available if we switched the curriculum to hooks, we ended up deciding that we would need to write, or at least adapt, some resources of our own. The story of writing that adaptation will be the subject of next week's post.

Making the Switch

We eventually decided to go ahead and make the switch to a curriculum that introduced React via React Hooks. And as one of the people who worked on updating our materials for the switch, I have to say it was incredibly gratifying to watch almost all of the code for our activities and examples get shorter and clearer than it had been when written in class-style React. I’m a big fan of hooks, personally. I think it’s one of the best API updates I’ve ever seen a tool go through.

Requisite plug: if you’re a user of the cheatsheets we’ve published at Kickstart Coding, the all-new hooks versions are now open source and available at github.com/kickstartcoding/cheatsheets, including a new one covering useEffect specifically (link). If you’re tackling React for the very first time, or if you’re just making the switch from class-style to hooks-style React, check them out!

Next week I’ll be writing about the project we used to address the documentation problem. Hopefully it will be interesting and a useful resource for other people trying to get the hang of hooks. It’s one of my favorite open-source projects I’ve worked on, so stop by next Tuesday if you’re curious!

(Original post: How we decided to upgrade our JavaScript curriculum to use React Hooks)

Random bugs with debug_trainer

Michael B — Tue, 04 Aug 2020 01:01:46 +0000

Original post: Kickstart Coding Online - Want to practice debugging without actually getting stuck? Introducing: debug_trainer!

The Problem

It’s possible to build some pretty nifty applications without having a good understanding of how the code is working. You copy and paste some online examples here, you try random things until one of them works there, and eventually you’ve got a sort of copy-pasted Rube Goldberg machine that basically works even if you’re not entirely sure how.

Eventually, though, something is going to go wrong that cannot be fixed without a decent understanding of what’s going on under the hood. And when that does happen it is scary and stressful and not at all the best time to discover that the plumbing of your code is a deep, impenetrable mystery.

Getting practice understanding your code and fixing problems with it before things like that happen can be incredibly helpful. Unfortunately, the only way to get practice fixing broken code is for your code to break, and broken code doesn’t happen when it’s convenient and you’d like some practice.

Although I think most coding schools have debugging exercises here and there, I have spent a lot of time wishing that we had some better ways to give students more regular practice with debugging.

Recently, I finally got a chance to take the time to sit down and write a tool for debugging practice that I’ve been thinking about making for a while to solve this exact problem.

Introducing debug_trainer!

debug_trainer is a terminal program that breaks your code! Run the break command on a file of your choice and it will introduce a random breaking change into that file (or several changes if you’re feeling adventurous). Then you, the programmer, can put your debugging skills to work and try to find the change that was made.

Let's say you've got a file, my_file.py, that looks like this:

def greet(name):
    print("Hello, " + name + "!")

greet("Stacey")

You'd run debug_trainer like this:

> debug_trainer break test_file.py 


Breaking test_file.py...


...done!


Good luck debugging! I believe in you! Don't forget to make your program print things out if you don't know what they are. ❤️

And it might, for example, change the file to this (see the error?):

def greet():
    print("Hello, " + name + "!")

greet("Stacey")

The changes it can make are all based on common issues I’ve seen students struggle with. It might change the first letter of a variable name from capital to lowercase. It might remove the word ”return” from a return statement in a function. It might rearrange or remove the arguments in a function declaration. Malevolent!

If you get stuck, you can ask debug_trainer to give you some hints with the error-type-hint and line-hint commands. error-type-hint will tell you what kind of change it made (for example, “somewhere in this file, debug_trainer changed the arguments to a function”). line-hint will tell you what line the change was made on. If you get really stuck, you can have it tell you exactly what it did with the explain command.

> debug_trainer error-type-hint test_file.py

HINT: somewhere in this file, debug_trainer changed the arguments to a function.

> debug_trainer line-hint test_file.py

HINT: The line where the change was made was line 1 of the original file.

> debug_trainer explain test_file.py

removed the name argument from greet on line 1 of the original file

And once you’re done, whatever file debug_trainer changed, you can reset it back to it’s working state with the reset command. Then you can do the same thing all over again as many times as you want!

> debug_trainer reset test_file.py

test_file.py has been reset!

I’m pretty excited about debug_trainer and I would love to get feedback, advice, suggestions for additional types of errors or new features, etc. I’d also like to give a special thank you to Dillon Kearns, without whose brilliant tools and examples I would not have been able to write this using my favorite language, Elm.

If you want to try it out yourself, just run

npm install -g debug_trainer

to get started, then run the debug_trainer command to have it list all the commands and how to use them. Or check out the repo here or the npm package page here for more details and usage examples.

And let me know on the issues page if you have any issues or feature requests!

Original post: Kickstart Coding Online - Want to practice debugging without actually getting stuck? Introducing: debug_trainer!