This video is free to watch - hope you enjoy it! If you like what you see, there's a ton more where that came from...

Buy Now

JavaScript: What Time Is It?

Sometimes a potential interviewer will 'cosplay' with you - pretending that you work at the company and seeing how you might solve one of their realworld problems.

This is premium content - you can own it in just 30 seconds!

Buy Now

JavaScript: What Time Is It?

It’s Thursday morning at 10am and you’re sitting at home in your bedroom, waiting for the phone to ring. The recruiter you’ve been working with said that Santosh, an engineer on Team X with Company Y was going to call and have a brief chat - no more than 30 minutes.

This is a screening call and they’re going to ask a few questions about what’s on your resume. Please be sure it’s up to date.

You’ve gone over your resume and feel good about it. In particular, you’ve described how you’ve been working with NodeJS exclusively for the last 8 years, leading a team of 5 developers and shipping a core feature at your last company. On your resume, you described your NodeJS (and JavaScipt) knowledge as:

Highly proficient with NodeJS and JavaScript as well as various front-end frameworks, including VueJS, React and Angular.

The phone rings. Here we go…

The Question

Santosh is well-spoken and very kind, asking you a bit about your past work which you describe in concise detail. He then says “would you mind if I asked you a quick technical question?” “Of course, please do” you reply.

You mention that you’re highly proficient with NodeJS and JavaScript, and I wonder if you could offer your thoughts with a problem that we ran into last week using dates. JavaScript has a fun history of weird results, but this one had us going for a while…

This is the problem when you say your good at a language - other developers will wonder just how far to the edge you’ve gone. The “have you ever had to deal with” questions are common, so know your language quirks!

We pull transaction data from an online service and recently we noticed the dates we were storing were off by 6 hours in the past from what they should be. So if a transaction was recorded at exactly midnight on the first of April, we were recording it as 6:00pm on March 31st. We store dates in GMT, just like the service we use. We ended up solving the problem - but I’m curious - how would you go about figuring this problem out?

You laugh nervously: quirky JavaScript problems are fun and are all too common. You have some ideas about this, but he’s asked you a specific style of question: how would you go about figuring this out?

The Answer

This isn’t supposed to be a technical question where you get up and write on a white board - this is a problem-solving question to see if you can suss out where the problem might be and how you would implement a solution. The biggest part of this question, however, is how you might interact with the rest of the team. Would you try to solve this on your own, or would you involve others? So: how would you solve this? Think about it a bit before reading on and practice speaking about it aloud. Maybe write down your answer if you don’t feel comfortable…

Pairing on the Problem

This is a great time for you to show how well you could fit on the team. You’re in the conference room and one of your colleagues walks in with a great JavaScript head-scratcher - let’s see what we can do! Pretend this is a pair-programming session. There are a number of questions you can use to help sleuth the problem, such as:

  • I know you’ve been thinking about this for a while but sometimes when you describe the problem to someone else, a solution pops to mind. Given that - is this a new thing? I assume we’ve been tracking dates correctly up until a short while ago? Yes, that’s correct.
  • Have you isolated when the change occurred? Yes, we have - it happened 2 days ago during an hourly ingestion we run at 10pm.
  • Did this coincide with any changes to production? We thought the same thing immediately - but no. We push on a regular cycle but our code update happened earlier in the day at 8am and 13 ingestions happened after that without a problem.
  • My first thought is that something changed with the API you’re pulling data from. Have you run a diff on the data right before and right after problem ingestion? Yes, we did and we found a small difference to the way the dates were sent over. At first it seemed trivial - but maybe you can spot a problem? Here, I’ll text you a screenshot I just took from my browser window. I’m in Hawaii at a conference…

You look over the dates and … yeah ouch! At this point your first reflex is pile on JavaScript like so many do, but then you remember that it’s probably not a good idea to be snarky and dismissive in an interview. Instead, you decide to lean on your professional curiosity.

JavaScript has been around a while, you would think a quirk like this would be addressed. Then again, whenever people get upset about JavaScript’s behavior, someone always chimes in with a logical answer. You understand that a positive attitude is the goal here. You might know the answer right off the top of your head (if you do - good for you!). Let’s pretend you didn’t, however…

I haven’t encountered this problem before, but my guess is that it has to do with timezones. From the screenshot you sent me I can see the difference in dates is 10 hours - which is also the offset from GMT. That seems like too strong a coincidence. It would be interesting to find out why, but to fix this problem in the short term I would probably run a replacement over the dates, replacing the spaces with a forward slash and then update the “bad” data we have to the correct time/date.

Good Job!

Screeners want to know if you’re going to fit on a team, which means the questions they ask will likely be less technical and more designed to figure out what type of teammate you’ll be. Remember to remain professional, curious, and polite! Interviews are stressful and it’s all too easy to let that overflow into frustration.


The Code

Code for this video (and for the entire series) can be found in the production GitHub repo.

  • Let's Get Started!

    This is a quick introduction to what this production is all about and what (I hope) you'll learn. Please watch it. There are some supplies you'll need to get and some mental space you'll need to clear if you're to get the most out of this production.

  • Review: Big-O Notation

    It's a thing you'll need to know if you plan to get through any interview. It's actually quite useful and in this post I'll hopefully make the case that's it's simple as well.

  • Review: Data Structures

    Let’s review data structures! It’s fun and exciting! In this section you’ll review and then build your very own data structures along with me! I’ll be using JavaScript to code mine, but feel free to use whatever language you like.

  • Review: Algorithms and Strategies

    Now the fun starts! We have our data structures and now we need to focus on the algorithms we’re likely to be asked about in an interview. But that’s not enough! What you really need to do is to be able to tease out the strategy that you’ll need to use in combination with your data structures and algorithms. That will help you answer almost any interview question.

  • Your Interview Mindset

    You're not going to make it through this section unless you have the right frame of mind. Simply wanting a job isn't enough - you need to calm yourself and focus.

  • Getting Past the Screener

    Before you get to the white board you'll likely have to pass an introductory screening interview - a short call (or in person meeting) to suss out what you know.

  • Databases: How Would You Implement...?

    Screener questions tend to have a bit more broad and, typically, based on your experience... sometimes not. Think about how you would answer this one about databases.

  • JavaScript: What Time Is It?

    Sometimes a potential interviewer will 'cosplay' with you - pretending that you work at the company and seeing how you might solve one of their realworld problems.

  • Understanding the Mechanics of The Interview Question

    Don't hate me... and PLEASE don't skip this video. Let's walk through Fibonacci together as a way of understanding how interviewers will flex and extend a single question to dig into your brain.

  • Practice: Stock Price Calculation

    This is a real interview question that comes straight from Amazon. You'll be writing this one by hand so remember your strategies.

  • Practice Question: Product of All Numbers But This

    A straightforward problem that, at first, seems daunting - until you break it down and apply the strategies you know.

  • Practice Question: Smallest Range of K Lists

    This is a tough one and you might struggle with it some. If you do, practice speaking aloud to get help from the interviewer.

  • Jon Skeet: Creating a C# Linter

    Another traditional question: create a linter for X language. This is more about parsing a string and remembering where you are within it.

  • Jon Skeet: Falling From Great Heights

    Not all interview questions have to do with code - some are purely logical, designed to see how you would try and solve a really, really hard problem. Skeet couldn't figure this one out...

  • Jon Skeet: Binary Tree Troubles

    It's a rule of interviews: 'ask a binary tree question' and that's exactly what I do in this video with Jon. Traversing in different ways, trying to balance along the way.

  • Jon Skeet: Creating a Queue from Scratch

    This is another very popular question from larger companies, and requires you to be familiar with linked lists, arrays and stacks.

  • Jon Skeet: Anagram Checker

    Let's end things with one that's a bit simpler - creating a string walking function that evaluates anagrams.

Watch Again



Next Up