It always blows my mind how most interview in our field. When I first started in tech I was afraid to talk about not knowing leetcode to my peers. 15 years in and I now can confidently say I’ve yet to meet someone who thinks these are a valid metric.
Why do we make this the gate keeper to our industry when we know (except for the very specific roles) we will rarely need leet code type problems. When we do we just google them.
I've read through some of the comments and there is some solid advice. I work at a large company and see this fairly frequently.
You have to approach these things as what do you want out of it.
Do you want to prove someone wrong, just to prove them wrong?
Do you want to steer them in a better direction?
Is this something you will end up owning, so want to avoid the pain?
etc..
There are numerous scenarios. For me, we are one company, large or small if I am not trying to steer it towards a better path, why am I here? If thats the case, I should just take my paycheck and shut up. It's good you care, it means you value your company and/or people.
That said, let me share my exp.
When I was 18 I managed a restaurant my dad had bought. I was a kid telling people who had worked there for years what to do. One day I disagreed with a head waitress that had been there for 10s of years. I did it in front of customers. She got defensive, stormed out, and I served tables the rest of the day.
The takeaway here is, theres a time and place. I feel my role as an employee is to work slightly behind the scenes. I advise my management why I think an approach is better or worse, highlighting we CAN go the way you suggest, but how do you propose we handle X. Usually you can lead them to the way you believe the correct one.
Another point to keep in mind, you dont know everything. I think the most valuable thing I have learned is to understand the motivating factor of why something is going in this direction.
Is there a timeline?
Funding constraints?
Promises made?
Is the person an idiot?
Again, there are so many different scenarios.
There is no black and white answer to your question. I will say though, if you make a statement, be confident you can back it up. Be sure you have thought it through, because there is nothing worse that saying someone is wrong, rallying people to your side, and being unable to deliver.
Small improvements on every feature you write. Just keep iterating, sometimes things look bad and you want to delete useless lines. But those useless lines may be there for edgecases that you don't know about.
Enhance, clean, iterate. Inspire the other devs to write cleaner code by leading by example.
I can appreciate this point of view but I think you are missing out. We learn as programmer's by making mistakes and experience. Familiarizing yourself with a crappy codebase (you didn't write) not only helps you get better at debugging but holds a wealth of experience of what not to do. As you don't write shitty code yourself, how else will you learn to deal with these problems? Everything we do should be to further our own skill set. My first real programming job was working with quants who wrote 1k single procedure Perl scripts, you had to scroll your editor to the right to see all the indentation from conditionals. When I look back it's one of my most valuable learning experiences.
My dev friend and I were looking into doing a similar product a few years back. We stopped because of laws that prevent you from putting anything that may obstruct you or another drivers vision / attention.
This is such a great project. I remember when it started back when I used to work in perl. The main devs on it are awesome. If I ever build anything in perl again that needs an webserver it would be this.
I do most the interviewing for our tech team. I will rarely even ask a technical question. I look for passion, confidence and that they can keep a dialog on the topic of tech going. If I cannot have a conversation with someone for 30 minutes, how would I work on a project with them for months? I personally loathe logic and algorithm questions. If I ever get asked them myself on an interview I will actually ask for a different set of questions. I dont think it adds any value.
Real world code doesnt suck in my opinion. The issue is that a lot of the time it solves problems that these books don't need to. Its easy to build an alogirthm and print it when you know every edge case.
If you would take the first version of most production code put it in a book and write the problem it solves, I'm sure you wouldn't think it sucks. My exp developer 15years, finance industry 7.
Why do we make this the gate keeper to our industry when we know (except for the very specific roles) we will rarely need leet code type problems. When we do we just google them.
So silly to me.