I've built multiple SaaS, and some are used by multinationals. Yet, I fail miserably at tricky interview questions. In this article, I'm going to show you a few recent questions I got, and share my thoughts.
In case you haven't seen any of my work. In the last 12 months, I've launched testing-playground.com, updrafts.app, rake.red and a bunch of open source projects. I like to believe that I know what I'm talking about.
Question 1
Here is a simple design of a navbar menu, we are struggling to stick the
loginbutton to the right edge of the<nav>(borders are added for a better understanding).
<nav>
<a href="#">Home</a>
<a href="#">Products</a>
<a href="#">About</a>
<a href="#">Log in</a>
</nav>
<style>
nav { display: flex }
a { margin: 0.4rem; padding: 0.4rem; }
</style>
Options - Single Choice
a:last-of-type { margin-left: auto; }a:last-of-type { margin-left: 100%; }a:last-of-type { float: right; }a:last-child { margin-left: auto; }nav:last-child { float: right; }
My thoughts
The interview existed of 12 questions, that had to be answered within 16 minutes. That sounds doable, until you meet the trick questions.
Have you thought about the question? I think that a:last-child { margin-left: auto; } is the correct answer. But a:last-of-type { margin-left: auto; } works as well. As this is an automated interview, I can only hope that I choose whatever the interviewer prefers. As a:last-of-type is listed first, this is easy to get tricked by. Time is limited, so when the candidate is confident that an option works, they are going to choose that, and move on to the next question.
I usually tend to group the left and right options, and add a justify-content: space-between. Why is that not an option? Is that wrong? Can we talk about it?
Question 2
const raiseError = (message: string) => {
const err = new MyError(message);
throw err;
};
What is the return type of this function in TypeScript?
Options - Single Choice
MyErrorvoidnullundefinednever
My thoughts
The clock was ticking, and I chose void. As that's how I would annotate this function. Makes sense, right? Think again! The return type of this function isn't void, it's never. As it's impossible for this function to return.
To make it return void, the throwing should be conditional. (wrapped with an if)
I believe this question is wrong because it doesn't say much about your TypeScript experience. I mean, how many dedicated throw functions do you have in your codebase? Most functions are constructed in a way that they have a return path. Either with a value, undefined, or void.
And when you do come across this edge case in your day job, how hard would it be to place your cursor at the function, and wait for that pretty tool-tip to appear, telling you the exact return type?
Question 3
Which HTTP methods are idempotent?
Options - Multiple Choice
- All of them are idempotent as it is a stateless protocol
- None of the HTTP methods are idempotent.
- All of them except for POST, CONNECT and sometimes PATCH.
- All of them except for POST, OPTIONS and TRACE.
My thoughts
First of all, this was a test for a frontend developer position. Are frontend developers really expected to know if certain HTTP methods are idempotent or not? Isn't that for the API developers to know? I really did not know the answer to this question.
After the test, I found out that the HTTP spec does have this specified, while I assumed that it was for the API spec (like open-api) to decide.
Anyways, I guessed that all of them are idempotent, as HTTP doesn't hold state. My database does. But according to MDN, it should have been all of them except for POST, OPTIONS, and TRACE. Today I learned.
Now the question is, what if I make my POST handler idempotent? Doesn't this question depend a tiny bit on the API that we're talking about?
Question 4
Which of the following browser actions/events are triggered by changing the CSS property opacity?
Options - Multiple Choice
- Layout operations performed
- Painting/Rasterizing
- Page composited together
- None of the above
My thoughts
Seriously? For what would we need this? I guess that the browser does a repaint, so that excludes the last option. Opacity doesn't change the layout, so there wouldn't be any layout operations. But what about Page composited together? I don't know. I really don't. Does that make me a bad developer?
Let's move on. Do you still want that opacity on your navbar?
Trick Questions
There were six more weird technical questions that made more or less sense than the four above. But they all had one thing in common. It felt like they were trying to trick me, and it are questions that I don't need to know to be able to develop solid applications.
When I would need to know it, I'm able to open my browser, and find the right answer in a matter of minutes. I'm a developer, but I suck at trivia.
Two more questions to wrap this up? Remember... your time is ticking:
Question 11
How would you explain a complicated technical problem to a colleague having none to very little technical understanding?
Write answer here...
Question 12
How would you go about getting a buy-in for your project from multiple stakeholders at work?
Write answer here...
I don't know what you want me to say. Do you have more details? Can I get another coffee and 30 minutes of your time? Let's talk about it.
My score
The "nice" thing about this automated test, is that you'll get your score right away. I had a total score of 47%. I suck at React, HTTP, Communication, well, basically in every area.
As expected, a few hours after my submission, I got the following mail. A little surprised that that part wasn't automated as well.
Hi Stephan,
Thanks for doing the skills test! It was a tough decision as we've had so many great applications, but we've decided to move forward with other candidates. Really looking for folks who've got more experience with javascript.
Well, this really was a motivational experience (not). Do you know the saying "You've dodged a bullet?". That's how I came to think about this kind of interview tests.
As I also operate on the hiring side, this provides me valuable insights into how the industry works. But if any recruiting person is reading this, please stop it. You're hiring developers specialized in interviews. Not in creating awesome software.
Top comments (11)
That just sounds like a bad interview. Lately I've been conducting a few interviews at my company and the primary focus isn't what you know but how you employ that knowledge. We have a somewhat tricky technical part but we're just looking for your process. We honestly don't care if you finish or not, rather were you able to communicate the issue, do you know how to debug your errors, can you think through a problem.
Trick question interviews are just lazy interviewers honestly. Being really good at finding any answer is more valuable than just knowing a handful of trick questions.
That sounds like much better interview experience. I only hope you'll make that expectation clear to the candidate. Otherwise, they will still feel obligated to finish and will be hesitant to ask questions. The candidate must know that you're testing communication skills and not the ability to finish.
It was a very bad interview indeed. Luckily, there are also good ones. I've blogged about that as well: dev.to/smeijer/how-i-got-a-job-off....
That flexbox question sent me down an interesting rabbit hole with
align-self: I could have sworn that that was the fix for that type of situation, but that only works for cross-axis items. The way to do this without an extra container is to setmargin-left: autoon the item you need to be pushed over. I ONLY know this because I came across it in Josh Comeau's CSS course. It's handy, but arguably trivia/epherma.This is the absolute worst interview experience I've read about. Tests like these cater to those willing to disregard requirements and take shortcuts. Because I don't see how anyone could score well without browsing for the answer in another tab.
A few days ago after having an interview with one recruiter, the CTO, and someone who was apparently a co-founder, I was asked to complete a 210 minutes (maximum time) test in codility. I am mentioning this here just because from my point of view (despite they are not multiple choice in general) codility tests are pretty similar to what is very well exposed as a concern in the post.
I didn't have time to dig into the test during the week because I was busy with my actual job tasks (I am looking for my next professional challenge). After that, the weekend came up, but I was doubting if dedicating 210 minutes of my relax/family time would be totally fair.
They pushed me on Monday. Kind of quoting: "Hey, we are kind of wrapping up the candidates for the position, did you had time to look at the codility test?"
So, after thinking deeply about the idea I created in my mind about the company based on the interview we had, and the pressure to work in a non-paid 3.5 hours depersonalized test, I decided to abandon the selection process.
I feel in general that we are obligated to show discomfort and struggle for fair recruiting processes for all of us. We should stand and get together to push companies to a more human and empathic process when they and we are looking for a win-win relationship in the future.
Every single one of these questions are HORRIBLE questions by which to evaluate devs.
Yeah, definitely. And these weren't even the worst. 😅
Great post.
I’ve run into similar types of questions and quizzes.
I hope those companies found who they were looking for.
If they were looking for people specialized in interviews, I'm sure they did. Universities like Stanford have classes dedicated to learning how to pass the technical interview.
web.stanford.edu/class/cs9/
I laughed out loud a couple of times! 😂 How do you honestly come up with stuff like this? 🤔 🤷♂️
It's crazy, right?