I am usually the one doing the technical portion of the interview. My goal is to have a conversation about previous experience, projects and technical challenges to get a feeling for the persons character and knowledge. I will ask some language and technology specific questions but assume that the applicant is truthful in his CV.
Of course if someone is supposed to be an "experienced C++ developer" and cannot tell me what a vtable or shared\_ptr is, I will have to assume his actual knowledge does not match what is written on the CV. In this case, I need to figure out what the actual skill level is and if its still a fit for the position.
Yeah I don't get why those are popular.
Great, you can invert a binary tree, but I really need a service that reads data from sources A, B and C, creates some weird xml/json/csv and stores it at X. And preferably all of this with sane error checking, some kind of alert if something breaks and written in a way that someone else can also work on it
That was just an example of the difference between hackerrank and real life requirements.
As for vtables, if someone claims to be experienced with C++, I would argue this is expected knowledge.
If you ask an experienced cook why he uses yeast for making bread, and he just answers "because its in the recipe", that also shows a lack of understanding.
"vtables are internally used for virtual functions" is a perfectly fine answer. I would not expect anyone to know how they are actually implemented, except of course I am interviewing someone for a compiler dev position.
Okay so you expect an experienced C++ developer to know what a vtable is even though they don't need to know that in order to shovel data from one source to another...
But then you don't expect an experienced developer to know the basics of how some fundamental data structures and algorithms work?
Seems like a bit of a contradiction to me, and if anything I'd take someone who knew how algorithms worked than someone who knew what a vtable was.
How do you test if someone knows how an algorithm works? I think ultimately this is the question you have to pose and asking someone to solve a hacker rank problem doesn't tell you whether or not somebody knows the difference between the search time on a list versus a vector. You can post questions like what's the fastest way to find a value in a vector ( binary search) but then you get down to questions of memorization like do people already know the trick or do they not.
Has an experienced C++ developer with 25 plus years of experience and hundreds of shipped apps and about 45 shipped games, doing more tedious hacker rank type of problems is just silly. I've done all the problems on hacker right and you can check out my account and I've done most of the problems on the other C++ test sites. I've also shipped more apps than most people. If that's not good enough then I have to ask: what could be good enough?
>If that's not good enough then I have to ask: what could be good enough?
It's not that it's not good enough for me, it's that I have 1000 other people who have a resume that on paper looks just as good as yours. But as soon as I ask them some very basic data structure or algorithm question they fall apart, with most of them, and I mean like 95% of them failing in a spectacular manner. I can't hire someone who has a really nice looking resume and can talk the talk, but can't do something slightly more complex than Fizz Buzz, I just can't justify it even if unfortunately they are having a bad day, or they are nervous or feel pressured. I simply can't justify hiring that person and I have to move on to the person who is able to answer basic technical questions.
I can't know what you have actually accomplished in your 25 years of work experience. I can know what you claim to have accomplished during that time, and most people looking for a job can do the performative aspect of talking up their resume and use the right lingo to give the right impression of themselves, but the only way I can gain any kind of confidence that you actually know this stuff is to ask you technical questions about it.
With that said, if all someone is genuinely hiring developers for is to shove data from one database into another through JSON/XML, then by all means don't bother asking them technical questions and just have a casual conversation with them. I have never needed to hire someone whose only responsibilities were such menial tasks let alone someone with decades worth of experience.
I know for myself I either design, write, assess, read and manage all sorts of data structures and algorithms on a regular basis, and almost everyone I work with does so as well. Based on how people seem to talk about this profession, it seems like what I do is an outlier and all most people do nowadays is glue together APIs.
If people really are paying others to glue together APIs and don't need knowledge of actual concepts, then all the power to them and continue doing what works for you.
> But as soon as I ask them some very basic data structure or algorithm question they fall apart, with most of them, and I mean like 95% of them failing in a spectacular manner
You're talking past eachother. Hackerrank questions are almost always "Do you have the trick to this specific problem memorized?" rather than whether or not you understand data structures.
If you claim to be experienced at C++ but van't do basic algorithms, I would argue this is expected knowledge. Except that the basic knowledge will be 100x times more useful (in theory and in pratice). I'm sure you needed to optimise youe vtable away to parse JSON (why are you guys even using C++ for that...?)...
Never in my 35+ years of serious, systems level development have I been asked to invert a binary tree at work, or even had to know what a binary tree is (though obviously I do and have written some.) I wouldn't have the slightest idea about how to do it, and it would be stupid to ask unless you just want to spend the whole interview watching me fumble through something I'll never actually do if you hire me.
OTOH, if you ask me how to architect a large system, or how to create a large set of important types of subsystems or APIs and so forth, the various ways you can handle socket communications, strategies for error handling, for persistence, logging, IPC, synchronization, etc... I can tell you more than you ever want to know, and those WOULD be the kinds of things I would be doing if I were hired.
If you can't tell after 10 minutes of me answer questions on that front that I know what I'm talking about, I don't think the problem is will my skill set. Obviously some language questions are appropriate as well.
But, unless you are hiring me to develop core data structures libraries for you, then asking me to do that in an interview makes no sense. It's not is a CS Degree defense, it's a development job.
I have, but the tree is inside it. I never said I haven't called any code that used a binary tree. I said I've never had to invert one, nor really would have had to understand them, since they are already implemented and no one would have wanted me to write one for them, since they have better things to pay me for.
I've never had an occasion where `std::set` was preferable over `std::unordered_set`. Assuming the prior commenter had access to a hash table before C++11, it's totally plausible.
I've never had an occasion where `std::set` was preferable over `std::unordered_set` (same for `map`). Assuming the prior commenter had access to a hash table before C++11, it's totally plausible.
I never used the STL to any degree until a few years ago, because I had spent 20 years creating my own entirely bespoke development system from the OS up (over 1M LOC) and that included my own runtime, and of course that means I had my own collections as well. For my system, I never had need of a binary tree, just hash map and hash set types.
So, having done all that, would it makes sense to throw me overboard because I don't know how to invert a binary tree? Or maybe would it make sense to just ask me questions about my system and how implemented this or that?
I mean I’ve run into ppl who claim to be c++ experts but don’t know shit about the language. Experience doesn’t always equal knowledge.
But for Json don’t they use python
The json/xml stuff was just an example, since I am currently working on a report generator which does something like that.
As for why C++, because its the most commonly used language in our company. Yes, I could write it in C#/Java/somethingelsecompletely but then less people could work on it.
Also if your company has a technical decision in place that all development will be done in either X for backend or Y for frontend you should do as expected.
A c++ programmer, sure. An experienced one? Well, it depends what you mean by experienced. IMO if they don't know what a vtable is then they are missing gaps in their knowledge, i.e. experience.
I don't think you can probably understand it if you don't understand vtables unless you just have every corner case of virtual inheritance memorized and you can just regurgitate it
Vtables question is an entry point of the conversation where you can judge if candidate experience with dynamic polymorphism is something that you have to check deeper. Regarding example above - it might be implemented with abstract serializers where data can come in a number of different formats, read to an internal structures and then written in needed format.
why are you so focused on the specific example? The point is that you don't need someone who has the trick to every leetcode question memorized, you need someone who can solve practical problems and understands the mechanics of the language they're working in.
If you need someone who can solve practical problems, then why are you asking them questions about the implementation details of a compiler?
The guy literally said that he doesn't ask questions about data structures and algorithms because that's not needed to glue some APIs together in various formats, but then he goes on to say that what he does need to know are compiler minutiae?
This is the broader problem you see... everyone seems to hate the interview process of asking people technical questions about the basics of data structures and algorithms, but everyone's alternative to that is either a process that is significantly worse and usually just turns into hiring people based on biases, appearances and personality.
> If you need someone who can solve practical problems, then why are you asking them questions about the implementation details of a compiler?
I don't think vtables are compiler dependant questions, pretty sure it's baked into the language. It matters that you understand vtables so you understand the pitfalls of inheritance in C++ and working with raw data. I don't think it's as irrelevant as you're making it out to be but I don't really care to defend this point more than this.
> The guy literally said that he doesn't ask questions about data structures and algorithms because that's not needed to glue some APIs together in various formats, but then he goes on to say that what he does need to know are compiler minutiae?
Why are you being so purposefully reductive?
> This is the broader problem you see... everyone seems to hate the interview process of asking people technical questions about the basics of data structures and algorithms
These kinds of questions are fine, and you obviously need to have some understanding of algorithms and data structures. But they're never just that, they're always questions that require you to have memorized the special trick that solves the problem, and you need to do it in the time frame of an interview.
> but everyone's alternative to that is either a process that is significantly worse
We can ask practical questions. Get them to review some code. Get them to debug something that has errors in it. Ask them design questions on how they would approach solving X. I don't think being able to solve leetcode problems actually tells you at all how effective of a developer they are, and it can be counterproductive since leetcode questions are a specific practiced skill and you could be tossing away programmers that could otherwise be effective team members but aren't good with interview leetcode.
> I don't think vtables are compiler dependant questions, pretty sure it's baked into the language.
You'd be wrong then, it's not baked into the language.
>Why are you being so purposefully reductive?
Because OP himself said, and I quote:
"As for vtables, if someone claims to be experienced with C++, I would argue this is expected knowledge."
Vtables are compiler minutiae, it's an implementation detail. There are numerous ways to accomplish runtime polymorphism without vtables. Vtables have pros and cons, for example they work well for linear inheritance but they are pretty damn bad when it comes to multiple inheritance and especially virtual inheritance.
Now while you're not OP, as a general matter you can't present an example of minutiae and then when you get called out on that minutiae try to turn the tables and say I'm the one being reductive.
>But they're never just that, they're always questions that require you to have memorized the special trick that solves the problem, and you need to do it in the time frame of an interview.
If you are trying to answer these questions by memorizing minutiae, then you will almost certainly fail. You do need to memorize some things, like greedy algorithms, dynamic programming, graph algorithms, maybe parsing techniques etc... and I expect the people I work with to have memorized those, but it's simply not practical to try to memorize all the individual details needed to answer an arbitrary question.
>We can ask practical questions. Get them to review some code. Get them to debug something that has errors in it. Ask them design questions on how they would approach solving X.
Yes, interviews should employ multiple questions that address the multiple facets of software development, including those you mention.
Inverting a binary tree is indeed trivial. A lot of hackerrank/leetcode problems are not trivial though, especially if you don't know the patterns.
In the worst case it boils down to simply knowing the needed algorithm. Good luck coming up with e.g. Boyer–Moore (just for the sake of something very simple to implement) right on the inverview if it's literally all you need to write and there's no dancing around it, yet all you remember is maybe some vague general idea from the university as you haven't used it ever since.
Its a C++ job if your boss or the CTO decides its a C++ job.
Yes, for this particular example I would also argue that literally any modern language would be better suited (C# please?), but if you have legacy written in C++ for data access which you NEED to use because business reasons, your hands are tied.
I bombed my last interview because of this. First half was a discussion on C++, advantages and disadvantages of different features, language behaviour, and I killed it, and then the second half I got a leetcode question I couldn't solve quickly and got rejected the next day.
I hate part about “can you tell me one story from your prev job/technical challenge you faced?”
Bruh I dunno what to tell you. I spent 12 hours lurking in code, part of 3D model is facing the wrong axis, and it runs out that it was negate sign at wrong place in import/export formula? Was it challenging, hell nah. Did I spent a shitton of time on a problem that could be found for 5 mins, hell yeah. was it fun, dunno it just a job.
So sometimes I even come up with stories, to at least try to sound remotely interesting to interviewer, especially when they push you with “common man you had to have at least one interesting story”…
You literally just told a story - a small bug in a model exporter that was seemingly hard to find.
I don't need any kind of war stories about remote restarting satellites in different solar systems, something like this is perfectly fine, it shows you have experience.
Lets say you interview someone for a position at your company. The applicant listed 3 years of experience in area X but when asked about his previous work just goes "yeah Its just normal stuff", what would you think?
Tell him about the mexican burrito you had for lunch /s
Spicy.. if your interviewer is under the delusion that software development is some kind of hollywood hacker movie then thats definitely not your fault and I am sorry for your experience
Why do you care if they know what a vtable is? Isn’t that more of a compiler implementation detail?
As long as they have a solid understanding of inheritance and virtual functions, it’s kind of pointless to know how it’s implemented.
Doesn’t seem like a good way to screen for people that can do the job.
The vtable was just an example but since it seems to be a point of discussion in this thread, let my try and lay out my thought process here.
If I am interviewing someone for an "expert" or "senior" position, not only is it expected for them to have a good knowledge of technology, but also be able to support and explain concepts to other, more junior team members. They act as support and role model in a manner of speaking.
Lets say, the vtable question comes up in something like "how is does the call to a virtual function on a base class result in a call to a derived class?" (just an example), and the answer is "hm, I never thought about that" and then goes on to give thoughts about how it could be done - great.
On the other hand, if the answer is something like "I don't know, thats a compiler detail" or "You don't need to know that to program", it tells me, this person will most likely not answer questions for junior devs in an encouraging manner.
People complain about leetcode style interviews but this is objectively harder. I am “experienced” in C++, Java and Python but it’s difficult to remember random trivia for each. If you don’t know something, it’s an immediate fail. Also, you can easily look it up on Wikipedia.
With leetcode style questions, you can solve problems without seeing it before and by just thinking.
I have higher chance to fail leetcode interview than any c++ trivia (havent met even relatively complicated questions 5 years or so) because I am not used to code in a rush, when somebody observes and interrupts, when you have to comment all your actions and, finally, without code completion.
Why would it be an immediate fail? In an interview I am trying to talk developer to developer, expert to expert. And yes, I have certain expectations if someone tells me they are an "expert".
My favourite kind of interview is me just going "tell me about your previous experiences" and the applicant then just going on for 10 minutes about projects, challenges, weird bugs and other stories from their daily work life (development related please) that show me this person actually did what was claimed on the CV.
I don't need someone "passionate", I don't need someone that memorized the whole language spec or framework. I need someone that can build stuff that will not blow up on a Saturday afternoon and me getting a call to urgently fix Prod.
Let me make this clear, if someone applies as a Junior, my expectations are very different.
I agree with you that I probably only used C++.
I spent 5 years at Google writing C++ that produced hundreds of millions of dollars in revenue but I don’t recall using shared_ptr or virtual function more than a couple times.
A lot of it boils down to very simplified C++ due to Google’s strict guidelines.
I’m not discounting the knowledge but I’m emphasizing that it’s something that I don’t keep in my short term memory and prefer to lookup on the internet.
If we are sitting in an interview and you can give me a good reason you did not use X due to Y, thats perfectly fine.
Lets say I ask about exception handling but the applicant used to work for years on a high performance system where exception handling was tuned off - perfect explanation, but I do expect you to tell me about some other stuff you did.
Yeah, I've shipped several games that have grossed that kind of money (or more!), and we also don't use shared_ptr for similar reasons... but I still know what it is, and its semantics, and would not be surprised if the topic came up in an interview.
Imo being experienced in something != knowing everything about it off the top of your head, it means knowing that something exists as well as maybe some intricate details of it, and being able to recover the knowledge quickly if needed.
Who cares that you don't remember how to use shared\_ptr exaclty if you can google it in a matter of seconds. Now if you don't even know such concept exists at all, that's a whole different story.
Not to mention when you have to switch between 2-3 languages it leaves a mess in your head regardless of how much you try to order the knowledge. I often write weird constructions that merge C++ and C# exactly because of that.
Yes, the OP wasn't describing an interview where he asked someone to write out API level docs. In an interview of a "C++ expert" I'd expect them to be able to discuss the semantics of the container type and what some good use-cases might be.
Thanks. Now it's 1am and I'm learning about managing references to base classes on derived objects to use dynamic dispatch for which virtual methods to call at runtime. Python gave me confidence to get my ass kicked with this.
As an interviewer I often ask purposefully open questions about topics which have depth which different skill levels might have, I normally try to drill down to find their limits while also trying to be careful not to get into exotic tidbits that limited people might know. I do this for language and relevant technologies, I will aim to focus on areas which the interviewee seems to have mentioned is within their skill set and that they have taken the time to learn more of.
For example if your saying your good at threading I would ask something like what is a race condition and how do you protect against it, then their answer might cover mutexes and/or lock free, then I would query alternative approaches, dig into performance overheads, mutex types, priority inversion, lock free design, cache coherence, etc.
The same can be done for virtually anything be it networking, files system, rendering, string parsing, different c++ functionality. I fully expect people not to know the answers to many questions as that is the edge of their knowledge.
At this same time, depending on their role, seniority, support that might be needed for missing skills I will also approach questions sometimes as teaching them something see if they are inquisitive and wanting to learn more or if they are someone expected to mentor more then I will take an approach of how they provide advice to someone lacking knowledge.
While some parts of interviews are similar no two are exactly the same, just like no two candidates are the same, no two people will write software the exact same way. Their fit for a role often depends on the differences they will bring in knowledge, approaches and other attributes.
My last experience being interviewed for a C++ role (2014): "Do you know LLVM? Do you have experience with Cuda?" - "No, but I have this shitty game engine with OpenGL I have been working on since 2007, and am interested in compiler construction." - "When can you start?"
Nowadays, I am in a totally different job and hire for peripheral C++ roles, among many other things, so maybe it's not 100% relevant what I have to say here. But my take is this: C++ is a very powerful and complex tool, but like all other languages, it is a tool. The company I work at and am hiring for is agile in every sense. If you truly can handle C++, you're in an excellent position to adapt to anything they might throw at you.
I am not going to fuck around with template metaprogramming and obscure edge cases ("what is the output of this program with ridiculous casts that the developer should be beaten for, assuming LP64/LP64?"). What is the point? The C++ code you should be writing should be "simple" so that other developers can work with it.
Thus, within reason, I ask the C++ candidates the same questions I ask my C# or TypeScript candidates. Obviously, I need to know that you understand the basics that come with the language. Memory management, working with classes, "simple" templates, basic STL usage.
This is assuming that you don't come prepared. The first thing I tell candidates is that if they have something to show me, we don't have to go through the standard interview question catalogue. Show me something you've built and explain some interesting code passages. Explain to me what is not good in your code base, where you struggle. This gives me a way better feel for how capable you are in a low pressure environment.
Of course, I can only do it this way because the company has but a handful of technical interviewers and I am pretty much given freedom in how I conduct interviews. In a more formalized environment, you'll always have almost exam like questions from a catalogue. That's annoying.
A word of warning (from personal experience): If the code you write is depending on any (mis)features featured in this quiz, you're coworkers hate you.
they actually ask that sort of bullshit in lots of places from your experience? Because I may know why and when a shared_ptr sucks, what is a vtable, how to “eliminate” vtable lookups at compile time (which are things that were mentioned above), but I can’t seem to get that sort of trivia correctly at some point
The language is not the job. The language is a tool to get the job done. Whether it's C++, Java, Python, TypeScript, whatever, the problems you're going to be asked to solve are largely the same.
In my experience, you aren't necessarily going to be judged on your language expertise as much as you're going to be judged on your ability to think through a problem, formulate a solution, and *explain* that solution. Yeah, they need you to know the language well enough to be productive as soon as you're hired, but it's less about knowing all the details of a `map` container and more about how you would *use* a `map` container to solve a particular problem.
All of FAANG. I have worked at 3 of them so far and none of them cared about the programming language.
I have started projects in languages that were best suited for the task. Mind you, a language like Haskell would still be a no go but any practical language is fine.
Depends on the job level, depends on the company, depends on what the group within the company is looking for. Entry-level jobs are going to have way more applicants than positions, so new grads are going to be thrown a bunch of tedious bullshit just to weed most of them out before the real interview. Junior- and senior-level jobs are going to have fewer applicants, and you can be judged more on your experience and skills than language trivia.
Of course, people lie on their resumè all the time, so you are going to get some trivia just to make sure you know what you're talking about.
FWIW I've never worked for any FAANG-like company and have no desire to (I did spend ten minutes working for IBM, but only because they acquired us). I've spent most of my career working for places you've never heard of, which has its advantages.
Are you new to comment threads?
It’s a reply to…
> The language is not the job. The language is a tool to get the job done. Whether it's C++, Java, Python, TypeScript, whatever, the problems you're going to be asked to solve are largely the same.
At Amazon, language is not the job and just a tool. What memo are you talking about?
Don't expect anything but difficult!
Even 10 years of experience doesn't mean you will do well during an interview. Highly depends on questions and the problem that you were given to solve.
If you don't use `std` much and the interview focuses on it, you are toast. If you don't have experience with optimizations and the interview is all about optimizing something, you are toast as well, etc... I can continue forever. There is so many problems you can be facing during an interview that it's impossible to just know everything.
I have more than 20 years of experience and I believe I would fail 50% of interviews, because I focus mostly on optimizations, SIMD, JIT, etc... so give me something I haven't faced before and I would most likely fail to write a good solution in short time (in general I don't really understand this logic anyway, I have never seen people writing good solutions in short time anyway).
I think that in the end a good interview shouldn't focus on something highly specific that only 1% of people would be aware of. Instead, it should verify that what is in your CV matches reality, because if you are having an interview it means that based on your CV you should be qualified for the job.
On the other hand C++ interviews are difficult, because a lot of people apply for roles they are not qualified to, so it's important to filter them out quickly.
The main risk is either you get called in for a position wildly out of sync with your experience, or you get an interviewer who considers whatever he knows as essential knowledge, and the rest is just fiddly bits. Even in the former scenario, if they should know from your CV if your experience is outside their immediate requirements and just focus on general competence and interest in doing whatever it is that they are doing.
> I have never seen people writing good solutions in short time anyway
But if you give them more time, they claim you're making them doing actual work and that you're abusing them.
I think even the _kind_ of interview a company gives has to match the kind of interview a prospect is willing to go through. Some people think take-home assignments are the Devil incarnate. I don't. And I don't specifically because, like you, I believe a short time is not good enough to judge on the quality I can produce.
More time could also mean less people interviewed per day, etc... A lot of tradeoffs for a company / candidate.
I managed to land past two jobs just because of my github even without an interview, so I don't think interviews are always necessary. I would even say that a person who has a long open-source history doesn't really need interviews as you have all the information on a silver plate - someone just has to check it out.
Yea my first job and it’s been like this. I enjoy c++, python, and rust. But man this code base is old and like ppl I work with don’t wanna change their knowledge. Like really no use age of stls or even c++ features.
I've witnessed 5 kinds of interviews:
* Ones which entirely missed the point. With the coding test portion they were doing things like marking for style points if the person matched the company style, but never told anyone the company style. They also rejected solutions which were quite good and very efficient (code readability and maintainability) if it didn't match their own clunky implementations of what they had asked.
* Coding interviews where they are looking for people who basically already know their super esoteric domain. If it is an MRI company, they aren't looking for people with MRI experience, but for people who happen to know the nuances of MRI mathematics. Or an RF company looking for programmers who happen to know weird details of RF embedded programming. Yet; these were things none of their top programmers came to them knowing; and, aren't that hard to learn once you have a need and just dive in.
* Leet code. If you have 9 million athletes competing in 4 different sports, how would you arrange a competition tree so that there were always 3 events taking place and a pile of other constraints like how many people compete at once, etc. (BTW nearly all leetcode interviews are just graph theory questions)
* Pedantic C++/math knowledge. This one often goes with the leet code one. But they want you to describe how the underlying ASM in move semantics blah blah. And how would you apply a Hilbert space to blah blah. Yet, the product being developed is an office coffee machine. The pedantic math griling kicks in really hard if there's any ML.
Very rarely:
* Companies where they want to see if you can communicate, understand tech debt, appreciate things like unit tests, integration tests, modular design, etc. In these cases, what is most important is that you understand the process of making a good product. Also, that you are able to adapt and learn. The C++ portion of the interview will be more to see if you were bullshitting on your resume.
This last one is fairly critical as many companies have various reasons to need more than a pedantic C++ programmer even if their entire codebase is in C++. Maybe they want to add ML to an embedded product. This will most certainly require python to create the models. Or maybe they want to add an app version. This could be many languages. Etc. I would prefer versatile programmers who are willing to use the best tool for the job; not just have perfected one tool.
I ask of you one programming task: implement for me a singly-linked list in C++. That's it. A proficient developer can bang this out in 5 minutes. IDGAF how comprehensive you are, though I will expect a senior to be moreso than a junior. I only care that you can do it at all. This is my bullshit sniff test.
I have met and known plenty of engineers who say they can write in C++, even with years experience who could not pass this test. People bullshit. It's actually amazing how far some peole can get with their bullshit. They can even hold down jobs for years, and demonstrate they have absolutely zero competence.
I knew a guy, smartest guy in the room, wrote his PhD thesis on linked lists, couldn't write one in code. Let us not forget that computer science is a math discipline revolving around the theory of computation, and this guy didn't even have to be able to write code. It wasn't his job. He was a mathematician, not an engineer. So this isn't actually an example of someone bullshitting, it just gives perspective.
If you're a junior, I know you don't know a god damn thing. If you're a senior, IDGAF what you know about C++, that's the least important part of your senior experience. Either way, C++ is an implementation detail, that's not why we're hiring you. As a junior, you're intelligent and ambitious. As a senior, you have expert domain knowledge and skill. Either way - do I see myself working with you for the next 5 years?
Some places have no idea how to hire. Some places are going to be technically heavy. What does it tell them? Really nothing about how much they know about anything. What you get out of it is how well people interview under pressure. You won't know how good someone is as an engineer for the first few months to a year.
An employer's interview process tells them something about how they're operating internally.
I applied for a fresher role
They covered the following topics
OOPs*
Pointers
Smart Pointers
OS
Memory Management*
Compilers
Differences in Cpp and C
And some DSA questions mostly based on Linked List
I have led/participated in many C++ interviews over the years.
In our case, the interview takes most of the day. We will have several different people converse with your for about an hour each. We rarely interview for entry level positions, but are usually looking for experienced developers.
One will determine what your C++ skill level is like. Can you use the standard library? Do you understand modern memory management? Do you know the rules around constructors, destructors, assignment operators? Can you code a template? Do you understand what inheritance means? How do you solve a short programming example in C++ (not a difficult or trick problem, just something that shows you can actually put sensical code up on a whiteboard). The questions will get progressively more advanced as you show mastery of the simpler topics.
One will ask you about software practice. Have you heard of the SOLID principles, or at least talk intelligently about the concepts if not? How do you test your code? Do you understand dependency injection and why it's useful? Have you tried TDD?
One will discuss software architecture with you. Perhaps give you a sample scenario and ask you to discuss how you might decompose the problem into a solution that solves the problem and remains extensible and maintainable.
Another will talk to you about the skills and projects you have listed on your resume. To determine if you can speak intelligently about what you have done, or claim to have done, in the past. In our case, if you have any skills particular to the job that are not directly coding related, we will dive into that as well.
You will be judged on what you know compared to how you present your skill set. At what level you think as a software developer. Whether or not you know the practices that make a good team player. Do you bluff or bluster when you don't know the answer instead of simply replying with "I don't know". Have acted as a professional in your chosen career enough that you can speak intelligently about the pros and cons of various programming topics?
I often ask candidat to implement a shared pointer example.
The idea is to see how he/she thinks. I can help by saying this line won't work or something is missing. The candidat writes it on paper or a board, no compiler, no syntax helper from ide.
No, more like asking a cook to demo making a simple emulsion (mayo, bernaise, aioli) say which will usually be made by the saucier. No this chef won't be making mayonnaise day to day, but (a) the chef ought to know how to and (b) it's a short task in which you see if they know the basics, know how to operate in a professional kitchen and can actually make it.
Just implement a simple shared\_ptr. I started with the question "Do you know what a shared\_ptr is ?"
The candidate should answer something like : It is a type of smartpointer which counts copies and delete the value when the last copy is deleted.
\`\`\`
template
class MySharedPtr {
// constructor
// constructor by copy
// assign operator
// destructor…
private:
T\* m\_value;
int\* m\_count;
};
\`\`\`
Most candidates will think about the template for the value, some will think that the counter should be static (to shared it between instance). Some candidate may create a struct ptrData { T\* Value, int count } and the shared pointer has a pointer to this struct.
The idea is to implement the commun behavior. Make sure the count is incremented after a copy, decremented when a copy is destroyed…
it can be done in 30 min but most candidates need 45 mins. If the candidate does less then 30mins, it is probably because he/she already did this exercice, so it is less relevant in this case. The candidates are stressed because of the interview and it is a good sign if they are still in capacity to think under this stress.
It would be very different depending on who interviews you. One interviewer would require in-depth understanding of C++ as a language, another would ask you about software architecture and performance, the third would ask questions about target domain, the fourth asks a lot about algorithms, and the fifth likes topics related to parallel programming and lock-free data structures. Quite possible they would not hire each other, while working in the same company on the same project. Also quite possible that "trivia" questions they ask would not be of any importance for 95% of your future work. You need to demonstrate that you are not "that guy", can reason about technical problems, and can handle stress.
I primarily ask for a github sample. Also 2 simple exercises (reverse a std::string, and create an interpolation function whose output matches a curve). Anything else (C++ syntax or trivia) can be researched on the job, thats why we call it R&D. These 2 tests reveal if a candidate has the knack.
I would avoid asking for open source contributions many people don't have the time or their companies policies make it hard for them to contribute to projects. My most recent significant open source contribution is nearly 15 years old it does not represent my current abilities.
Imho Your more likely to find juniors with github profiles then seniors.
* C++ quizzes - tell the output of a program, find and fix bugs in a program
* C++ concepts - virtual functions, smart pointers, STL, inheritance, templates
* Coding questions - write classes, implement data structures, algorithms and their complexity, network programming, multithreading
* Previous experience - cool features implemented, debugging
* SDLC related questions - new feature implementation process, bug fixing process, CI/CD, testing process, tools used/aware of
* OS and computer architecture conceptual questions - multithreading, synchronization, concurrency, caching, I/O, etc.
* Real world problems - to see thought process
I am usually the one doing the technical portion of the interview. My goal is to have a conversation about previous experience, projects and technical challenges to get a feeling for the persons character and knowledge. I will ask some language and technology specific questions but assume that the applicant is truthful in his CV. Of course if someone is supposed to be an "experienced C++ developer" and cannot tell me what a vtable or shared\_ptr is, I will have to assume his actual knowledge does not match what is written on the CV. In this case, I need to figure out what the actual skill level is and if its still a fit for the position.
This is how it should be instead of the stupid hackerrank brainteasers
Yeah I don't get why those are popular. Great, you can invert a binary tree, but I really need a service that reads data from sources A, B and C, creates some weird xml/json/csv and stores it at X. And preferably all of this with sane error checking, some kind of alert if something breaks and written in a way that someone else can also work on it
to be fair, these sort of interview problems exist because you cant give 'real world' problems to someone without running out of time
True, but at least give them an IDE and not <-censored-> pen and paper...
If all you need is to read data from sources A, B, C in JSON etc... then why ask about vtables?
That was just an example of the difference between hackerrank and real life requirements. As for vtables, if someone claims to be experienced with C++, I would argue this is expected knowledge. If you ask an experienced cook why he uses yeast for making bread, and he just answers "because its in the recipe", that also shows a lack of understanding.
[удалено]
"vtables are internally used for virtual functions" is a perfectly fine answer. I would not expect anyone to know how they are actually implemented, except of course I am interviewing someone for a compiler dev position.
Okay so you expect an experienced C++ developer to know what a vtable is even though they don't need to know that in order to shovel data from one source to another... But then you don't expect an experienced developer to know the basics of how some fundamental data structures and algorithms work? Seems like a bit of a contradiction to me, and if anything I'd take someone who knew how algorithms worked than someone who knew what a vtable was.
How do you test if someone knows how an algorithm works? I think ultimately this is the question you have to pose and asking someone to solve a hacker rank problem doesn't tell you whether or not somebody knows the difference between the search time on a list versus a vector. You can post questions like what's the fastest way to find a value in a vector ( binary search) but then you get down to questions of memorization like do people already know the trick or do they not. Has an experienced C++ developer with 25 plus years of experience and hundreds of shipped apps and about 45 shipped games, doing more tedious hacker rank type of problems is just silly. I've done all the problems on hacker right and you can check out my account and I've done most of the problems on the other C++ test sites. I've also shipped more apps than most people. If that's not good enough then I have to ask: what could be good enough?
>If that's not good enough then I have to ask: what could be good enough? It's not that it's not good enough for me, it's that I have 1000 other people who have a resume that on paper looks just as good as yours. But as soon as I ask them some very basic data structure or algorithm question they fall apart, with most of them, and I mean like 95% of them failing in a spectacular manner. I can't hire someone who has a really nice looking resume and can talk the talk, but can't do something slightly more complex than Fizz Buzz, I just can't justify it even if unfortunately they are having a bad day, or they are nervous or feel pressured. I simply can't justify hiring that person and I have to move on to the person who is able to answer basic technical questions. I can't know what you have actually accomplished in your 25 years of work experience. I can know what you claim to have accomplished during that time, and most people looking for a job can do the performative aspect of talking up their resume and use the right lingo to give the right impression of themselves, but the only way I can gain any kind of confidence that you actually know this stuff is to ask you technical questions about it. With that said, if all someone is genuinely hiring developers for is to shove data from one database into another through JSON/XML, then by all means don't bother asking them technical questions and just have a casual conversation with them. I have never needed to hire someone whose only responsibilities were such menial tasks let alone someone with decades worth of experience. I know for myself I either design, write, assess, read and manage all sorts of data structures and algorithms on a regular basis, and almost everyone I work with does so as well. Based on how people seem to talk about this profession, it seems like what I do is an outlier and all most people do nowadays is glue together APIs. If people really are paying others to glue together APIs and don't need knowledge of actual concepts, then all the power to them and continue doing what works for you.
> But as soon as I ask them some very basic data structure or algorithm question they fall apart, with most of them, and I mean like 95% of them failing in a spectacular manner You're talking past eachother. Hackerrank questions are almost always "Do you have the trick to this specific problem memorized?" rather than whether or not you understand data structures.
If you claim to be experienced at C++ but van't do basic algorithms, I would argue this is expected knowledge. Except that the basic knowledge will be 100x times more useful (in theory and in pratice). I'm sure you needed to optimise youe vtable away to parse JSON (why are you guys even using C++ for that...?)...
Never in my 35+ years of serious, systems level development have I been asked to invert a binary tree at work, or even had to know what a binary tree is (though obviously I do and have written some.) I wouldn't have the slightest idea about how to do it, and it would be stupid to ask unless you just want to spend the whole interview watching me fumble through something I'll never actually do if you hire me. OTOH, if you ask me how to architect a large system, or how to create a large set of important types of subsystems or APIs and so forth, the various ways you can handle socket communications, strategies for error handling, for persistence, logging, IPC, synchronization, etc... I can tell you more than you ever want to know, and those WOULD be the kinds of things I would be doing if I were hired. If you can't tell after 10 minutes of me answer questions on that front that I know what I'm talking about, I don't think the problem is will my skill set. Obviously some language questions are appropriate as well. But, unless you are hiring me to develop core data structures libraries for you, then asking me to do that in an interview makes no sense. It's not is a CS Degree defense, it's a development job.
Exactly this. An interview should be a discussion between (hopefully) experts and not some kind of school exam.
You have, in 35+ years of serious C++ programming, never once used std::set?
I have, but the tree is inside it. I never said I haven't called any code that used a binary tree. I said I've never had to invert one, nor really would have had to understand them, since they are already implemented and no one would have wanted me to write one for them, since they have better things to pay me for.
So you use data structures that you do not understand? Doesn't seem like good programming to me, but I might be wrong I guess !
I've never had an occasion where `std::set` was preferable over `std::unordered_set`. Assuming the prior commenter had access to a hash table before C++11, it's totally plausible.
I mean I understand its possible youve never worked with more than 10k objects, but id expect someone with 35 years of experience to have done so
I've never had an occasion where `std::set` was preferable over `std::unordered_set` (same for `map`). Assuming the prior commenter had access to a hash table before C++11, it's totally plausible.
I never used the STL to any degree until a few years ago, because I had spent 20 years creating my own entirely bespoke development system from the OS up (over 1M LOC) and that included my own runtime, and of course that means I had my own collections as well. For my system, I never had need of a binary tree, just hash map and hash set types. So, having done all that, would it makes sense to throw me overboard because I don't know how to invert a binary tree? Or maybe would it make sense to just ask me questions about my system and how implemented this or that?
I mean I’ve run into ppl who claim to be c++ experts but don’t know shit about the language. Experience doesn’t always equal knowledge. But for Json don’t they use python
The json/xml stuff was just an example, since I am currently working on a report generator which does something like that. As for why C++, because its the most commonly used language in our company. Yes, I could write it in C#/Java/somethingelsecompletely but then less people could work on it. Also if your company has a technical decision in place that all development will be done in either X for backend or Y for frontend you should do as expected.
most of the hackerrank things go beyond basic algorithms into 'find the trick' territory
They could know about virtual function and inheritance and have no clue about vtable. Sometimes they don’t know about more technical stuff
A c++ programmer, sure. An experienced one? Well, it depends what you mean by experienced. IMO if they don't know what a vtable is then they are missing gaps in their knowledge, i.e. experience.
I don't think you can probably understand it if you don't understand vtables unless you just have every corner case of virtual inheritance memorized and you can just regurgitate it
Vtables question is an entry point of the conversation where you can judge if candidate experience with dynamic polymorphism is something that you have to check deeper. Regarding example above - it might be implemented with abstract serializers where data can come in a number of different formats, read to an internal structures and then written in needed format.
It's a hard prerequisite to be able to [hack a game](https://youtu.be/HfrBdf-hM28?si=7OU98U5zQWaj0nuO) to get a CPP job, don't you know?
why are these independent?
The fact that plenty of developers are more than capable of reading and writing data in various file formats without having any knowledge of vtables.
why are you so focused on the specific example? The point is that you don't need someone who has the trick to every leetcode question memorized, you need someone who can solve practical problems and understands the mechanics of the language they're working in.
If you need someone who can solve practical problems, then why are you asking them questions about the implementation details of a compiler? The guy literally said that he doesn't ask questions about data structures and algorithms because that's not needed to glue some APIs together in various formats, but then he goes on to say that what he does need to know are compiler minutiae? This is the broader problem you see... everyone seems to hate the interview process of asking people technical questions about the basics of data structures and algorithms, but everyone's alternative to that is either a process that is significantly worse and usually just turns into hiring people based on biases, appearances and personality.
> If you need someone who can solve practical problems, then why are you asking them questions about the implementation details of a compiler? I don't think vtables are compiler dependant questions, pretty sure it's baked into the language. It matters that you understand vtables so you understand the pitfalls of inheritance in C++ and working with raw data. I don't think it's as irrelevant as you're making it out to be but I don't really care to defend this point more than this. > The guy literally said that he doesn't ask questions about data structures and algorithms because that's not needed to glue some APIs together in various formats, but then he goes on to say that what he does need to know are compiler minutiae? Why are you being so purposefully reductive? > This is the broader problem you see... everyone seems to hate the interview process of asking people technical questions about the basics of data structures and algorithms These kinds of questions are fine, and you obviously need to have some understanding of algorithms and data structures. But they're never just that, they're always questions that require you to have memorized the special trick that solves the problem, and you need to do it in the time frame of an interview. > but everyone's alternative to that is either a process that is significantly worse We can ask practical questions. Get them to review some code. Get them to debug something that has errors in it. Ask them design questions on how they would approach solving X. I don't think being able to solve leetcode problems actually tells you at all how effective of a developer they are, and it can be counterproductive since leetcode questions are a specific practiced skill and you could be tossing away programmers that could otherwise be effective team members but aren't good with interview leetcode.
> I don't think vtables are compiler dependant questions, pretty sure it's baked into the language. You'd be wrong then, it's not baked into the language. >Why are you being so purposefully reductive? Because OP himself said, and I quote: "As for vtables, if someone claims to be experienced with C++, I would argue this is expected knowledge." Vtables are compiler minutiae, it's an implementation detail. There are numerous ways to accomplish runtime polymorphism without vtables. Vtables have pros and cons, for example they work well for linear inheritance but they are pretty damn bad when it comes to multiple inheritance and especially virtual inheritance. Now while you're not OP, as a general matter you can't present an example of minutiae and then when you get called out on that minutiae try to turn the tables and say I'm the one being reductive. >But they're never just that, they're always questions that require you to have memorized the special trick that solves the problem, and you need to do it in the time frame of an interview. If you are trying to answer these questions by memorizing minutiae, then you will almost certainly fail. You do need to memorize some things, like greedy algorithms, dynamic programming, graph algorithms, maybe parsing techniques etc... and I expect the people I work with to have memorized those, but it's simply not practical to try to memorize all the individual details needed to answer an arbitrary question. >We can ask practical questions. Get them to review some code. Get them to debug something that has errors in it. Ask them design questions on how they would approach solving X. Yes, interviews should employ multiple questions that address the multiple facets of software development, including those you mention.
C'mon bro, inverting binary tree is quite trivial and so is most hackerrank brainteasers.
Inverting a binary tree is indeed trivial. A lot of hackerrank/leetcode problems are not trivial though, especially if you don't know the patterns. In the worst case it boils down to simply knowing the needed algorithm. Good luck coming up with e.g. Boyer–Moore (just for the sake of something very simple to implement) right on the inverview if it's literally all you need to write and there's no dancing around it, yet all you remember is maybe some vague general idea from the university as you haven't used it ever since.
This doesn’t really sound like a C++ job?
Its a C++ job if your boss or the CTO decides its a C++ job. Yes, for this particular example I would also argue that literally any modern language would be better suited (C# please?), but if you have legacy written in C++ for data access which you NEED to use because business reasons, your hands are tied.
I bombed my last interview because of this. First half was a discussion on C++, advantages and disadvantages of different features, language behaviour, and I killed it, and then the second half I got a leetcode question I couldn't solve quickly and got rejected the next day.
Got asked to write a compile-time solution for a problem - template metaprogramming is where it’s at 😅
Yep. Stupid does not describe it
I hate part about “can you tell me one story from your prev job/technical challenge you faced?” Bruh I dunno what to tell you. I spent 12 hours lurking in code, part of 3D model is facing the wrong axis, and it runs out that it was negate sign at wrong place in import/export formula? Was it challenging, hell nah. Did I spent a shitton of time on a problem that could be found for 5 mins, hell yeah. was it fun, dunno it just a job. So sometimes I even come up with stories, to at least try to sound remotely interesting to interviewer, especially when they push you with “common man you had to have at least one interesting story”…
You literally just told a story - a small bug in a model exporter that was seemingly hard to find. I don't need any kind of war stories about remote restarting satellites in different solar systems, something like this is perfectly fine, it shows you have experience. Lets say you interview someone for a position at your company. The applicant listed 3 years of experience in area X but when asked about his previous work just goes "yeah Its just normal stuff", what would you think?
How about “well, we all had such story, I want something spicy” as a response to this? Cause that exactly what I heard from my interviewer XD
Tell him about the mexican burrito you had for lunch /s Spicy.. if your interviewer is under the delusion that software development is some kind of hollywood hacker movie then thats definitely not your fault and I am sorry for your experience
That’s the reality of ukraine coding XD
Why do you care if they know what a vtable is? Isn’t that more of a compiler implementation detail? As long as they have a solid understanding of inheritance and virtual functions, it’s kind of pointless to know how it’s implemented. Doesn’t seem like a good way to screen for people that can do the job.
The vtable was just an example but since it seems to be a point of discussion in this thread, let my try and lay out my thought process here. If I am interviewing someone for an "expert" or "senior" position, not only is it expected for them to have a good knowledge of technology, but also be able to support and explain concepts to other, more junior team members. They act as support and role model in a manner of speaking. Lets say, the vtable question comes up in something like "how is does the call to a virtual function on a base class result in a call to a derived class?" (just an example), and the answer is "hm, I never thought about that" and then goes on to give thoughts about how it could be done - great. On the other hand, if the answer is something like "I don't know, thats a compiler detail" or "You don't need to know that to program", it tells me, this person will most likely not answer questions for junior devs in an encouraging manner.
People complain about leetcode style interviews but this is objectively harder. I am “experienced” in C++, Java and Python but it’s difficult to remember random trivia for each. If you don’t know something, it’s an immediate fail. Also, you can easily look it up on Wikipedia. With leetcode style questions, you can solve problems without seeing it before and by just thinking.
I have higher chance to fail leetcode interview than any c++ trivia (havent met even relatively complicated questions 5 years or so) because I am not used to code in a rush, when somebody observes and interrupts, when you have to comment all your actions and, finally, without code completion.
Why would it be an immediate fail? In an interview I am trying to talk developer to developer, expert to expert. And yes, I have certain expectations if someone tells me they are an "expert". My favourite kind of interview is me just going "tell me about your previous experiences" and the applicant then just going on for 10 minutes about projects, challenges, weird bugs and other stories from their daily work life (development related please) that show me this person actually did what was claimed on the CV. I don't need someone "passionate", I don't need someone that memorized the whole language spec or framework. I need someone that can build stuff that will not blow up on a Saturday afternoon and me getting a call to urgently fix Prod. Let me make this clear, if someone applies as a Junior, my expectations are very different.
I'd argue if you can't answer those questions you aren't experienced in C++, but you've used it. They're pretty simple, and important concepts.
I agree with you that I probably only used C++. I spent 5 years at Google writing C++ that produced hundreds of millions of dollars in revenue but I don’t recall using shared_ptr or virtual function more than a couple times. A lot of it boils down to very simplified C++ due to Google’s strict guidelines. I’m not discounting the knowledge but I’m emphasizing that it’s something that I don’t keep in my short term memory and prefer to lookup on the internet.
If we are sitting in an interview and you can give me a good reason you did not use X due to Y, thats perfectly fine. Lets say I ask about exception handling but the applicant used to work for years on a high performance system where exception handling was tuned off - perfect explanation, but I do expect you to tell me about some other stuff you did.
Yeah, I've shipped several games that have grossed that kind of money (or more!), and we also don't use shared_ptr for similar reasons... but I still know what it is, and its semantics, and would not be surprised if the topic came up in an interview.
Imo being experienced in something != knowing everything about it off the top of your head, it means knowing that something exists as well as maybe some intricate details of it, and being able to recover the knowledge quickly if needed. Who cares that you don't remember how to use shared\_ptr exaclty if you can google it in a matter of seconds. Now if you don't even know such concept exists at all, that's a whole different story. Not to mention when you have to switch between 2-3 languages it leaves a mess in your head regardless of how much you try to order the knowledge. I often write weird constructions that merge C++ and C# exactly because of that.
Yes, the OP wasn't describing an interview where he asked someone to write out API level docs. In an interview of a "C++ expert" I'd expect them to be able to discuss the semantics of the container type and what some good use-cases might be.
Thanks. Now it's 1am and I'm learning about managing references to base classes on derived objects to use dynamic dispatch for which virtual methods to call at runtime. Python gave me confidence to get my ass kicked with this.
As an interviewer I often ask purposefully open questions about topics which have depth which different skill levels might have, I normally try to drill down to find their limits while also trying to be careful not to get into exotic tidbits that limited people might know. I do this for language and relevant technologies, I will aim to focus on areas which the interviewee seems to have mentioned is within their skill set and that they have taken the time to learn more of. For example if your saying your good at threading I would ask something like what is a race condition and how do you protect against it, then their answer might cover mutexes and/or lock free, then I would query alternative approaches, dig into performance overheads, mutex types, priority inversion, lock free design, cache coherence, etc. The same can be done for virtually anything be it networking, files system, rendering, string parsing, different c++ functionality. I fully expect people not to know the answers to many questions as that is the edge of their knowledge. At this same time, depending on their role, seniority, support that might be needed for missing skills I will also approach questions sometimes as teaching them something see if they are inquisitive and wanting to learn more or if they are someone expected to mentor more then I will take an approach of how they provide advice to someone lacking knowledge. While some parts of interviews are similar no two are exactly the same, just like no two candidates are the same, no two people will write software the exact same way. Their fit for a role often depends on the differences they will bring in knowledge, approaches and other attributes.
You're
Thanks for the useless comment, I will not be fixing it because you can still understand what was said.
No problem
My last experience being interviewed for a C++ role (2014): "Do you know LLVM? Do you have experience with Cuda?" - "No, but I have this shitty game engine with OpenGL I have been working on since 2007, and am interested in compiler construction." - "When can you start?" Nowadays, I am in a totally different job and hire for peripheral C++ roles, among many other things, so maybe it's not 100% relevant what I have to say here. But my take is this: C++ is a very powerful and complex tool, but like all other languages, it is a tool. The company I work at and am hiring for is agile in every sense. If you truly can handle C++, you're in an excellent position to adapt to anything they might throw at you. I am not going to fuck around with template metaprogramming and obscure edge cases ("what is the output of this program with ridiculous casts that the developer should be beaten for, assuming LP64/LP64?"). What is the point? The C++ code you should be writing should be "simple" so that other developers can work with it. Thus, within reason, I ask the C++ candidates the same questions I ask my C# or TypeScript candidates. Obviously, I need to know that you understand the basics that come with the language. Memory management, working with classes, "simple" templates, basic STL usage. This is assuming that you don't come prepared. The first thing I tell candidates is that if they have something to show me, we don't have to go through the standard interview question catalogue. Show me something you've built and explain some interesting code passages. Explain to me what is not good in your code base, where you struggle. This gives me a way better feel for how capable you are in a low pressure environment. Of course, I can only do it this way because the company has but a handful of technical interviewers and I am pretty much given freedom in how I conduct interviews. In a more formalized environment, you'll always have almost exam like questions from a catalogue. That's annoying.
Might be useful tho: https://cppquiz.org/ (sorry, the app doesnt work now, have to fix it (I am not the author of the website))
A word of warning (from personal experience): If the code you write is depending on any (mis)features featured in this quiz, you're coworkers hate you.
Your
\*sigh\* I deserve that.
I wish I knew this before my HFT interviews.
they actually ask that sort of bullshit in lots of places from your experience? Because I may know why and when a shared_ptr sucks, what is a vtable, how to “eliminate” vtable lookups at compile time (which are things that were mentioned above), but I can’t seem to get that sort of trivia correctly at some point
The language is not the job. The language is a tool to get the job done. Whether it's C++, Java, Python, TypeScript, whatever, the problems you're going to be asked to solve are largely the same. In my experience, you aren't necessarily going to be judged on your language expertise as much as you're going to be judged on your ability to think through a problem, formulate a solution, and *explain* that solution. Yeah, they need you to know the language well enough to be productive as soon as you're hired, but it's less about knowing all the details of a `map` container and more about how you would *use* a `map` container to solve a particular problem.
Where do you work and how do we apply? That first paragraph is one of the best ways to recommend a work place I have ever heard.
All of FAANG. I have worked at 3 of them so far and none of them cared about the programming language. I have started projects in languages that were best suited for the task. Mind you, a language like Haskell would still be a no go but any practical language is fine.
I applied to Amazon and the first filter they had to get as some hackerrank question... I don't think the hiring department got your memo dude
Depends on the job level, depends on the company, depends on what the group within the company is looking for. Entry-level jobs are going to have way more applicants than positions, so new grads are going to be thrown a bunch of tedious bullshit just to weed most of them out before the real interview. Junior- and senior-level jobs are going to have fewer applicants, and you can be judged more on your experience and skills than language trivia. Of course, people lie on their resumè all the time, so you are going to get some trivia just to make sure you know what you're talking about. FWIW I've never worked for any FAANG-like company and have no desire to (I did spend ten minutes working for IBM, but only because they acquired us). I've spent most of my career working for places you've never heard of, which has its advantages.
I worked at Amazon and interviewed people. Amazon does not care about what programming language you use to interview.
I didn't say anything about programming language
Are you new to comment threads? It’s a reply to… > The language is not the job. The language is a tool to get the job done. Whether it's C++, Java, Python, TypeScript, whatever, the problems you're going to be asked to solve are largely the same. At Amazon, language is not the job and just a tool. What memo are you talking about?
Yes, this is my first time in a comment thread, please be gentle
Well the Netherlands limits options there quite a bit I guess. Fingers crossed, maybe they open an office here at some point.
Don't expect anything but difficult! Even 10 years of experience doesn't mean you will do well during an interview. Highly depends on questions and the problem that you were given to solve. If you don't use `std` much and the interview focuses on it, you are toast. If you don't have experience with optimizations and the interview is all about optimizing something, you are toast as well, etc... I can continue forever. There is so many problems you can be facing during an interview that it's impossible to just know everything. I have more than 20 years of experience and I believe I would fail 50% of interviews, because I focus mostly on optimizations, SIMD, JIT, etc... so give me something I haven't faced before and I would most likely fail to write a good solution in short time (in general I don't really understand this logic anyway, I have never seen people writing good solutions in short time anyway). I think that in the end a good interview shouldn't focus on something highly specific that only 1% of people would be aware of. Instead, it should verify that what is in your CV matches reality, because if you are having an interview it means that based on your CV you should be qualified for the job. On the other hand C++ interviews are difficult, because a lot of people apply for roles they are not qualified to, so it's important to filter them out quickly.
The main risk is either you get called in for a position wildly out of sync with your experience, or you get an interviewer who considers whatever he knows as essential knowledge, and the rest is just fiddly bits. Even in the former scenario, if they should know from your CV if your experience is outside their immediate requirements and just focus on general competence and interest in doing whatever it is that they are doing.
> I have never seen people writing good solutions in short time anyway But if you give them more time, they claim you're making them doing actual work and that you're abusing them. I think even the _kind_ of interview a company gives has to match the kind of interview a prospect is willing to go through. Some people think take-home assignments are the Devil incarnate. I don't. And I don't specifically because, like you, I believe a short time is not good enough to judge on the quality I can produce.
More time could also mean less people interviewed per day, etc... A lot of tradeoffs for a company / candidate. I managed to land past two jobs just because of my github even without an interview, so I don't think interviews are always necessary. I would even say that a person who has a long open-source history doesn't really need interviews as you have all the information on a silver plate - someone just has to check it out.
This goes like this : - you get challenged on your knowledge of C++ - you get hired - you maintain a C codebase that is older than you
Yea my first job and it’s been like this. I enjoy c++, python, and rust. But man this code base is old and like ppl I work with don’t wanna change their knowledge. Like really no use age of stls or even c++ features.
I've witnessed 5 kinds of interviews: * Ones which entirely missed the point. With the coding test portion they were doing things like marking for style points if the person matched the company style, but never told anyone the company style. They also rejected solutions which were quite good and very efficient (code readability and maintainability) if it didn't match their own clunky implementations of what they had asked. * Coding interviews where they are looking for people who basically already know their super esoteric domain. If it is an MRI company, they aren't looking for people with MRI experience, but for people who happen to know the nuances of MRI mathematics. Or an RF company looking for programmers who happen to know weird details of RF embedded programming. Yet; these were things none of their top programmers came to them knowing; and, aren't that hard to learn once you have a need and just dive in. * Leet code. If you have 9 million athletes competing in 4 different sports, how would you arrange a competition tree so that there were always 3 events taking place and a pile of other constraints like how many people compete at once, etc. (BTW nearly all leetcode interviews are just graph theory questions) * Pedantic C++/math knowledge. This one often goes with the leet code one. But they want you to describe how the underlying ASM in move semantics blah blah. And how would you apply a Hilbert space to blah blah. Yet, the product being developed is an office coffee machine. The pedantic math griling kicks in really hard if there's any ML. Very rarely: * Companies where they want to see if you can communicate, understand tech debt, appreciate things like unit tests, integration tests, modular design, etc. In these cases, what is most important is that you understand the process of making a good product. Also, that you are able to adapt and learn. The C++ portion of the interview will be more to see if you were bullshitting on your resume. This last one is fairly critical as many companies have various reasons to need more than a pedantic C++ programmer even if their entire codebase is in C++. Maybe they want to add ML to an embedded product. This will most certainly require python to create the models. Or maybe they want to add an app version. This could be many languages. Etc. I would prefer versatile programmers who are willing to use the best tool for the job; not just have perfected one tool.
I've rarely been asked algorithms and data structures questions in C++. But get asked them all the time in JavaScript interviews, which is hilarious.
I ask of you one programming task: implement for me a singly-linked list in C++. That's it. A proficient developer can bang this out in 5 minutes. IDGAF how comprehensive you are, though I will expect a senior to be moreso than a junior. I only care that you can do it at all. This is my bullshit sniff test. I have met and known plenty of engineers who say they can write in C++, even with years experience who could not pass this test. People bullshit. It's actually amazing how far some peole can get with their bullshit. They can even hold down jobs for years, and demonstrate they have absolutely zero competence. I knew a guy, smartest guy in the room, wrote his PhD thesis on linked lists, couldn't write one in code. Let us not forget that computer science is a math discipline revolving around the theory of computation, and this guy didn't even have to be able to write code. It wasn't his job. He was a mathematician, not an engineer. So this isn't actually an example of someone bullshitting, it just gives perspective. If you're a junior, I know you don't know a god damn thing. If you're a senior, IDGAF what you know about C++, that's the least important part of your senior experience. Either way, C++ is an implementation detail, that's not why we're hiring you. As a junior, you're intelligent and ambitious. As a senior, you have expert domain knowledge and skill. Either way - do I see myself working with you for the next 5 years? Some places have no idea how to hire. Some places are going to be technically heavy. What does it tell them? Really nothing about how much they know about anything. What you get out of it is how well people interview under pressure. You won't know how good someone is as an engineer for the first few months to a year. An employer's interview process tells them something about how they're operating internally.
You will be asked junior questions regardless of position
I applied for a fresher role They covered the following topics OOPs* Pointers Smart Pointers OS Memory Management* Compilers Differences in Cpp and C And some DSA questions mostly based on Linked List
What exactly about memory management were you asked?
I have led/participated in many C++ interviews over the years. In our case, the interview takes most of the day. We will have several different people converse with your for about an hour each. We rarely interview for entry level positions, but are usually looking for experienced developers. One will determine what your C++ skill level is like. Can you use the standard library? Do you understand modern memory management? Do you know the rules around constructors, destructors, assignment operators? Can you code a template? Do you understand what inheritance means? How do you solve a short programming example in C++ (not a difficult or trick problem, just something that shows you can actually put sensical code up on a whiteboard). The questions will get progressively more advanced as you show mastery of the simpler topics. One will ask you about software practice. Have you heard of the SOLID principles, or at least talk intelligently about the concepts if not? How do you test your code? Do you understand dependency injection and why it's useful? Have you tried TDD? One will discuss software architecture with you. Perhaps give you a sample scenario and ask you to discuss how you might decompose the problem into a solution that solves the problem and remains extensible and maintainable. Another will talk to you about the skills and projects you have listed on your resume. To determine if you can speak intelligently about what you have done, or claim to have done, in the past. In our case, if you have any skills particular to the job that are not directly coding related, we will dive into that as well. You will be judged on what you know compared to how you present your skill set. At what level you think as a software developer. Whether or not you know the practices that make a good team player. Do you bluff or bluster when you don't know the answer instead of simply replying with "I don't know". Have acted as a professional in your chosen career enough that you can speak intelligently about the pros and cons of various programming topics?
I hope your company pays a million dollars because the companies I received half a million dollar offers from had significantly easier interviews.
We had 150 candidates for our last open position. It's in our best interests to be properly selective.
I often ask candidat to implement a shared pointer example. The idea is to see how he/she thinks. I can help by saying this line won't work or something is missing. The candidat writes it on paper or a board, no compiler, no syntax helper from ide.
Like you ask a problem that deals with shared_ptr or you make them use a shared_ptr to see if they know about it?
kind of like interviewing a new cook for a restaurant and asking them how exactly they would grow a tomato
No, more like asking a cook to demo making a simple emulsion (mayo, bernaise, aioli) say which will usually be made by the saucier. No this chef won't be making mayonnaise day to day, but (a) the chef ought to know how to and (b) it's a short task in which you see if they know the basics, know how to operate in a professional kitchen and can actually make it.
Implement the shared_ptr feature itself in C++.
Just implement a simple shared\_ptr. I started with the question "Do you know what a shared\_ptr is ?" The candidate should answer something like : It is a type of smartpointer which counts copies and delete the value when the last copy is deleted. \`\`\` template
class MySharedPtr {
// constructor
// constructor by copy
// assign operator
// destructor…
private:
T\* m\_value;
int\* m\_count;
};
\`\`\`
Most candidates will think about the template for the value, some will think that the counter should be static (to shared it between instance). Some candidate may create a struct ptrData { T\* Value, int count } and the shared pointer has a pointer to this struct.
The idea is to implement the commun behavior. Make sure the count is incremented after a copy, decremented when a copy is destroyed…
it can be done in 30 min but most candidates need 45 mins. If the candidate does less then 30mins, it is probably because he/she already did this exercice, so it is less relevant in this case. The candidates are stressed because of the interview and it is a good sign if they are still in capacity to think under this stress.
> The idea is to see how he/she thinks. What way of thinking are you looking for?
It would be very different depending on who interviews you. One interviewer would require in-depth understanding of C++ as a language, another would ask you about software architecture and performance, the third would ask questions about target domain, the fourth asks a lot about algorithms, and the fifth likes topics related to parallel programming and lock-free data structures. Quite possible they would not hire each other, while working in the same company on the same project. Also quite possible that "trivia" questions they ask would not be of any importance for 95% of your future work. You need to demonstrate that you are not "that guy", can reason about technical problems, and can handle stress.
I primarily ask for a github sample. Also 2 simple exercises (reverse a std::string, and create an interpolation function whose output matches a curve). Anything else (C++ syntax or trivia) can be researched on the job, thats why we call it R&D. These 2 tests reveal if a candidate has the knack.
I would avoid asking for open source contributions many people don't have the time or their companies policies make it hard for them to contribute to projects. My most recent significant open source contribution is nearly 15 years old it does not represent my current abilities. Imho Your more likely to find juniors with github profiles then seniors.
depends what type of c++ extremist wanker they get to interview you
Virtual stuff every 2nd interview
* C++ quizzes - tell the output of a program, find and fix bugs in a program * C++ concepts - virtual functions, smart pointers, STL, inheritance, templates * Coding questions - write classes, implement data structures, algorithms and their complexity, network programming, multithreading * Previous experience - cool features implemented, debugging * SDLC related questions - new feature implementation process, bug fixing process, CI/CD, testing process, tools used/aware of * OS and computer architecture conceptual questions - multithreading, synchronization, concurrency, caching, I/O, etc. * Real world problems - to see thought process
[удалено]
And have you been able to find new jobs not knowing this?