> although in the interview I might politely ask (after solving the problem) what relevance it has to the job, just to make the point.

I highly advise you don't do this, because I don't consider it polite. Everyone tries to be objective in final review, so don't jab them with something snarky they'll remember about you while discussing your performance.

It's an exercise, it's artificial. Can you convert an abstract idea into code. Yes there are bad questions and bad interviewers, that doesn't mean wanting to see you write code is bad. You don't want Microsoft's new "real world, from the job" style questions [1] because I've had a few of those and they're misguided. Way too much internal domain knowledge is missing and I spend too long trying to get it out of them.

That said, DP in a phone screen for devops is a little tough.

[1] https://www.businessinsider.com/microsoft-new-developer-inte...

I wouldn't ask it snarkily. I've been hired for jobs before and then asked to work on stuff that, while related, was nowhere in the job description. Got hired to do Java/C++ development, was pushed into being part-time sysadmin for our primary test environment because my team had spare capacity and our dev-ops team didn't. There were times I went 6 months without touching a line of Java or C++. Another guy I worked with said he got hired for real-time c development and then got pushed into Java development shortly after arriving.

Some managers embrace the notion that all software engineers are basically the same and you can shuffle them around outside their area of expertise and then complain when efficiency goes down. Now granted there are probably more strategic ways to ask about that then the direct method I originally posted, but if I'm interviewing with one of such managers, I want to know.

Fair enough; phrase it "What would my day-to-day work look like?" "What percentage of time coding/designing/testing/meetings?" The current interview process could be better but right now these coding questions are just a proxy for ability/aptitude.

I just want you to have the best shot at this job. Be as critical about the process as you want after you get it.

Wasn't trying to be confrontational, advice from the other side of the table is always appreciated. :)

And you're right. 9/10 times it'll just be a fizzbuzz proxy and not worth the risk of a direct question.

There's literally no way to not ask that snarkily. Don't do it.

Also, it reeks of "justice driven opinion having" which is scary beyond reason for an employer, e.g. "They didn't ask for this feature the right way so I'm not going to deliver it/deliver it in a way that makes them unhappy."

I know it's the internet, but you seem to projecting a certain tone onto my statements that wouldn't be there. I don't know where you got "justice driven opinion having" from, it's mission-driven opinion having. They need to know I can code my way out of a shoe-box, and in return I need to know they can lead a team of engineers through a Chuck-E-Cheese ball pit.

Someone who gets defensive about an honest, neutral-tone question about their interview process is likely going to be defensive about more important decisions, which means they take feedback poorly and are likely a poor leader. This is assuming I'm talking to a hiring manager and not an HR rep.

I don't apply to missions I'm not willing to work overtime for. If I'm going to make sacrifices for whatever my employment does, I require that my leadership shares my commitment and is fundamentally competent such that they don't needlessly waste my sacrifices. In any interview I'll be probing for that as respectfully as I can, just as they'll be probing me for technical aptitude and whatever character profile they're looking for.

But that's not what you're accomplishing by asking that question, you're taking a moral position beyond your role on a topic you're not an expert in. What you're demonstrating is your lack of perspective and a hubris that can poison a team, turning it into a snake put where people "neutrally" question every decision.

The mere fact that you think you can neutrally ask a question like that is a red flag.

Or I'm just politely asking for confirmation of what I'm interviewing for, as I'm participating in said interview. You sound like that proverbial manager who refused to hire someone because at the lunch interview the candidate put salt on his fries before trying them, and the hiring manager extrapolated that to mean he doesn't properly analyze situations before acting.

As for "role" and "expert", you seem to think that in an interview my job is to be subordinate. Quite the contrary, at present I'm not unemployed and my bills are paid. I'm looking for an upgrade, not a necessity. So in an interview I'm still deciding if the company is worthy of my subordination/my making them more money. I may not be leadership, but I can pick which leader to support. Leaders who are oversensitive to basic, polite questioning during a job interview clearly don't want/need help that badly.

Now once a subordinate, obviously there are times/places for questions and times/places when they are not helpful. But if you consider questioning decisions in general "poison" for your team, and you fear your team turning into a "snake pit" if someone starts asking questions, then that points to a severe lack of trust and/or poor communication between you and your subordinates. Either of which would turn me away even if you offered to double my salary.

It's not honest. You're not asking the question to better understand the situation, you're asking the question to make a rhetorical point. You're not expressing your opinion, you're hiding your opinion, and setting up a "trap" for the employer to possibly fall into if they answer "incorrectly". You think you know better.

Asking questions doesn't create a snake pit, not being straightforward with your opinions does. Asking leading questions that force people to not trust your motivations will certainly create a toxic work environment.

Related, I don't think you actually believe I was genuinely putting forward the idea that you shouldn't ask questions in your interview. I have some not-great theories about why you chose to do that, but this probably isn't worth the time it'd take to figure it out with you...

It is honest, it's just not 100% blunt. I'm saying a professional version of "Now that I've proven my resume isn't a complete lie, you know these problems are irrelevant and non-representative, right?" and gauging their reaction with a plausible out that I was just confirming basic information if I need it. I can even throw in that anecdote about my previous job where I was hired for one thing and pushed into another. Hell if there's another engineer in the room we might even bond over it. If I was 100% blunt I'd be guilty of the very snark you say is impossible not to have and likely get less information about them thanks to pushing too hard. I have to pass their "is he completely full of shit?" test, why shouldn't they have to pass mine? Ideally we both pass our respective tests and both sides become much less guarded as the interview goes on.

As for "knowing better", in the past I occasionally have known better than some of my bosses, as born out in money lost (once to the tune of millions of dollars) doing it their way until they (miraculously and of their own accord, of course) came around to doing it the way some of my co-workers and I had been promoting. Was a minority of cases, but often enough that I don't assume competence or honesty from strange managers without at least some indirect verification.

As for not asking any questions in interviews, I didn't mean to insinuate you meant that exactly. But from your statements it appears you would have issues with non-technical non-job-specific questions, because I'm an engineer and such questions would be "taking a moral position beyond your role on a topic you're not an expert in.". Which to me sounds like "Engineers shouldn't judge businesses beyond their immediate role because they don't have business degrees". To which I'd say I don't need to be an "expert" to judge interviewing techniques any more than I need to be a licensed auto-mechanic to change my oil and brake pads. Likewise I've learned the hard way to examine a business's financial incentives/disincentives, business model and direct competition more closely than the job descriptions, because those factors will determine the nature of the job I'm applying for a lot more than any given mission statement or brief description in an interview. So I may ask questions about those topics as well, despite being "beyond my role".

Since you value direct honesty about intentions: this conversation is beneficial to me in forcing me to explain/defend these perspectives in greater detail than I usually have the opportunity/need to. So for whatever it's worth I thank you for that. It's clear we both come from very different experiences in approaching this scenario, and I'm sure your experience bears out your arguments just as mine does my arguments. I doubt we'll come to an agreement here, but part of me wonders how I'd do in an interview with you if I wasn't aware it was you and you weren't aware it was me, from this thread. Probably never going to find out, but would be interesting.

I can't honestly said I read this. The fact that you're writing this much to try and justify something so simple and unimportant should be a red flag to you.

There's plenty of ways to do it non-snarkily.

Interviews go both ways. If you have a problem simply saying something like "nah, these are just screening problems, it's hard to come up with good ones" then it sounds like there's deeper problems here. Like, the company having issues recognizing even obvious flaws in its own processes.

You will be looking for jobs forever if you read that much into every interaction, and possibly for good reason.

The problem with tech interviews is that it’s super rare to find the right combination of elite technical skills and emotional intelligence required to properly assess a candidate. Those people are usually busy.

What you end up with is someone who is either a mid-level engineer and almost totally green to recruiting or an HR drone with zero technical skills who is liable to believe a bunch of bullshit. Both tend to ask stupid interview questions they learned from a book because they’re out of their depth in some way.

This is not a situation unique to software either; it affects nearly every professional specialization (especially ones where the pay gap between an HR role and a functional role is as big as it is in tech). You’re right, it makes zero sense to put your interviewer on the defensive — being likable is almost always more important than being good.

It is all about phrasing. If you ask it like "I thought this was a X position, doing Y isn't something I expected to be related. I can do it, but I was hoping you could clarify if the expectation was the ability to do X, Y, or both?" you will likely have a far better outcome than if you come off as challenging them.

For embedded programming you are more likely to be asked questions that require bit manipulation, shifting, masking, etc. Maybe low-level C, mapping structs to memory locations, etc. Maybe how you might go about implementing hardware interrupt handlers, or how you could put a microcontroller into low-power sleep and then wake up, etc.

It is common for embedded software engineers to come from electrical engineering, and they are maybe less likely to ask CS-type questions.

I interviewed for a position (and got the job) about four years ago for a C#/Angular senior developer and I was suppose to be “speaking my architectural experience into the team”. At the time, the only way I could document 10+ years of development experience was by putting a job I had worked at for a decade doing cross platform C and C++ with a little bit of assembly.

Out of nowhere, after I thought the interview was over, one guy kept drilling me on that type of low level stuff that had nothing to do with the job just to prove how smart he was. I remembered all of it thanks to a decade of dealing with it and too much time on comp.lang.c but it was still off putting.

I’ve since cut all of that stuff off my resume.

I wasn't there, so I can't know how the interview went, but are you sure the motivation was "just to prove how smart he was" ?

If I'm already 100% sure I'll recommend a hire, it's not rare for me to go off-script and dig into random stuff in the candidate's experience, first of all because I find it interesting or fun to talk about, and second because having deep knowledge about anything is positive signal, regardless of whether it's useful for the job.

I have definitely been in this scenario and asked people who had relevant background to work out low-level performance details of their code. I hope they didn't think I was "drilling" them.

My (would be) manager who was also technical (he has since self demoted to an IC role after his kids graduated college) was already satisfied. It was one of the other devs who was sitting in.

I think he asked me something about the difference between undefined and implementation defined behavior and the an example of each. This was in 2015. I had the same question when it was relevant for an interview in 1999.

I’ve geeked out with another hiring manager at an interview about some old 8 bit coding I did but that felt different.

If I was hiring for this sort of position, I'd want them to talk about the difference between hard and soft real time. I'd want to know whether or not they were familiar with embedded software development standards and what sort of things are restricted from "normal" environments when you are working in the embedded environment.

The last thing I would want to see is lines of code on a whiteboard. I'd want to see how they'd structure their code, not whether or not they remember C/C++/Rust/language-de-jour syntax.

All of the proposals for questions that I've seen in this thread are for basic programming skills. Not whether or not the person knows the environment we are hiring for.

Hopefully. But I've heard from people who got asked leetcode style stuff in addition to those kinds of questions because it was company policy for anyone interviewing to be a "software engineer".

Best to be prepared.

Although embedded is possibly one of the few software positions where these questions might be somewhat relevant- aside from embedded who is writing a sort by hand anymore; although even in embedded it isn't that common of a problem. I just find the questions especially egregious for an average software dev working on something like a web app, since in that case hand-coding something like a sorting algorithm or BST is almost always the wrong thing to do.

Oh I completely agree, but like it or not such questions have become the unofficial Software Engineering SAT. Part of being an engineer is working with/around other peoples' bullshit. If the furthest that extends is a dumb interview question or two, that's a dream job. :)

I'm a Web developer, and I did hand-code the Dijkstra path-finding algorithm recently. Granted, it's not common, and I didn't do it from memory, but at least I knew what to Google.

I needed to represent the shortest path between nodes on a map, so I needed the internal data from the algorithm, thus the need to whip out my own version.

I interview A LOT of candidates.

Don't bother with books about how to get a job. You're wasting your time.

Instead, spend more time with books about hiring. How to run an interview, what to look for, ect.

The reality is that companies mostly want to hire someone who can do the job and behave in a team. (There are some exceptions, but you probably don't want to work there.)

At the end of the day, doing lots of leetcode exercises doesn't prepare you on how to convince someone in an interview that you can do the job. A few leetcode questions might help build your confidence, but that's about it. Really, all you need to do is play along and evaluate the people who are interviewing you.

BTW, what I usually tell candidates goes something like this: "Look, we only have an hour, so these questions are contrived. We don't write code like this on the job. The best way to succeed is to play along and answer the question." And then, as I get into the questions, I sometimes add things like, "This isn't a JSON versus XML question" and "If you can use async-await, we wouldn't have a question. I'm trying to evaluate..."

You are still asking the leetcode question, and no matter how fairly you explain it the candidate who practised those questions will probably do better.

I doubt it. Leetcode questions tend to be deliberately technically challenging, and focused on algorithms.

I don't ask technically challenging questions. I'm more focused on comprehension in a technical discussion, and a basic comprehension of concepts that are critical for the product that I work on.

actually, i would think leetcode interview problems would be more relevant for embdedded development jobs. in embedded, you're less likely to have access to libraries that implement advanced data structures, sorting and searching, string manipulations, etc. so you'll need to do more of it by hand.

To a point, but like most things in software my experience is you look up someone who's already figured it out and copy them :) Granted you have to understand the code a little more and be able to apply it to whatever system/hardware constraints you're working with.

But just as higher level Software Engineers rarely have a need to implement recursion/graph traversal/etc, in embedded its even rarer due to the relative expense of such operations. I'd say knowledge of signal processing and how to power/performance/memory-optimize code would in general be much more valuable.

That’s my impression too. I would expect more handcrafted code on embedded systems and you need more awareness of computational complexity and memory needs.

It's not as important as you would expect for a couple of reasons:

1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets.

2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job.

So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.

This. If I'm in embedded land, especially hard real time, I don't care how quick something is, as long as it complies with the real time requirements.

Programmers will endlessly prematurely optimize. I'd much prefer to see simple code that can be understood and optimized where needed, rather than squirrely code that runs fast but is unmaintainable.

As much the current interview process is broken, I honestly believe this is the best attitude.

In a way, it's nothing more than studying for some goal you think it will improve your current situation, and the good news that it is pretty much a solved problem, with plenty of information online that can be used to practice.

Just take into account that for an embedded position you might actually be asked more domain-specific questions.

I wish you the best in your seearch!