Just launched! Get 30% off Rails Revisited Have a Look

JavaScript: What Time Is It?

Buy or Subscribe

You can access this course in just a minute, and support my efforts to rid the world of crappy online courses!

Buy Standalone  Subscribe

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.