And I would google it on my phone and answer:

https://stackoverflow.com/questions/2209224/vector-vs-list-in-stl

Do I get the job?

Is knowing the difference important when you are looking at what data structure to use for what problem? Yes. Is it important that someone should be able to rattle off all the differences off the top of their head in an interview? Not really, at least not in my opinion.

Overhead. Literally and technically the answer.

First off, it’s spaces

In a previous life I used a brief ”questionnaire” when interviewing developers. they are told it has stuff we don’t expect them to know for the job, so don’t worry if you can’t answer some questions. It was then used to guide the conversation. I learned a lot about candidates and how they think as talking through their answers. I also learned some new ways of doing things. Some of our tech was not very common so it was about identifying candidates we felt would be able to pick it up quickly. Only once did I have someone start filling it out and then leave.

Hahahahahaha

The colors always look weird to me, as it was designed for the "green-scale" 4 color display of the original GameBoy. When it's put onto a GameBoyColor or something it ends up all purple and blue.

The GameGear version (wiith a real color display) looked much better but actually played worse, because it had one less button, making the controls much more awkward.

But thanks for trying it out, hope you had some fun with it...

lol, thanks, but I don't need any help. (PS-> Saying things like "for your own sake" are what come off as condescending). Generous of you to think of me though.

For me, when hiring, we would just send them a test, (think your Minecraft example), ask them to produce some reasonable code that solves the problem, with some parameters (could say don't use stl for example if that is your particular kink) and give them a couple of days. Didn't care if they had something memorized, the real question we wanted to answer is can they think through and solve a problem and write reasonable code?

If the code looks reasonable, then interview them based on the code as to why they chose the things they did to understand and explain their choices and didn't just copy/paste something from somewhere. Also gives you a chance to verify if their brackets are same line, and that the use spaces instead of tabs, and that their code is not an unreadable mess.

I will admit though, I never hired people for SpaceX or Tesla, nor have I had to send a person to the moon, so maybe my opinion is irrelevant. Wouldn't be the first time.

That's not what I meant, sorry. To be clear, the "weird and proves nothing" part was referring to having to create a linked list implementation in a 2 hour time limit (when there are many implementations out there):

As for this:

Heck yeah I would! There could already be a third party software package out there I can license that does 90% of the work. Or maybe do some research to determine what data structure would be best suited for the information, start with a great well supported open source implementation and take it from there.

If I had a developer on my team who didn't take the basic first step of Googling to see if the problem had already been fully or partially solved and potentially save us time and money, and instead started re-creating the wheel, I would be questioning their sanity.

You get information from everywhere. Peers, education, books, PHD papers, and yes, Google. Having something memorized to spew out in an interview is not a sign that a person is better suited for a job than any other factor.

It is okay to agree to disagree on this. I am not asking you to find me a job, or help me land a C++ game programming career at your company, so you don't need to feel responsible to correct my wrongheaded opinions.

After being actively involved in hiring since 2008, having done hundreds of interviews for engineering and management positions on the hiring side, I learned that it’s much better trying to get an idea about how a candidate thinks about a solution than test minute details (worse: under time pressure), especially if the technical field is vast. And what the candidate wants from the job. Motivation.

What is considered technologically basic to you may be irrelevant to someone else. The field is simply too vast and I found it’s a waste to test for basics.

My own SW background is from way back in the 1980s, started as a hobby spending countless hours writing assembly for 6502 and 68000, followed by a formal education (equivalent to a master, at an engineering university in Austria). I’m pretty sure I can trip up any applicant especially millennials and younger in an interview for a SW position, if I wanted to but what’s the point? Likewise I’d bomb some new modern SW engineering concept. Last time I gave in to that idea of interviewing was for a SW job for Symbian, which had really odd resource optimized driver concepts and it “weeded out” like 90% of applicants. It was pointless.

I found it best to just head to the cafe with the applicant, chat about what’s going on around town to break the ice and then listen to what they worked on and how they solved problems. Then I explain a typical engineering problem at our company and ask what their approach for a solution would look like.

You are conflating two unrelated things:

1) Having information memorized to regurgitate on command (build me a linked list! Now!).
2) Problem solving (We have to build a system that hasn't been done before).

I am saying they are two different things, your opinion seems to be both are required to be a good software dev. I disagree.

If you want to continue, you can PM me. I am not going to respond, but if it makes you feel better, go for it.

I keep coming back to this thread because I want to see what you guys are going to write next about linked lists.

I'm waiting for you to start arguing about how to write a memcmp() function that is hardware attack resistant.

That is what I got asked when I went to interview at SpaceX years ago. Needless to say, I wasn't enough of a "rock star" to pass. I gave them an answer that worked but it wasn't the answer they were (specifically) looking for in the interview.

f558a5e7-e433-4618-9cae-b89fd70bdc57_text.gif

Is there anything more annoying than arguing engineers

Finally. A proper interview style with no dick measuring. I've always found that problem solving skill and personality go much further in the workplace than having someone that can implement a memorized version of Dijkstra's algorithm.

When I was hiring, I looked for:

can I work with this person
work ethic
did they work on outside projects related to the field
etc.

I honestly didn't really care that much about the coding test or whatever other than just feeling them out for just basic understanding (which is usually easy to determine). You know why? Because you can have the smart programmer ever who can ace these quizzes, but then is a jerk to everyone he works with, and writes horrible unmaintainable code that works but is unreadable, and then causes problems in every meeting as only his solution can be the correct one.

I was looking for the guy who did programming projects in his spare time, was working a job while going through college, and is humble and likeable. Because how can you be that bad of a programmer if you're able to do projects on your own outside of class/work? I'm sure it happens but I haven't ran across anyone who did that stuff who wasn't pretty competent.

I refer to them as black box programmers. No one wants to deal with them. You don't want them to talk to anyone since their interpersonal skills are garbage. Give them a task and they do it but bring them into a meeting and they'll start spouting off about linked lists, no matter how irrelevant it is. They also try to show off if included in a panel interview with their superiors.

I have always answered a question asked of me on that subject with a "not very often" and lost out on jobs as a result and had no problems with that. Homeownership and growing, active, kids, aging parents that need support etc. takes the place of most of that outside time. I have more in common with those kinds of co-workers. Knowing how to compartmentalize and multi-task and still complete assignments in a timely manner are more important traits to me to find when I am interviewing someone, if that's even possible in a half hour interview. Someone who picks up new things quickly too. Also, as a job candidate I was making judgments about the interviewer as well and how well rounded they were and whether I could work with them. I have not had an interview in 15 years, but have interviewed all of the new people in our group when they applied over that time period. We have anniversaries of 15 years (me), 15 years (my boss), another 15 years, two 10s and 5 years for co-workers and our director is at 25 years next year. That's says a lot about who we are. 15 years ago I was a single guy, an apartment dweller.

For all of the linked list talk, I don't think people are truly appreciating what an understatement this is. A lot of people talk about what THEY would do if THEY were making pinball machines, but then the jobs always get filled by people already or formerly in the industry so they never get a chance. Here's your chance.

When some yahoo named Ted Estes emailed me a reply to an rgp post a million years ago and said I should interview at Williams/Bally I didn't hesitate. Well, I did hesitate, because I lived in rural Virginia and had no desire to double my cost of living by moving to the Chicago area. But then I realized I'd regret it if I didn't at least go investigate. The rest is history. (I came to Williams and then pinball shut down, so you can blame me for that bit of history!) But still, it's been quite the wild ride, and still going.

Agreed. I pour all my efforts and creativity into my job. Last thing I want to do is side projects relating to the same kind of work. That’s what pinball is for!

Totally agree. That work/life balance is critical for long haul for me. I love software dev as a job, but when I go ‘home’ there is zero development going on. Everyone is totally different regarding that… but I would never gauge someone’s commitment based on how they spend off hours. That seems pretty crappy to me.

I grew up in the Springfield area, maybe it's geographical.

Is vehicle depreciation even a thing anymore? We bought a 2019 Honda Pilot NIB and we bought a used 2019 Honda Pilot, an identical car in all aspects, for the same price in 2021. That was a wake up message to me at the time. Never saw that before COVID/supply chain theories.

I need to start limiting my work day posts to this thread, it might look like to Keith/JJP that I lack the proper work ethic.

A large portion of people here believe that pinball coders - who have the most awesome job ever - should be "banging out a couple mini wizard modes" on their free time. Ya know, cause it's pinball and pinball is fun and people should work for free cause it's pinball.

Just check out the BKSOR owners thread if you want to see some of this lunacy.

I suspect I may be very well suited for a job like this as well… though not from my own perspective. There’s no way I would personally want to turn this hobby into work, as it would ruin it for me.

I would hope no other software people don’t understand this, at least none that haven’t already been doing this for decades.

Why?
Are you applying for the job?

I keep wondering if this is one of those "hidden interviews" like what the halcyon days of Silicon Valley were known for: See a billboard with some weird gibberish.... Oh, you decoded it?! You're hired!

Argue about linked lists all day long... good... good... oh, you won?! You're hired!

Only one way? What about the design choice of the sentinel value being nullptr or a dedicated end() node. A dedicated end() node require a little more overhead but allows for iterator and standard algorithm support. STL containers use std::allocator for memory by default, however you can provide your own allocator if needed including (gasp) a memory pool strategy. If you feel the need for placement new, look into emplace() methods. c++ has evolved quite a bit since the 89 standard...

The correct answer is "Whatever is dictated by your organization's coding conventions." Bonus points if said conventions are enforced by automated tooling.

My alma mater just posted some stats from the CS class profile of 2022 (University of Waterloo). Here is the total compensation (TC) of new grads in $CDN so do 0.80x for USD. Most of these kids will be working in the US (brain drain -- but honestly the $$$ tells the story)

pasted_image (resized).png

I think the part that escapes you is the vast majority of people reading this thread stopped caring about you, your credentials, how other companies handle anything, or why you think that's important after the first paragraph or so.

Your opinion is noted. Good day <your preferred pronoun>

Lol, that was never an issue, my old company paid so poorly that I was only hiring new college students 90% of the time. Even Amazon though must have been hard up because they were constantly pinging me the past couple years along with Facebook.

I think that's the problem. Sometimes, it is important to know who your audience is. Pinball people are probably more interested in pinball than C/C++. Personally, I'm more interested in the code of the 6800 processors that Bally and Williams used in the 80s and 90s. I have seen and done enough C/C++ for a lifetime.

Actually, it's even more complicated than that. You're referring to managing memory in a virtual address space. In these embedded systems, you sometimes have to manage physical memory when dealing with the GPU. You're looking at tiling if you live at this level in the programming stack.

Now there's something I haven't heard of in a long time. I think most regular software engineers have no clue what SIMD is. It doesn't matter to them.

This is performance and scaling. It's not something most people think about. I have a process in a system that utilizes 1% of the total available CPU. 1% is nothing. The CPU is idle 99% of the time. Now I want to scale the usage. I have 100 of the same process executing concurrently. Now all the available CPU is consumed.

The most important thing I learned was that you need to measure to make appropriate decisions about performance. If you don't measure you don't know where the problem is and if you make a change, how the change affects the performance. I have some really good stories about measuring and how it helped determine where problems were and how it was used to solve them. Interviews I had in the past never touched on any of these topics. As I have previously posted, the interview screener wanted to know if I knew what a DAG is. The only experience I had with that word was https://en.wikipedia.org/wiki/Dag_(slang)

Having spent some time in gaming systems, I can tell you obviously understand game software mentality and methodology. As I mentioned, it's mostly irrelevant to general purpose software engineers who don't care about those things. They only care about features and functionality. Rarely do they care about performance.

One of the problems I have in interviews is that I'm just flat out terrible with vocab/tech talk. People would ask me about things I hadn't used in 20 years in interviews and I'd like freeze up like a deer in headlights, lol. It's not my strong point at all, and I'm sure I would fail most of your interviews because of it.

But what I am good at is solving problems and I have a good work ethic. Doesn't matter if it's programming, financial, construction, coaching sports teams, etc. I believe I was in the top 10 of code produced out of 500+ programmers and 2nd in code reviews at my old company, but if I had been interviewed under their later process I probably would have never been hired, lol. The funny thing is, nobody at the company even knew those metrics except me as I'd worked with a couple people to get that information compiled. It amazes me to this day that I was the only one who cared at the company.

Basically what I'm saying is, the interview process is a crapshoot and you never know exactly what you're getting until they've worked there for a couple years, no matter how rigid your process is. Cream of the crop people tend to leave faster if they're not tied down to an area or have other options, so even if you hire the best of the best, you might be rewarded with high turnover. Some of the brightest guys can also be extremely detailed oriented, so while what they produce is excellent, they may also be really slow.

You were mentioning performance above, one of the embedded units I worked on was extremely cpu limited and had all of these tasks that were constantly being starved due to lower priority. I spent a lot of time eeking out performance improvements and profiling due to tasks getting starved and others overrunning. I'd fix it and then some other team would check in a change the next week and use up what I just saved.

These traits, along with being a positive person that I would want to work with every day, are the most important things a person can bring to an interview with me. I'll know within the first 5 minutes if you have been technical in the past and have some experience there, and not by asking you to write me a name parser or know why manhole covers are round. I really want to know if you are going to be a positive impact to our environment or a negative one.

Ok. I'll bite (again). This thread should probably have a title change since it is no longer really a discussion about the actual job opening. Apologies to the OP and free bump.

Three things to start off with before going into the "TL;DR" section.

1. None of this is personally directed at any poster. It is supposed to be debate about posted issues.
2. I have found that "if you think you know a lot about a topic then you are mistaken because there is always someone else who knows more than you". I have been on both sides of this - I know more than someone else and someone else knows more than me.
3. More apologies as this is almost "flynnibus-esque".

<TL;DR>

Unless you have actually seen the source code for any software in question, you can't say this is a true statement. Most companies that produce a software product have closed source code so I doubt if there are any statistics to back up any claim - on either side. The way I see it is that it doesn't matter if you use STL or not. If it gets the job done (even in real-time simulated environments), it gets the job done. I try not to make anything more complicated than it needs to be.

I have to disagree with this - as a generalization. Most software engineers care about getting their features implemented and working. Performance is after thought. It is only considered when the feature isn't working in a performant manner. Why waste development time on something that doesn't need attention? The only important area of design that I have encountered where after thought is an error is security. You need to design security into your system. You cannot "patch it in". The topic of security is a whole 'nother can of worms. These two areas (performance and security) are usually handled by specialists rather than generalists. Think "performance review" or "security review". These are done by (external) consultant teams. That has been my experience.

That's a contrived example and doesn't prove anything. A good optimizer will optimize that all away. The function foo() will be inlined and the function call overhead will be eliminated. I know the point you're trying to state. You're trying to state that function call overhead is wasted CPU execution cycles. STL overhead is wasted CPU execution cycles. In a real time environment, you want minimal wasted CPU execution cycles.

The problem with this example is that you haven't MEASURED and just generated an example. If you measure and determine function call overhead is the cause then inline the function to remove the overhead. If you measure and determine that bulk of a more complicated foo() function is the problem then removing the function call overhead will make no difference (number of CPU execution cycles spent in the function is orders of magnitude more than the function call overhead).

It always come back to measure. If someone uses STL in a function and it's not causing any significant wasted CPU execution cycles then why bother wasting time on it? It all sounds academic (religious - metaphorically speaking) rather than practical (real world).

Use a profiler or some form of profiling. Just be aware that the profiler itself injects overhead into the system. A good profiler will amortize the overhead equally (evenly) across the execution. The overhead will also be minimal. The other issue with a profiler is that it changes execution timing and in a pre-emptive thread execution kernel this can change your execution flow. As a side effect, this may expose synchronization bugs in the code.

Why stop there?

• In a system where paging is implemented, you should allocate blocks of memory in physically resident pages (non-paged) to reduce page faults. Page faults are orders of magnitude more of wasted CPU execution cycles.
• If you really care about performance then you need to investigate the processor cache line size to keep your data in the processor cache as much as possible.
• Then there's TLB misses that can introduce overhead. Change your data structure layout to keep high frequency use data in a cache line and in the same page to reduce TLB misses. How low do you want to go?

If you're debugging crashes in debug mode then you aren't debugging crashes in what your customers are using. The best debugging I ever did was in retail (release) mode. I once had a debug session that lasted days in a debugger that stopped execution at the crash. All I did was inspect memory and code. It took me days to figure out what happened. My experience is that most software engineers give up debugging failures far too quickly. It's reflected in the quality of software being released by software companies nowadays. That is my opinion - nobody else's.

I am the same. My last company let me go and I tried interviewing around but failed all the interviews. If I interviewed with the company I worked for over the years today, I would fail.

This kind of problem depends if you are running in a preemptive or cooperative threaded system. Cooperative threading requires cooperation. Duh. If you hog the CPU then you will starve others. Preemptive threading can still be abused by high priority threads that don't enter wait states. Good software will spend most of its time in a wait state, unless it's computationally intensive. If it's computationally intensive then it should probably be in a separate thread at a lower priority than system or user interaction threads.

The one area where true cooperation is required is the ISR. Any ISR must be as efficient as possible and do the minimal amount of work handing off lower priority tasks to be executed outside the ISR. The ultimate ISR is a trap handler.

Seen plenty of these over the years. In a relatively open system (like desktop computing) it doesn't really matter that much. In an embedded system it matters more. If it matters enough then add some code that enforces quotas or whatever to prevent it from happening. In debug builds for projects that I worked on in the past, I tracked all memory allocations and could tell at termination how much leaked and by whom (culprit code).

</TL;DR>

Sheezus, take it to PM already.

...but much more interesting

Where do you guys find the time to write epically long posts.

I try, but then a squirrel runs by and i'm done...

Can I qualify? I haven't worked as a programmer, but when I use a dating app I make a linked list of all the hot girls on it.