29

I had an interview for a website developer position. The interviewer asked me to tell the difference between Frontend and Backend. I explained and gave "Angular" as an example for Frontend. The interviewer corrected me that Angular is a Backend.

I'm pretty sure Angular is a Frontend. Maybe the interviewer was wrong, or maybe he tried to test me. But honestly, I was still a greenhorn and scared. I didn't want to argue back and lose my chance. So, I just apologized and went along with him. Moreover, this is just a definition, it's not like the system will be broken down if he mistakes it.

I wonder if what I did was wrong? Should I have been more confident and convinced the interviewer?

  • 3
    Are you sure it wasn't a trick question/comment? – Kingsley Jan 23 at 21:37
  • 8
    You shouldn't edit your question to respond to comments directly, as such commentary is not really part of the question. Instead, if relevant, you should edit your question as a whole to read as if it were always the best version of itself, including any necessary clarifications or details. (In this case, just mentioning that you like the answers here better doesn't really warrant noting in the question.) – V2Blast Jan 23 at 22:04
  • to be fair, angular is a frontend framework not a front end per se. i also wouldn't call angular a backend for the same reason. to me it sounds like the interviewer isn't really a developer and is misusing definitions. – chris Jan 24 at 10:43
69

Ignoring whether angular is the frontend of the backend, as that's not the point here.

Should I have been more confident and convinced the interviewer?

In short, yes.

Being right is only part of the battle, being able to convince others that you are right is the other, usually much harder part. Similarly, it's as important to know when you may be wrong, and have enough doubt to yield to someone else expertise, though then you should also know what questions to ask, so you may understand why you were wrong, and the other person right.

So instead of saying, for example:

I'm pretty sure Angular is a Frontend.

You can instead explain your definition of the frontend, backend and relation between them, and how you see angular fit into that world. Then the interviewer can respond by pointing out something wrong with your definition, and explaining why it is wrong. To which you can agree, or disagree - again explaining why do you think you are right.

That changes the dynamic from flinging "you are wrong" or "you are right" into an exchange of knowledge.

|improve this answer|||||
  • 57
    You could also say, "on the xxxx project, I used it as a frontend framework" and then explain. Then you could say, "it's interesting that you use it in the back end here. Can you tell me more about that?" Intelligent conversation is always OK in interviews. – O. Jones Jan 23 at 12:47
  • 1
    @O.Jones indeed! Even if in the end your initial assertion will turn out wrong, that's perfectly fine as long as it's handled the right way. – Tymoteusz Paul Jan 23 at 12:49
  • It doesn't even have to be a conversation, since interview time is valuable. One could say "I've considered it frontend, for reasons X, Y, and Z. I'll look into the matter some more later today, since I don't want to derail our meeting, unless you'd like to discuss it some more." You can still display your position and knowledge, but don't have to make a big point of it (especially valuable in the case where you happen to be incorrect). – Upper_Case Jan 23 at 17:41
  • 2
    @Upper_Case It doesn't even have to be a conversation, since interview time is valuable. Actually, if there isn't time for conversation when I'm only considering working there, then you can sure count me out of the people whom will ever work there ;) Just saying. There should always be time to talk/chat/converse about technologies. Anyone, especially those you've only just met, can have valuable insights and ideas. So yea, there should most definitely be time to discuss. If short on time, either skip whatever was planned or schedule another meet. – rkeet Jan 23 at 21:44
  • @rkeet Conversation is great! Especially on a technical subject during a technical interview. What I meant was more along the lines of "in a time-limited setting where only so many discussions will be possible, is a discussion of 'X is frontend or backend' one of the conversations you want to have?". My comment above wasn't too clear on that. Angular definitely isn't my area of expertise, but is that a conversation that sells you to the interviewer? If not, then it wouldn't be worth dedicating time to. If so, then discuss away! – Upper_Case Jan 23 at 21:55
16

The interviewer asked me to tell the difference between Frontend and Backend.

This was an "explain like I'm five" sort of question. Personally I would have started more vague and then went over libraries/frameworks.

Maybe the interviewer was wrong, or maybe he tried to test me.

It seems more like he was testing how much of a spine you have when presented with an inaccurate statement. I would have asked for some clarification.

Him: Angular is backend

You: Other UI frameworks/libraries have server side rendering, and can be used in back-end with node.js or another back-end environment. Angular by itself is normally used as a front-end UI framework. Do you mean server side rendering with Angular?

Use it as a learning opportunity, but be careful when you think you know something 100% you could be wrong. How the interviewer responds gives you the opportunity to see how he handles these sorts of questions.

|improve this answer|||||
  • 2
    I've been in a lot of interviews over the years. Thinking the interviewer is testing you at a meta-level rarely happens. To give an example, I once had a panel of interviewers break into an argument with two trying to convince a third I answered a question correctly. I doubt it was some sort of meta-test (although it did provide me with some insight into the company). – Edwin Buck Jan 24 at 3:18
5

Both approaches in itself are not ideal. I.e. giving up and apologizing when you know you're right, or just making a statement without backing it up.

Giving up and plainly apologizing shows that you're not someone who's going to be able to make a point or help the company go into the right direction when you don't let them know about mistakes you're aware of.

At the same time just saying "you're wrong" is not helpful in itself. However if you were to explain the difference between the two concepts and then explain why Angular (or whatever you're talking about) fits in one category but not the other, then you can educate and explain how someone's wrong.

Maybe it's a test, maybe it's not. Whatever the case you should always stay your ground but don't make a big deal out of it. Educate and explain why you see it the way you do and if that's not enough then let it rest, you've done your part, but don't apologize when you know you're right.

You don't need to convince anyone in most cases, but you should show that you can do your job and a part of that is communicating your knowledge. If it's a business critical matter then yes, you should put more effort into backing up your claim but at the end of the day it's okay to agree to disagree as long as you can explain why.

|improve this answer|||||
5

It's a very fine line to walk.

If the interviewer is testing for the presence of a spine, you want to show you are confident enough to stand your ground without giving the impression that you are likely to be stubborn or quarrelsome.

On the other hand, if they are genuinely mistaken, you should be reluctant to let them leave the interview with a mistaken impression that you don't know your stuff. BUT, if you push it too much, you risk coming across as stubborn, quarrelsome and (if you fail to convince them) not knowing your stuff.

Tactfulness is your friend here. Stand your ground (but not too forcefully) and back your position up with additional knowledge.

I'd always understood it to be a front-end framework on the basis that....

Equally as important as standing your ground, is finding a way to shut the conversation down in a polite, professional manner without conceding the point if the interviewer refuses to budge. There is no value in letting the situation escalate to a "yes it is" "no it isn't" farce similar to Monty Python's argument sketch.

Well maybe it has some backend use-case I've not come across yet. My experience in it so far has always been part of the front end tool-set.

|improve this answer|||||
2

No, the interviewer wasn't wrong or trying to trick you.

I do however think it was a silly question to ask, and that shouldn't count against you. JavaScript is commonly referred to as a front-end thing however it's both.

Front-end refers to the presentation layer. That is your HTML, CSS and JavaScript (when it's used to manipulate the layout of a page).

Now that JavaScript has evolved, and when used to create entire applications on the client-side (or a server-side node app) it's no longer strictly front-end. It's actually back-end.

The client-side has a front-end (HTML, CSS, JS), Angular (also JS) is the back-end but it's on the client-side and usually built by a front-end developer.

What you would have called the "back-end" has now become the "server-side".

Basically the phrases front-end and back-end have become too blurred. I have stopped using them and now use: client-side and server-side.

As for what you should have done. If an interviewer corrects you, and you still don't understand their point of view, as them to explain it. It might turn out they end up agreeing with you, or worst case you end up learning something new.

|improve this answer|||||
  • Of course if you start mixing up the terms and calling things in way they shouldn't be called, anything can be anything. Angular is clearly a FRONT-END development framework and in no way a BACK-END framework, even if you use it as SSR (which is not even that common with angular) it's still a FRONT-END framework. JS is a language that can be either used in front-end or back-end so yes, in this case, the interviewer was wrong saying angular is a back-end (= server-side) framework and the interviewee should have stand his ground or ask for clarification on this statement if that mattered to him. – toto Jan 24 at 11:06
  • You are correct if you consider everything client-side is front-end, which is technically incorrect. Front-end only refers to the presentation layer. A pure client-side SPA has a front-end and back-end. The JavaScript framework used to power it would be considered the back-end, and likewise back-end doesn't mean server-side. It means the back-side of the presentation that drives it and that could be either client or server side. – flexi Jan 24 at 19:04
1

You could have chosen to meet in the middle and acknowledge their line of thinking without disrespecting it:

Hmm, I certainly understand how one could interpret Angular to be backend; it is certainly a feature-rich and complex framework.

I typically classify it as a frontend framework since it operates in the client's web browser.

|improve this answer|||||
  • This reads like you are calling the interviewer an idiot "I can see how you might be confused in to thinking A is B but I tend to call it A because it is A" – Qwertie Jan 24 at 5:03
0

A good interview is a two way conversation. Your interviewer is ultimately just another person working in your industry who will eventually be a colleague and a peer, if perhaps a senior one.

Sometimes they'll be wrong about objective things, as will you, but more often there won't actually be a clear right/wrong solution to a problem and finding one will involve debate, collaboration and compromise.

They want to hire you to help find these solutions, so use this type of situation in an interview as an opportunity to test that way of working with them, and to show them you can do it in a productive way.

Far from being something that would put them off, you doing this is actually the very best way you can demonstrate how good a future colleague you could be. So yes, if they assert something fundamental to the job you don't quite agree with, ask them why they think that. Try to convince them otherwise, but likewise be receptive to them convincing you. Just as you would on the job.

|improve this answer|||||

Not the answer you're looking for? Browse other questions tagged or ask your own question.