What would be a professional response to “unfair” testing methods during a job interview

Question

I recently interviewed with a medium sized company. The job description was very general, one requirement was:

Good knowledge of at least one of the following languages: JavaScript, Python, C#, Ruby

I am a junior level Python developer. I have some very basic knowledge of JavaScript, but none of Ruby or C#

Upon arrival I was presented a test. I was asked to start a web-server using Ruby on Rails by using all the necessary steps (installation, initialization, creating a basic hello world page, making it accessible on local host and also handling a error along the way they had prepared). The timespan was very short. Since I had no prior knowledge of Ruby, I just started google, reading a quick tutorial on the official Ruby resource. I had completed the task about 40% - 50% when my time was up.

I was asked why I was unable to finish and I explained that I had no prior knowledge of ruby whether as a developer or in regards to dev ops or administrating a Ruby-based web server.

I was told the exercise was explicitly about seeing how I would handle technology which I know nothing about and the timeframe was intentionally too short. It was designed to see how the applicant would act under stress faced with an unlikely task.

However, I was later explained that my test would be graded “F”. I was disappointed and asked what would have been expected. I was informed that the grading was analogue to how far you have come with your solution. Since I was under 50%, I was graded F. I then asked how the result should have been for passing the test (being A and B in this case). A would have been the task fully completed, B would have been like A, only missing the last implementation of displaying the actual “hello world” message.

I may be wrong (since I have never worked with Ruby etc), but I feel like this test was very unfair since on the one hand side it was pretty much designed to struggle and fail, however it was graded like a normal test where the applicant would be able to implement the solution within the given time because he should know these basics.

During the following interview part my “bad grade” was referenced a few times. What would have been a professional response to this?

Answer 1

The professional response is to put on a smile, let them reference it all they want, take the free coffee or water offered, listen politely and then reject their offer.

An interview is a two-way street. They try to find out who you are, you are trying to find out who they are.

It's obvious there are no reliable results in a test that sets people up to fail and then grade all failures an F. You can set people up to fail to see how they do when failing, but then you need to have degrees of failure, or the whole thing is completely pointless.

So they told you you failed. That might be the truth because they are incompetent, or just their mind games to make you accept a lower offer. You think they failed in creating a test worth having. Be nice, smile, say "thank you for the opportunity" and, should you get an offer, say "thanks, but no thanks". They missed their opportunity to hire you. Their problem, not yours.

Answer 2

my test would be graded “F”. I was disappointed

There's no need to be. Tests are tests. They measure very different things and some interviews do so in strange ways. This is one. There's no point in caring about this apart from wondering how it relates to your ability to do the job.

I feel like this test was very unfair

Maybe. But again, you're getting hung up on a "grade". Once you're out of college, grades don't really matter any more. Your ability to perform does. This test is one data point that the interviewing company can use. If they are looking for a Ruby developer then it makes sense to reference a "bad grade". Maybe the interviewers are focusing too much on the grade aspect rather than what it told them about your (in)experience with what they tested for. But without knowing more about what they've said that's a hard call to make. There's a difference between "As a grade F I don't expect you to get this" and "Given your grade F, we'd like to make sure that you're still interested in learning about new technologies rather than only applying what you've done so far". The former is rude, the latter is something I would absolutely want to discuss. I probably wouldn't reference the grade itself because it'd make me feel like a schoolmaster, but I can see why some interviewers would. I'd simply talk about what I learned of your skills and experience. You should do the same and don't get hung up on the grade itself.

What would have been a professional response to this?

Focus on what they're talking about rather than the fact they're referencing a "failing grade". You would ask whether the fact you struggled is normal, how fast they expect people to pick up on new technologies, whether the tech used would come up in the job, what their support/training framework is like, ... If the interviewers get hung up on talking about this you would also counter some of that by pointing to feedback you've got in previous jobs/classes about picking up a technology quickly, being driven to learn, etc.

You could have asked a bit further about this specific test, though it's not like you needed to. Those questions would be things like:

• Given how you describe it, it sounds like it would be normal to get a failing grade, is that correct?
• You mentioned the "bad grade" a few times now, I understood it wasn't unexpected but did the fact that I struggled on that test give you any concerns about my fit for the job?
• Do you not typically hire people without prior experience in [technology] and mostly go for people who aced that test?

In all of these questions I would personally avoid talking about grades and tests and stick with asking about the fact you lack experience in something they tested for, just like you would do if an interviewer mentioned a technology a few times you're unfamiliar with. Your goal is to figure out if your lack of experience could be a barrier to not just taking the role, but thriving in it. It should be what the interviewer is doing as well, but there are plenty of bad interviewers out there.

The other answers point to using this aspect of the hiring process as a reason to walk away. I disagree. While every aspect of a hiring process should inform you about what a company is like it's not like one quirky test, strange interview question or even outright "unfairness" in the process means they would be a bad employer. Things are never that black or white and you should always look at the overall impression you get. You'll run into plenty of interviewers from HR who suck at interviewing technical profiles. But those aren't your future colleagues so it doesn't make sense to reject a job offer over it. It's the same with this. If the overall impression you get is that this would be a good place to work and that your skills are or will be well-suited to the job, then one strange interview question shouldn't put you off.

It's only when this fits into a broader pattern that you should start to worry. And even if they overall suck at interviewing, that's still not always a reason to reject the entire company. It means they probably struggle more than others to find the best people for a job which speaks to the potential quality of your future coworkers, but you need to factor that against all the other variables you're looking at when job searching.

Answer 3

If the job description calls for proficiency in at least one of four languages, with a test given in only one of those languages, the bias is obvious.

If the purpose of the test is "to see how the applicant would act under stress faced with an unlikely task", the only winning move is not to play.

Maybe the right answer was to push back on the unrealistic time expectation. It's hard to know what magic answer the interviewer was looking for. I do wonder if they give the same test to everyone, or if they give a Javascript test to the candidates who show proficiency in C# or Ruby.

Answer 4

Usually interviewers set up bizarre tests because they've been burned, not because they have some sadistic plan to torture candidates. If you honestly want the job, try to determine what they've been burned by and allay their fears about you.

In this particular case, I'm guessing they have had problems with people who can't or won't do work outside their preferred language. If that's you, there's nothing particularly wrong with that, you just won't be a good fit for certain workplaces. Other workplaces embrace the single-stack lifestyle and you should seek those out.

If you enjoy work that requires you to learn new things, but just didn't perform well on this particular test, then give the interviewers examples of times when you have jumped in on a problem outside your wheelhouse. If you have examples where being slower and more methodical has been beneficial in those sorts of circumstances, all the better.

Also remember this isn't a one-way communication, where they ask questions and you answer. You can start a discussion with them about their potential concerns, and empathize with them: "I'm guessing you've been burned by people who refuse to go outside their tech comfort zone. I learned a little JavaScript so I could troubleshoot more system-wide problems, and people really bother me who refuse to do that. I know I'm not as efficient as a JavaScript specialist though, so I usually seek their help before I waste too much time."

Answer 5

"I see. Given the grading rubric it seems to me that Ruby is required, so I'm not the right fit. It might make sense to update the job description.

It's been a pleasure meeting you. Unless you have any other questions perhaps we should wrap up?"

Rationale: A few key elements of a "profesional" response might include: know your worth, offer value, be concise, and show don't tell.

The test is either [1] poorly considered or [2] behavioral. This response covers both cases.

• First, You politely point out the disconnect (grading rubric not aligned with claim of Ruby not required). No need to make it personal or assume either case. You demonstrate a willingness to surface and calmly discuss issues.

• Second, you try to offer value. If the rubric is correct than the job requirements should align to avoid false positives. You demonstrate an ability to move past the problem to the solution. You offer a suggestion for improvement. You are calm, polite, and a team player. This does not 'throw' you and you do not make any assumptions.

• Finally, you concisely and politely put the current situation on the table. You value their time and yours. This is the chance for the behavioral interviewer to 'come clean' or risk losing you. You achieve situational mastery via a conflict neutral approach.

With this approach you [1] 'win' the interview and [2] gain a lot of additional information. A number of the other answers assume one case or the other, which is a common mistake.

Answer 6

I think there were better ways you could have handled this. You don't explicitly state this, but the whole narrative of your question reads as if you felt you had to do these challenges in order to earn a job from people who were in a position to either accept or reject you based on task performance.

In reality, you were presented these challenges as platform on which you and the people interviewing you could learn about each other (whether that was their conscious intent or not). And what would a company want from you?

If they are wise, they would want someone who contributes to the overall success of the company, usually by doing things. But also by giving feedback and data to help them make better decisions. The last thing anyone wants is an employee who will take a task they can't handle, and quietly go off to fail without saying something.

So, what is the professional response? Tell them you have no idea and are highly likely to fail unless given sufficient time to research it. And possibly also that they are using an inadvisable interview strategy because they may see false positive results from poor programmers who happen to have Ruby experience, while filtering out valuable talent from good programmers who don't.

You could learn a lot about them from how they handle that sort of feedback, which also should be one of your primary goals in an interview.

If they wanted you to proceed anyway to see how you handle such a problem, it wouldn't be wrong to go ahead with it to let them see how you tackle new things. And they might have disqualified you anyway, in spite of your advice. In which case, they may have saved you from taking a fairly unhappy job.

Answer 7

The professional response would be to tell them that you have graded them F for their interview process and that you will be withdrawing. Then leave and count yourself lucky for having avoided such a toxic company.

Answer 8

Yeah, that seems odd.

I've been in software development for over 30 years. I don't know Ruby either. If asked to create a "hello world" web server in Ruby during an interview, I would first state that I did not know that language, and that it was unrealistic to expect somebody to do much of anything in a language they don't know during a short coding challenge.

I'm also not a web dev, so setting up a web server in ANY language is something that would not come super naturally to me. (I've done a tiny bit of work with setting up test web servers, but it's been several years)

If they insisted that I do it anyway, I would have done pretty much what you did. I'd do some quick research, and then take it in steps, achieving one small milestone at a time.

If the requirement was getting more than 50% of the implementation of a task (web server) I am not familiar with, in a language I don't know, I would press them, politely, on the appropriateness of their test.

Interviews are stressful. I am a hiring manager myself, and tend not to use coding challenges at all during interviews since I think it puts unreasonable pressure on the applicant. I ask them about their past projects, and ask questions to drill down on their domain specific knowledge, work habits, problem solving skills, etc. I might also pose a design problem and ask how the candidate would tackle it. I'm interested in their thought process and problem solving skills more than getting a specific correct answer.

Answer 9

The requirement stated:

Good knowledge of at least one of the following languages: JavaScript, Python, C#, Ruby

So it implies that you should have basic knowledge of the other 3 languages? Presumably, they would prefer good knowledge of more than one.

Then you move on to assess:

the applicant would be able to implement the solution within the given time because he should know these basics.

If the basics of Ruby include setting up a server and running "Hello World" then I would surmise that the testing did exactly what it was designed to do.

Answer 10

"Nothing to see here ... move along ... move along."

You really can't control how any hiring company/manager decides to construct their "entrance exam," but, as a (koff koff, wheeze ...) "old hand at this," I can also say that "most folks who construct 'entrance exams' like this" feel that they are situated in front of a gigantic fish-net that is only occupied by "those whose job-search cannot 'think outside the net.'"

Maybe it has never occurred to you that sites like monster.com charge tens of thousands of dollars(!) to retrieve resumes from their site.

If you're looking for a job – (1) "be creative," and (2) "bloom where(ever) you are planted."

No ... you don't have to "put up with this ... nonsense."

Answer 11

I try to remember 2 things when applying for a job:

1. Many people who are doing the hiring are not capable of identifying talent.
2. When filling a job, you only need to find a suitable candidate, so you can risk failing to identify all the suitable candidates.

Isolated stress tests are not very reliable or valid. Someone who already has a job would probably handle this better than if they were unemployed for a significant period of time. Very few, if any, programming situations require creating anything in less than an hour. If the nuclear power plan is going to explode in 15 minutes unless a line of C is fixed, you better get someone who really knows what they're doing. That would not be the time to find out who can learn a new language.

This quick programming test will tell who can learn quickly and knows similar languages to the extent they can apply it to a new one. However, many programmers have particular languages that the prefer and are reluctant to learn new ones. Or they're so oppose to other languages, they would hate every second they have to work with it. That's not a good situation for anyone over a long period of time. Quick learners are good to have, but what other evidence is there that they will deep dive into a language over a period of time? Knowing a couple of languages would help even if they're not the right ones.

Handling this professionally (finally, an answer) would be to not let if affect your job search. If doing tasks with a short time frame are stressful to you, practice. Expose yourself to it and try and get better. Learn how to evaluate the evaluation process that companies use. Were there other warning signs that this job may not be for you? If someone wants to test me under pressure with a quick task, but they came late to the interview, I'm not sure I want to be tasked with bailing them out of the mess they've created through their own incompetence.

Answer 12

Your question could be answered like two similar questions: what could you do during a test that did not match the posted job requirements, and what could you do after?

I think you might have offered to accomplish the end-result of the test using the job requirements, instead of the harder requirement they asked you to use. So, if the position says "one of the following languages: JavaScript, Python, C#, Ruby", ask if you could bring up the web-server and use JavaScript/Python instead to generate the HTML. You can always request something, though they might not be prepared to go that way. Requesting at the half-way point when you gave it a good try is fine too, though even harder to pull off.

After you've been through a test that didn't match your skill-set, you can still offer your own demonstration, though it would have to be short as people will want to keep a schedule.

The "professional" thing to do is not complain about their test; they may not be the ones who wrote the job requirements, and they only know about what their part of workplace requires. Perhaps the Python and Javascript positions have been filled, and they're just looking for the Ruby person now. Just as people who don't even meet the job requirements will still apply, often managers will interview other peoples candidates who were looking for something different. It's a time investment which is less likely to pay off for either side, but the few hours required might be better than interviewing no one.

Answer 13

A professional response is to chalk it up to experience and prepare for your next interview with a clear head.

Job interviews are competitive, and there are usually more qualified candidates than there are positions to fill. Even with the best preparation there will always be an element of luck involved.

Sometimes the job advert will be poorly written and you will waste your time (but not nearly as much time as the company does), sometimes the interview process will be poorly designed, sometimes you just aren't quite what the interviewer is looking for, and sometimes you will get the job.

Don't take it personally, fix any holes in your knowledge that are identified during the process, and move on to the next opportunity.

Answer 14

It’s a bizarre test. I’ve never used ruby, I don’t think I’ve ever looked at any ruby code. If you told me “write a web server in ruby” and that’s what I have to do, then subtask 1 for me is: Learn ruby. Not a single line of code for that web server would be written before I know the language. And at the point where I grab the keyboard, half of the task (the subtask where I learn ruby) is done.

But then I’ve never had a job where they were looking for cowboy developers.

PS. I've worked on one project that started around 1996 and is still going strong. What I'm doing right now has been started five years ago. Software development is not a sprint, it's a marathon.