DEV Community

Ankur Tyagi
Ankur Tyagi

Posted on

Top 5 Things NOT to Say in a Job Interview

Top 5 Things NOT to Say in a Job Interview 👇

Alt Text

Few of us enjoy job interviews. But if you’re going to land your dream job – whether it's a junior role or senior.

key phrases that will invariably mess up your chances, the moment you say them.

five key sentences to avoid, why they’re so inappropriate, and what to say instead.

1. “I want this much money”

Yes, many employers are out to pay you as little as possible.

Yes, you should be forthright and not accept less than what you’re worth.

But that doesn’t mean you should start laying down red lines before you’ve even got the job.

That attitude of ‘How much are you going to pay me?’, right away, immediately puts me off interviewing someone.

The problem is that some people who are just graduating often think they’re much better than they really are. But even with a four-year degree, they’re really not.

2. “I think my work speaks for itself”

If you’ve been asked to interview, it’s a likely sign that someone’s impressed with your portfolio. Good job.

But that’s only got you to the first stage.

To succeed at the interview, you’ve got to explain the thinking behind your work,

the challenges you faced and how you overcame them.

If you fail to grasp this, and wrongly assume that your work “speaks for itself.

“At the interview, we look for people who can articulate their creative process, describe the challenges they’ve experienced.

3. “I actually don’t know much about the company”

if you walk into an interview showing that you’ve made little effort to research your prospective employer,

why on earth would they think you’re going to make any effort as an employee?

So get creative with Google read about the company

4. “No, I don’t have any questions”

Towards the end of the interview, you’ll be asked if you have any questions. “And the worst thing you can say is NO

“Make sure you have some questions up your sleeve, to show you’re interested in the job and company.”

You think that if you’ve read the company properly beforehand, you shouldn’t have anything left to ask,

but that's a mistake.

Your research doesn’t reduce the number of questions you can ask at the interview, it simply gives you a chance to ask more intelligent and good ones.

5. “Yes, I can do that” (when you can’t)

In interviews, you should always sell yourself, exude confidence, and project an image of positivity.

But in doing so, it’s easy to get caught up in your own hype and start exaggerating what your abilities and skillset actually are.

“I think the worst thing you can say in an interview is something that’s untrue because if they sense you’re talking crap, you just look even more under-experienced,”

“It’s much better, to be honest, and say you don't know

Hope this helps you 💙👍

Latest comments (12)

Collapse
 
hyftar profile image
Simon Landry

I actually said point 3 in the interview for the job I currently work at. Thing is, I did do research on the company but it's in my company's best benefit to not advertise what we do so by extend they do not keep a lot of information about themselves online and their website was just a black page with an email to contact them. I think it's definitely possible to not know much about a company if it's a startup or in the same situation as the one I work at, a bigger no-no would be to lie about knowing a lot while not knowing anything.

Collapse
 
theonlybeardedbeast profile image
TheOnlyBeardedBeast • Edited

Point 1, they ask for it, I mean literally in every company they asked me how much I want, and at the beginning I was struggling with that, it is hard to define your value.

Point 2, It happened that they asked to explain my work, and I was happy to go through my github repo and explain what I did and why.

Point 3, true, but sometimes the company descriptions are so abstract that you really dont have clear view, anyway most of the times in the introduction they explain what the company aims and what it does.

Point 4, I am usually so in stress that I really cant think about questions, but I always tell them that "if anything comes to my mind I will contact you". Not the greatest answer but most of the times the interviews I had were around a hour with talking and company walkthrough and you know, really a lot of information at once.

Point 5, that should be basic.

Extra point, the interviewers know that you are a human being, and they usually threat you just like that, different personalities react differently, just be calm, be yourself and dont lie.

Collapse
 
stereoplegic profile image
Mike Bybee

Don't waste time if they can't be upfront about rate/salary range. If they get huffy about "well since you're bringing up money already," they're probably going to be cheap and you're probably better off not going much further through the process.

Collapse
 
eonuk profile image
eonuk
  1. “I want this much money”
    Ask what the range of the salary is. They will probably ask you (or at least the agency will) how much you want. If you provide a range, and they wont, then say "hang on a minute, your prepared to ask me, but wont give me a range? What is wrong with giving me a range?"

  2. “No, I don’t have any questions”
    Don't ask questions for the sake of asking questions, they will spot it. Ask something intelligent or not at all

  3. “Yes, I can do that” (when you can’t)
    Chances are there are aspects of the job you havnt done before. The worse thing you can say is something like "I dont know if I can do it / its going to be a big challenge" etc. If you know you can learn it easily enough, then lie

Collapse
 
sriram2520 profile image
Sriram

Points 2 - 5 are completely spot on. But I disagree with point 1. There have been instances where me as a candidate have invested 4-5 rounds of time, only to later discover that the salary range of the job opening was lesser than what I was willing to work for.

Every job opening has a salary range and unfortunately these are not public. Its better for both sides to save time, if the salary range doesn't overlap.

Collapse
 
stereoplegic profile image
Mike Bybee

If they can't be upfront about their salary range, it's probably too low.

Collapse
 
eljayadobe profile image
Eljay-Adobe

My advice is to be truthful. Any lie is a disqualifier. Any fib. Even blowing smoke or exaggerating. When an interviewer picks up on that, the interview is over.

I've been much more impressed with a simple "I don't know that" over confabulation of the thing the candidate doesn't know.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

Here's one from a fairly terrible candidate I had a while back, when I pointed out a major bug in his coding challenge submission.

He puffed up at once. "Maybe you don't understand what the coding challenge prompt was, but..."

I cut him off, something I never do as an interviewer. "Excuse me, sir, let me stop you there. I wrote the prompt. Been using the same one for seven years. I know the prompt."

"Oh."

Collapse
 
stereoplegic profile image
Mike Bybee

A seven-year-old coding challenge?

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

We've been using the same challenge for that long, because it gives us good comparative metrics versus prior submissions in many regards. It's unique to us. (And yes, we have a list of all the usual places where the solution may be "borrowed" from.)

Thread Thread
 
stereoplegic profile image
Mike Bybee • Edited

I understand that, and it has its merits, but the "usual places the solution may be 'borrowed' from" is sure to grow if the challenge doesn't evolve (I just watched a YouTube vid last night of a guy sharing every coding challenge he's ever done). I'm also not convinced that metrics are very useful when it comes to ranking creativity (even if, despite the Rockets' recent embarrassment, I still believe in Moreyball).

Also, personally, I secretly hope (I guess not so secretly, since I keep saying it on Dev and LinkedIn) that candidates are searching to "borrow" at least bits and pieces of the solution (the code review follow-up is where they prove knowledge of how the solution works, regardless of whether said solution is 100% original or not). I need to know that they know when it's unnecessary to reinvent the wheel.

FWIW I'm not at all excusing his attempt to bullshit you, and I applaud you for giving take-home challenges instead of utterly useless (for the hiring company, and pointlessly sadistic to the candidate) timed, on-the-spot challenges.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

We're aware of all of that, and yes, learning how others solve it is fine. We see some similar techniques, and certainly plenty of developers use libraries or common patterns, especially for the more predictable components. It is smart.

We're mainly on the lookout for two problems in that area: (a) people who copy/paste someone else's code — we've only ever had two candidates ever do that, mind you — and (b) people who copy/paste together code with no concept of what it's doing. Neither is amenable to coding-as-a-career. Situation (a) is easy to check with a web search, and situation (b) is exposed with the live coding that expands on the code they submit.

(P.S. We also know how to factor in nerves. They're actually a good sign: it means there's a human being there, who knows they're not perfect. It's the people who blaze through live coding with nose held high that worry me, and needfully so, as I learned the hard way over the years that they are always unteachable and toxic.)

But, returning to the original premise, there has been many an interview where, as they fix a bug live in their coding challenge submission, I'm quietly hoping they'll remember some built-in component that handles something for them. Often I will even give them a hint to that effect after giving them a few minutes to think of it themselves. After all, the entire purpose of both the take-home and live coding is to demonstrate how they work through a problem, handle natural roadblocks, and accept suggestions. I don't even expect them to necessarily fix the bug or finish the change in the live coding. I just want to see them try; it tells a lot about them.