C/C++

Objects arrive in the program. Each object may have a phone number and/or login (both or either one), and a payload in the form of binary data. Incoming objects must be stored in RAM following these constraints: If the incoming object's login and/or phone number match those of a previously stored object, then the stored object should be deleted, and the incoming one should not be stored. If an object has been stored in RAM for more than 60 seconds, it should be deleted. It is assumed that objects arrive frequently. At the same time, objects matching by login/phone are significantly fewer than all incoming objects. void process(Object o) { }

[name] tell us about yourself, the products you've worked on, and the tasks you've performed.

During review, a diff is visible that looks like rough copy-paste/strange hack — the code performs the desired action, but it is not obvious how it works or if it works at all. What are your next steps?

What properties should a task have to trigger a reaction like "oh, I don't want to do this"?

What, on the contrary, repels in such events?

What qualities should a colleague have to make working with them comfortable?

How to understand that a change (for example, switching from Boost to the standard library) really 'works'?

How do you feel about activities outside of work (forums, corporate events, sports) and what attracts you to them the most?

Have you participated in technical disputes/discussions within the team? How did they proceed and how were they resolved?

Have you experienced large-scale refactoring of a legacy database? If not, how would you act if you had to?

Why did you leave your previous job?

What motivated you to look for a new place?

There is a code review task: a colleague submitted a solution that works and is covered by unit tests, but the implementation is completely different from how you would do it yourself. What will you do?

Situation: two managers come and give two urgent tasks, and there is no time for them. What would you do?

What is the plan for refactoring and what should be in place to do it confidently?

How could RVO/NRVO optimization be implemented in a compiler?

What will be displayed on the screen? (Question 1: constructors, RVO/NRVO)

What will be displayed on the screen? (Question 3: sizeof array, pointer, reference to array)

How not to find yourself in a situation where in three months everything is 'torn apart' and nothing works, if the lead decided to radically rewrite the code (for example, to remove Boost)?

auto lambda = []<typename>(){};