
Ask HN: Scolded on a job interview for not namespacing - jason_slack
I went on a job interview for a Quant position.<p>I wrote out some c++ and I used namespaces like: std::cout, std::merge, etc. I did not write: using namespace std;<p>The interviewer just lost it. Went on this rant that &quot;how can programmers now write such confusing code&quot;, &quot;just name space it ahead of time&quot;.<p>And he was just plain mad. Uncomfortable mad. I tried saying &quot;what if functions have the same name&quot;..he spouted off about &quot;how compilers are smart enough to know what the programmer wants based upon parameters provided and why would any programmer use functions with the same name and how so many people he talks to don&#x27;t know how to code but call themselves coders...and why didn&#x27;t I write my own code to merge 2 files. Did I need to use the std..&quot;<p>What does everyone else do?<p>using namespace std;<p>cout &lt;&lt; &quot;blah&quot; &lt;&lt; endl;<p>merge(...);<p>or<p>std::cout &lt;&lt; blah&quot; &lt;&lt; std::endl;<p>std::merge(...);<p>and I always use std:: instead of writing my own. I mean &quot;time tested&quot; versus &quot;have I had enough coffee...&quot;. In 25 years of c++ I always used std:: before re-creating.<p>Has anyone else had a horror interview like this?<p>Edit: I didn&#x27;t shout or get mad. I practiced my Buddhist learning and turned the other cheek without emotion.
======
cletus
Honestly if I ever had someone yell at me in an interview I'd just pick my
stuff up and walk out.

Cheap way of figuring out you don't want to work there. Give feedback to the
recruiter of what is unacceptable behaviour.

As to the actual point I'm with you: be explicit. I write std::cout too. Not
that I'd get upset if someone used "using namesace std" as long as such using
statements are used judiciously, it's fine. Like if someone creates something
claled "cout" in namespace "foo" and then writes this:

    
    
        using namespace foo;
        ...
        cout << 3;
    

Then yeah I'd ping them on a code review.

~~~
vehementi
Why bother giving feedback to the recruiter? That's only going to improve the
company he's not going to be working at, rewarding them for already failing to
do their jobs (who put this guy is an interviewer's position? etc.)

~~~
notacoward
Feedback is not a reward. It's a way to improve processes, and if we _as a
group_ give feedback then we _as a group_ benefit. That recruiter might move
on to another company, and you might benefit when you interview there next. Or
you might benefit from someone else having given feedback to a recruiter at
the next place you interview. Or it could come back to you in myriad other
ways.

The idea that it's only worth doing things with a _direct and immediate
benefit_ might appeal to some people's Randian insensibilities, but it's
really quite broken.

------
darkstar999
> The interviewer just lost it. Went on this rant

> And he was just plain mad. Uncomfortable mad.

Good thing you found this out during the interview. No way you would want to
deal with this on a daily basis. That's insane. If the company has an HR
department you should consider telling them what happened.

~~~
crankylinuxuser
> HR department you should consider telling them what happened.

Why? Better you dodge a bullet and GTFO. Don't waste time with telling them
what they probably already know.

~~~
matthewmacleod
Fine to dodge the bullet, but please always provide the feedback if possible.
It takes minimal effort, and can help avoid the same unpleasant experience
happening to others in the future.

~~~
crankylinuxuser
I've done hundreds of interviews of various types. Do you know how many have
provided me feedback? 1 (see below). All others either sent me a form email or
ghosted me. Perhaps if I went through a recruiter, I would give the recruiter
my feedback as a professional courtesy there, but I'm not opening a dialog to
some HR department.

And that unpleasant experience is also a very good sign to prospective
employees to "DONT WORK HERE". If that's how they treat people they're
courting, I want to know that up front, rather than see it a month later after
relocating. So no, I don't want them to fix it (in reality; delay it).

I want interviews to be the same way as a Unix process: fail quickly and fail
loudly. And this interview certainly did that.

(Glowforge, I didn't have the experience in the areas they were asking. And
I'm happy they told me. And they were up front with me within 2 days, at
that!)

------
umvi
I personally use namespaces in .cpp files, and explicit scoping in header
files, but... that seems like such a small style issue to pick a fight with
during an interview. Steer clear of that company.

------
ilkhan4
Not an answer to your question (I primarily write C#), but sounds like you
dodged a bullet, really. That guy would have been horrible to work for/with
based on what you described.

------
swish_bob
Ah Quants. All the best shouting matches in my last office were between the
Quants arguing over things that ultimately were a matter of taste. Proper
storming out and slamming of doors arguments.

~~~
busterarm
In the short time that I worked at a quantitative hedge fund (all of 2007,
basically), the quants were the absolute nicest, friendliest people in the
whole company.

If you were even slightly technical and curious, almost any of them would
answer whatever questions you had and would casually shoot the shit about
anything in their nerdy areas of interest.

This in contrast with the one floor trader who repeatedly and forcefully
kicked me while I was under his desk replacing the Bloomberg keyboard he
spilled his Sprite all over...because 3 minutes and from half the building
away wasn't a fast enough response time for him.

~~~
swish_bob
I've known lovely quants. Can't think of any traders who were just plain nice.

But their ability to (as frankly average programmers) get into shouting
matches (in front of a room full of above average programmers) about shit that
didn't matter? Never been beaten.

------
wnkrshm
At least in my experience, no compiler will save you from having to suddenly
manage namespaces if you add a dependency mid-project that has namespace
collisions.

I always use STL functions with the explicit namespace, since I work in the
namespace of the code I'm writing by default (to not cause other people
problems with collisions down the line).

I've seen this done in other projects and thought it was a good practice.

~~~
xemdetia
I agree that this is generally good practice, and if the interviewee explained
that it was just to dodge problems with making assumptions with a large
codebase/build process I would always give them extra points. It almost is
telling that the codebase that the interviewer was working in was rather small
(not in a negative way) that these stylistic issues didn't fit his current
mental model, but such is the way of C++.

------
stephen82
No matter what type or kind of interview you go to, it is unacceptable to be
treated like this, even if you have started talking nonsense or unrelated to
the interview questions.

This guy's attitude represents what is currently happening inside that
company: the environment must be extremely toxic to work in and as the others
have said, you have just dodged a bullet.

In all seriousness, I wouldn't want to work for such a company, even if they
paid me 1 billion dollars.

Prestige and dignity above all mate, heads us!

~~~
fredley
A billion? I'd do it for a billion. I could put up with a year of that for
unimaginable wealth. Probably even a million to be honest.

~~~
ninju
$500,000 USD is the lowest I would go

------
scarface74
That tells you a lot about the company. Even if he didn't yell at you and just
spent a lot of time arguing about code style, it still tells you a lot about
the company - that they are probably a lot of architect astronauts who are
more concerned about minutiae than shipping software.

Also a warning sign - applying for a senior level/architect position and most
of your interview is spent writing leetCode and not discussing higher level
concepts.

------
chrisbennet
I _used_ to use namespaces but a developer/client of mine had some sort of
issue with them. (By issue, I mean a technical problem like name collision or
something.) Ever since then I stopped using them. I find it helpful to be able
to look at function name and instantly know what library it came from.

Added: You dodged a bullet.

------
w0utert
Where I work 'using namespace std' is explicitly forbidden, and rightly so for
exactly the reasons you point out: there's way too many common names in std::
that could clash with our own code.

More broadly, 'using namespace' is strongly discouraged except for our own
namespaces. In all but a very narrow set of exceptions, we prefer to make it
immediately obvious what functions are from external dependencies when
scanning the code.

If the interviewer finds adding explicit namespaces 'confusing', the problem
is with him, not you.

------
masmullin
I believe that the 'using namespace <xxx>;' is discouraged now-a-days.

I believe the more preferred way is to be explicit by 'using std::cout;' for
each and every function you want to "shorten/cleanup"

------
paul7986
Red flag for someone you don’t want to work with or under. They have no people
skills.. treating people/those you work with kindly & respectfully is more
important then your insecure ego & silly mad perfectionism(which is subjective
& your Strive for your perfectionism just makes you look like a jerk unless
your best buds with the head jerk).

------
alistairSH
As an interviewer, I generally wouldn't care about style. Unless it was
something really strange, in which case I'd probably ask about it to see if
there's a good reason for the strange style.

As an interviewee, like others have suggested, this is a serious red flag that
you don't want to work there. So, in a way, mission accomplished.

------
btschaegg
To answer your final question: No, I haven't. Lucky me :)

I think there's multiple levels to this.

1\. On a personal level: You clearly dodged a bullet.

Also:

> I didn't shout or get mad. I practiced my Buddhist learning and turned the
> other cheek without emotion.

Kudos to you.

2\. On a more organizational level: That's what style guides are for, end of
discussion (a coherent code base is worth much more than individual subjective
quibbles). Would the guy have been a professional, the answer should have been
"you'll have to change the style to match our style guide, but that doesn't
matter here".

3\. On a technical level: I don't write much C++ code nowadays, but yeah, I
also always use the std:: prefix.

My reasoning would be this:

\- "using namespace X;" in a header is a no-go anyway (I don't think is
negotiable).

\- In a .cpp file, I'd rather only operate in one namespace implicitly to
avoid a giant mess of overloads. To the argument "compilers are amazing":
Editors are not, I can guarantee you that much.

\- I never write code for std, since that's reserved for the standard library
and STL. So, for me, there's no valid reason ever to use "using namespace
std;".

\- On the "confusing" argument: I'd wager you'd never use std::cout directly
except in very simplistic scenarios. Usually, there's either an abstraction
(typedef is your friend there, if you want simpler names), or you write your
own functionality on top of it (certainly not in the std:: namespace).
Similarly, if one of your functions contains more than a couple instances
std::<whatever>, it probably is way too big, anyway.

But then, the technical level is the most subjective part of all of them.

------
rdiddly
It's possible he was acting, trying to put you in a "high-pressure situation"
to see how you'd react. If that's the case it sounds like you probably did OK.

If on the other hand he was just being his normal charming self, then I guess
you now know why they're hiring. Nobody hires because it's awesome; they hire
because they have to. Which is because the last person quit. Which is because
of this asshole.

I've had rude interviewers, but never to the point of ranting like that. In
the moment I mostly just keep going with the rest of the interview and make
the best of it, but later on I always come up with lots of ballsy things I
could've said. Including some version of the above like "OK I think I just
found the source of your turnover problem" and point at the guy...

------
zunzun
Based on your description of their behavior, the interviewer sounds like an
socially insecure and technically incompetent programmer. Even worse would
have been if you were hired and worked with this person as organizationally
senior to you (shudder). Not exactly "Mr. Mentor" material.

~~~
adonnjohn
I can't imagine a universe where a well-qualified senior developer would be so
obsessed with such a pedantic thing. To call the code unreadable because it
needs a small refactor... that interviewer was clearly letting their emotions
guide their thought process. Advise why to use the namespace, hear what the
interviewee has to say, tie off the discussion, and move on.

"Rockstars" who can't teach do long-term damage to engineering culture.

------
aantix
I had an interview where the interviewer was much more concerned about looking
smart and presenting his cleverly chosen question, than ever wanting to know
if I was a good candidate.

I even told him that his overbearing interjections we’re throwing off my
rhythm.

I never heard back from him. Probably for the better.

~~~
mrfusion
I’d say that’s 60-80% of interviews. Especially group interviews. Everyone’s
first priority is to look smart.

~~~
aantix
10 Tricks to Appear Smart During Meetings

[https://medium.com/conquering-corporate-america/10-tricks-
to...](https://medium.com/conquering-corporate-america/10-tricks-to-appear-
smart-during-meetings-27b489a39d1a)

------
jb3689
Losing it _any_ time at work is totally unprofessional. Don't work with these
people. Moreover, interviewers go bananas over the strangest things sometimes.
Just be reasonable and agree with or politely disagree with feedback

------
_Nat_
> I tried saying "what if functions have the same name"..he spouted off about
> "how compilers are smart enough to know what the programmer wants based upon
> parameters provided [...]

This sounds like a potentially challenging social situation!

On the one hand, your preference for more explicit syntax has a lot of real
merits, e.g. avoiding naming collisions as you've stated. But, if the
interviewer's ranting and not quite willing to give due consideration, how do
you handle the conversation (besides walking away)?

I think I'd take it like this:

1\. Let them vent a bit.

2\. Make an analogy to [weak-vs.-strong type
systems]([https://en.wikipedia.org/wiki/Strong_and_weak_typing](https://en.wikipedia.org/wiki/Strong_and_weak_typing)).

3\. Acknowledge the merits and opportunities to benefit from the interviewer's
preference (which is analogous to weak typing).

4\. Suggest why you feel that, despite their own position having merits, you
lean toward stronger syntax in your own coding.

5\. Point out that you fully understand the weaker syntax and would be able to
use it if called for on-the-job.

Since C++ is strongly typed and you're presumably interviewing for a C++-based
position, you might focus on a consistency-of-design argument, perhaps gently
putting forth the perspective that weaker syntax makes source code more
script-like.

------
ryandrake
Most of the comments here are focused on the interviewer’s behavior. As for
the code, I make it a policy to never, ever use “using namespace x” because of
the potential of namespace pollution/confusion. Always prefix standard library
identifiers with std::

I didn’t think this was even controversial.

I also always use this-> to access members even when I don’t have to. Write
things explicitly so there is no potential for confusion when someone else
reads your code.

------
mpurham
Generally never use the using namespace std given there are a ton of functions
from std library that I do not need.

I had a similar experience but, in a much friendly environment except I did
the exact opposite. I actually wrote a blog post ([https://marcell.me/using-
namespace-std/](https://marcell.me/using-namespace-std/)) about this last
week, feel free to check it out

------
jolmg
I don't write C++, but in Haskell I always either list what I'm importing in
the import declaration:

    
    
        import Data.Time.LocalTime (getZonedTime, localDay)
    

or I qualify it:

    
    
        import qualified Data.Aeson as J
    

That way any uncommon identifier that's not defined in the same file is easy
to identify where it came from. If I see `J.Value`, I know it came from
`Data.Aeson`. If I see `localDay`, I know it came from `Data.Time.LocalTime`.
Yes, the compiler is smart enough, but I don't care so much about it as I do
to the humans that read the code, including myself.

> and why would any programmer use functions with the same name

Because they would otherwise be resorting to Hungarian notation.

For example, J.Value in my example above is for JSON values, but if I were to
import:

    
    
      import qualified Database.Esqueleto as E
    

E.Value would be for SQL values.

Similarly, `Data.List.empty` tells me if a list is empty, while
`Data.Set.empty` tells me if a set is empty.

------
dagi3d
I am not c++ developer myself, so can't help on the namespacing decision,
although a quick search on a project made by google, it seems they don't
although I assume it will change from team/company to team/company who might
have their own guide styles: [https://github.com/google/flutter-desktop-
embedding/search?q...](https://github.com/google/flutter-desktop-
embedding/search?q=std%3A%3A&unscoped_q=std%3A%3A)

having said that, the question here is not who is right but the unprofessional
behaviour shown by the interviewer.

I'd suggest to write to the company's HR or even to one of their c level
managers and tell them about this situation. I think it's hasn't been the
first time and that even this toxic behaviour is not a surprise within his
coworkers.

------
friedman23
You were interviewed by someone dumber than yourself. It's simply amazing when
someone gets angry about something and they are also wrong.

You should name and shame them. Imagine if you didn't have the good fortune to
be interviewed by this person. You would be spending the next 2 years
debugging his merge code haha.

------
tabtab
Many people have little things they obsess on, or at least over-focus on.
That's just human nature. If you do something that agitates them, then chalk
it off to random bad luck and move on. Everyone has their own code style
preferences.

Related:
[http://wiki.c2.com/?NarrowStaffSelectionFactors](http://wiki.c2.com/?NarrowStaffSelectionFactors)
,
[http://wiki.c2.com/?StuckOnPetFactors](http://wiki.c2.com/?StuckOnPetFactors)

------
iamunr
Sounds like you learned you don't want to work there - what a joke.

------
lfowles
> Has anyone else had a horror interview like this?

Here's my horror story from last year where the interviewer was getting
frustrated at my mistakes in dictating C++ over the phone and abruptly cut off
the interview with "It's clear you are not right for this position. Goodbye."

This was for a hedge fund infrastructure dev position... I wonder if there's
something in the water?

[https://news.ycombinator.com/item?id=17727794](https://news.ycombinator.com/item?id=17727794)

------
mortivore
I have not. Once had an interview where the CEO was in the interview for an
entry level dev position. That was weird. Nothing where there was shouting.
That seems very unprofessional.

------
kerrmudgeon
Were you able to complete the problem within reasonable time, otherwise?

As an interviewer, I get frustrated if the candidate wastes time writing
excessively prolix text while missing the meat of the question. This is by no
means an excuse for hostile conduct, and the additional context here makes it
clear the interviewer is kind of a jerk in addition to being narrow-minded.

------
sys_64738
Definitely unprofessional and disrespectful for an interviewer to have a
temper tantrum during the process.

The nearest I've had is a manager who was angry in a 1:1 when I disagreed and
blew a gasket. That just made me smile as I thought it was funny but I stopped
him there and left the room. Nothing more was ever said of that meeting.

------
JohnHaugeland
1) Your style of code is much more common

2) Even if it wasn't, either or, it's not a big deal.

3) That kind of behavior is not normal even in the presence of a serious
problem. I would expect self control around a security flaw in production, let
alone a triviality in an interview.

Don't tolerate this. You're worth more than this.

------
icedchai
I hate typing the same thing over and over... so, yeah, I'd use namespace std.

However, for an interview, you are correct. This is something too trivial to
mention or "get mad" at...

~~~
w0utert
Typing is cheap. Debugging, reverse-engineering and refactoring is expensive.

Taking shortcuts just because you don't like typing a few extra characters is
a bad habit to have, it leads to the kinds of code that has obfuscated
variable names, no comments, 'clever tricks' that put way too much logic in a
single line, etc.

I used to think like you, but I realized saving a few keystrokes is almost
never worth it.

~~~
ifoundthetao
Except when it comes to Vim. Amiright? jk

But really though, this is solid, sound advice. And it's a great way to relate
it back to business value. The extra half-second incurred when it comes to
additional typing is going to be far less than the time saved when it comes to
clarity gained from looking at the code again. Whether that be for future
development, debugging, or whatever else.

------
cascala
Tell a senior person at the company, or the Human Resources person you dealt
with. Tell them what you experienced... this is unacceptable behavior and The
hiring firm should know.

------
ape4
It always seemed bad to import an namespace. Being explicit is better. But
'std' might be an exception since everyone does it.

------
flashgordon
You actually hit the jackpot. You just found really quickly and cheaply where
you do _not_ want to work and why!!!

------
cheez
They probably wanted you to fight back.

------
paulcole
This is part of why you go on job interviews. To figure out the places you
_don’t_ want to work.

------
blattimwind
> And he was just plain mad. Uncomfortable mad.

"Good day to you. _walks out_ "

------
cjhanks
Given that your examples of using std::cout are using the wrong I/O direction,
I am surprised you have "25 years experience of c++".

Perhaps, that annoyed him too. Still, yelling doesn't help much of anything.

Edit: OP changed post. Not fair to down vote....

~~~
jason_slack
I made it up for brevity in case the interviewer lurks here and used cin but
then removed lines. Thanks.

------
rajacombinator
Lot of pricks in this industry. Tell him to f off.

------
jessicatechexp
As someone who have worked in quant firm when people are losing money they go
mad.

Usually, interviewer wanted to put me into high pressure/stress mode to see if
i could still function rationally.

Not everyone does, i also saw guys who choked or started bleeding or lost
their temper and became violent literally when put under pressure. If the job
has such environment - interviewer must test whether you fit in or you'll be
better staying out of it for your own good. Cheers!

