Ask HN: Scolded on a job interview for not namespacing
I wrote out some c++ and I used namespaces like: std::cout, std::merge, etc. I did not write: using namespace std;
The interviewer just lost it. Went on this rant that "how can programmers now write such confusing code", "just name space it ahead of time".
And he was just plain mad. Uncomfortable mad. 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 and why would any programmer use functions with the same name and how so many people he talks to don't know how to code but call themselves coders...and why didn't I write my own code to merge 2 files. Did I need to use the std.."
What does everyone else do?
using namespace std;
cout << "blah" << endl;
merge(...);
or
std::cout << blah" << std::endl;
std::merge(...);
and I always use std:: instead of writing my own. I mean "time tested" versus "have I had enough coffee...". In 25 years of c++ I always used std:: before re-creating.
Has anyone else had a horror interview like this?
Edit: I didn't shout or get mad. I practiced my Buddhist learning and turned the other cheek without emotion.
68 comments
[ 3.4 ms ] story [ 128 ms ] thread"Rockstars" who can't teach do long-term damage to engineering culture.
Added: You dodged a bullet.
Then comes this guy in afterwards...
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.
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.
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.
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:
Then yeah I'd ping them on a code review.isn't is the purpose of code review
Furthermore, interviews != code reviews. For an interview, not only is the candidate putting their best foot forward, but the interviewer should be putting their best foot forward, as well. It doesn't matter if Joe is the best programmer in the company -- if he's abrasive, you don't want to put him in front of prospective candidates.
There's something paradoxical about this statement, I'm not sure if it's the way I'm reading it, or even if you intended it that way. But if there was a "failure" here, and I were in that company's HR and Recruiting shoes-I'd probably want to know about it, and surely you would too if it were your company looking to grow and bring in talent to reach goals?
Would you tolerate your staff treating candidates this way?
We often see complaints here about how unwilling companies can be to provide feedback to job applicants. I’d definitely encourage applicants to similarly leave feedback for employers they reject, because it improves the system for everybody. And if you are in a position to do so, try to solicit feedback on your recruitment process from applicants too!
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.
If the company has this psycho in there interview rotation, he sends a strong negative signal, basically the company has a "tell" that candidates can use to avoid this guy or companies that would employ him.
If the recruiter coaches them to hide their "tell" [removed the guy from the interview rotation], they haven't really fixed the problem, just hidden it. Now, the next guy/girl who interviews won't know about the horrible guy he/she will be working with because the company "hid" him from view until it was too late.
> 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.
Why? Better you dodge a bullet and GTFO. Don't waste time with telling them what they probably already know.
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!)
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.
I even told him that his overbearing interjections we’re throwing off my rhythm.
I never heard back from him. Probably for the better.
https://medium.com/conquering-corporate-america/10-tricks-to...
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.
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!
However, for an interview, you are correct. This is something too trivial to mention or "get mad" at...
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.
Would you fully qualify every reference then? I'd argue that would add more clutter and obfuscation.
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.
Perhaps, that annoyed him too. Still, yelling doesn't help much of anything.
Edit: OP changed post. Not fair to down vote....
"Good day to you. walks out"
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.
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.
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).
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.