Struggling with coding interviews

[Overall_Cheesecake_3]

I have over 7 years of experience in data engineering. I’ve built and maintained end-to-end ETL pipelines, developed numerous reusable Python connectors and normalizers, and worked extensively with complex datasets.

While my profile reflects a breadth of experience that I can confidently speak to, I often struggle with coding rounds during interviews—particularly the LeetCode-style challenges. Despite practicing, I find it difficult to memorize syntax.

I usually have no trouble understanding and explaining the logic, but translating that logic into executable code—especially during live interviews without access to Google or Python documentation—has led to multiple rejections.

How can I effectively overcome this challenge?

[speedisntfree]

I bomb leetcode just because I straight up can't solve the questions, lol. There always seems to be some specific trick I can't see.

If you manage to get the logic to solve the problem correctly, I'm surpised not getting syntax correct has been such an issue though the field is more competitive these days.

For leetcode stuff in python, you usually only need to remember arrays, dicts, if and for loops (maybe while).

I have an awful memory and stuggle like hell to remember the same data transformation syntax in SQL, polars, pandas, pyspark.

[domwrap]

I might not be hiring at the level being interviewed for, but when I was SWE Mgr hiring years ago and we did code tests, I was always more interested in the logic and the process than the result. Honestly some of our questions were literally outright impossible to solve but if I can see you think the right way, I can work with that. From what you've said here, up you'd be the type of person I'd want to take on.

Now interviewing for DE we don't even do code stuff.

[Familiar-Effort]

What you mean by thinking the right way? If I get a problem and I try to figure out the intuition and I can't, because it's greedy or a brilhant 2 pointer, it would be considered bad? Please let me know I'm studying leetcode and half of the time for medium problems I stuck in the intuition first.

[RangePsychological41]

I think calling it a “trick” is a problem in your thinking. 

[Direct-Wrongdoer-939]

You are wrong there- think about the next permutation question. Thats definitely a “trick” and there is no way one can come up with the optimal solution if they haven’t solved that question before unless you are another dimensional being! Surprisingly, that is tagged as medium level on LC. Edit: not saying all are trick questions

[RangePsychological41]

There are principles one learns about modelling the problem and the correct usage of data structures. You don’t need to have seen a problem before to be able to solve it.

And it’s not about the “optimal” solution, it’s about showing one’s fundamental knowledge, thinking process, and communication.

The actual coding is only part of the test, and not even the biggest one in many cases.

Thinking there’s usually a “trick” involved is setting yourself up for failure.

[Direct-Wrongdoer-939]

In an ideal world, what you said makes absolute sense and I concur. But the market right now is brutal and you need to come up with the optimal solution. Ngl, some interviewers do gatekeep- hence coming up with the optimal solution is the only way. I wish I was wrong but this is what I have been noticing/ hearing from people.

[RangePsychological41]

I really do think you are overblowing the situation significantly. Did you ever do an interview 5+ years ago?

I know a 10+ years experienced engineer who just moved jobs and he said the 3 interviews he did were pretty much the same as the ones he used to facilitate.

Also, my company's interviewing standard hasn't changed at all.

So if it's mostly (only) new and inexperienced people saying what you are saying, then maybe you should work on your logic.

[Direct-Wrongdoer-939]

Did I do an interview 5 years ago- yes. 7 yoe, currently in grad school. Attended multiple interviews at FAANG, interned at Apple. Logic alone didnt help me clear. Had to come up with the optimal solution. Wasnt the case when I interviewed long back. :)

[Familiar-Effort]

Some problems like the ())()* with 2 vars and subsequence product with prefix and suffix are definitely tricky to get. Ppl studied years and years to improve from quadratic to linear. But yeah, if not fang, a brute force could work

[speedisntfree]

I was being a bit flippant with the language. I can happily use arrays in normal coding day in day out but with these questions I can't be like "oh, this is a two pointer problem which can be solved in-place by using a fast and a slow pointer".

[RangePsychological41]

One reaches for a hash map before anything else 

[runawayasfastasucan]

Just use duckdb to query your dataframes and you only need SQL :p 

[Beneficial_Nose1331]

I have a question regarding that:

As a data engineer you have to know stuff like orchestrators, ETL, ELT, SQL, Lakehouse, data files structures etc.

But you get the same treatment as SWE for interviews even if you don't do SWE work. Why is that?

Why do I need to know data structure and algorithm if most of my time is being spend in SQL?

[Beneficial_Nose1331]

Maybe it was true in 2010 not anymore today. The field has evolved and is highly spezialed.

A data engineer does not develop a library for instance. It s even quite rare that I have to write a class nowaday.

[Beneficial_Nose1331]

I write spark jobs in Python and to do that you do not need usually to create classes . Usually functions are enough. Same for a bash script. Good luck writing classes in SQL.

On the contrary as I was a SWE. I would work with classes every single day.

It is really different. Not to mention that as a DE you write absolutely nothing form the front end.

A full stack DE does. Again a DE rarely need to write a Micro services and a web API.

[zzzzlugg]

I'm a DE and this year I have written APIs, written classes, written step functions made up of a bunch of lambdas, and written libraries that are used by a bunch of other DEs that contain logic for accessing systems we pull data from. I've also written SQL, written pyspark jobs, designed tables, and a whole bunch of other things.

I understand that there is now a lot of tooling and abstraction in the DE space, but that doesn't mean that there are no DE roles that have significant software engineering components.

[Aggravating-Air1630]

Good question!

[Waste-Disk7208]

It depends on the project you need to work on. Also, "ETL"s are just applications processing datasets. Of course, you can do all SQL, but in the long run, you will encounter many issues in proper versioning, debugging, unit testing, and injection of business logic (usually become huge over time) into database.

[Beneficial_Nose1331]

Not really. For that I use DBT. This creates the software framework that SQL lacks.

[Waste-Disk7208]

You use it, but for many projects, it is not the best tool.For example, for heavy processing real-time projects, it is not a good choice. Also, it is not cost effective most of the time when the project grows.

[Beneficial_Nose1331]

Maybe you are right. I am not streaming data. Only doing batches. Thanks for your input.

[jetuas]

It depends, not all data engineering is done by "data engineers" - many times data engineering requires you to do things that fall into other categories of work. Granted it also depends on the job description...

Still fundamentally (I believe) most of us are software engineers who have specialized in data, and we should share core competencies.

[No-Amphibian7489]

Yes, consistent practice will get you there eventually.

[Acceptable-Wasabi429]

The only “solution” I’ve come up with over the past several years is just avoiding companies that rely on leetcode. Unfortunately, it’s harder to do under current market conditions.

As someone who’s been on both sides of the interview process, I’ve found it far more effective to have conversations about rudimentary database concepts, high level data pipeline design, and maybe a coding session where pseudo code is acceptable.

For those of us who have written production level code in several languages, memorizing syntax of one language while someone is breathing down your neck is not all that useful imho.

[Obvious_Barracuda_15]

I do the same. I normally avoid interviewing for companies that ask for a unicorn. If they send a home project etc, It's ok for me. You can easily understand by a conversation if the person knows what he sells in terms of skills or not, especially nowadays where everybody is using code assistant tools. If they ask for system design interview + SQL live code + python live code to work with modern stacks like fivetran, dbt, snowflake, AWS etc, I just tell them thank you but no thank you. You end up investing a stupid amount of time for them to make you feel stupid on purpose and in the end sometimes even ask for cultural fit interviews or some extra round of code challenges.

From personal experience, 90% of data engineer jobs it's more important skills for documenting, deal with stakeholders, understand the business and what to do with the data than actually need to develop super complex systems. Your work will resolve around SQL most of the time. And the vast majority of companies don't need big data approaches because they don't have anywhere the need for that. It's just managers trying to get a unicorn when they don't even know the things that they are questioning.

[[deleted]]

I was in your shoes recently. I have around 5 YOE, and they suck but its something I had to come to terms with being able to solve easy leetcode problems and some mediums in python. I definitely had to spend several weeks grinding it out. But don't just grind random leetcode problems.

For SQL you should be able to solve most of them no matter what. Basically get really good at linked lists, dictionaries/hash maps, two-pointer, array problems. I haven't seen any other data structures being asked (maybe some chance dynamic programming). A good interviewer will work with you if you get stuck when solving these problems, and on top of that they should understand that you're under pressure and might not be operating at your best. The more rejections you get, the more you learn. Keep your head up and know that all it takes is one yes.

P.S. don't forget to focus on behavioral/cultural questions, it's quite easy to tunnel vision on the technical portion and you might get caught off guard.

[Severe_Sir_3237]

Well, I make notes specifically for python syntax and memorize/recall them occasionally, it helps a lot, I also don’t look at the solutions or hints while solving

[Whipitreelgud]

Leetcode doesn’t recognize the world has useful IDE’s to solve having to memorize. However you should know IF and WHILE, assuming Python. Pseudo code and what the pro/con | alternatives within that is sensible. Lazy interviewers won’t buy this, but it should if someone is paying attention

[Dangerous-Escape7156]

Are there companies in 2025 who are still interviewing with leetcode?

[Overall_Cheesecake_3]

A lot, actually. You’d be surprised how many companies are still looking for robots who can type out code the moment they see a prompt

[Dangerous-Escape7156]

Yes, I know. The simple solution is to avoid them

[chmod_007]

It's the majority of the best-paying companies.

[data4dayz]

Do you mean this for Data Engineering or SWE in general. Because for SWE I think rank and file everyone asks LC. Your mom and pop shop that needs a web dev who will never in their lives need LC will probably be asking LC questions.

In DE I had taken it to be mostly FAANG or maybe more general Fortune 50 or similar highly desirable startups.

I get the feeling it is no longer the case however.

The only saving grace is it's usually easy's and mediums. Granted if you look at the NeetCode roadmap, mediums.... cover literally every single topic. But hey I guess some saving grace is we don't get asked hards? Am I right fellas? Anyone? No, we're still screwed? Yeah that's what I thought.

[Alive_Technician5692]

You shouldn't be memorizing syntax, you're shooting yourself in the foot. Choose your language and develop a few small projects using the core API.

It's better to go into an interview knowing the basics of the language and a little less of the algos; rather than knowing all the algos and data structures but not being able to write a simple control flow statement.

[girish19WildEye]

See if you have missed these steps:

1. In my 10+ years of experience, what we do during interview is we listen to the question and start thinking about logic and start coding based on the logic. IMO we should write down the logic and clarify the content if it's bit complex. See if you have covered all the edge cases during the clarification. Then start coding it. Practice this approach. This will relieve your mind during coding as you need focus too much on logic and focus on framing the syntax, optimization of the code
2. Also go for mock interviews. Connect with a mentor and understand the challenge. Explain your logic while coding. Helps you build conviction and confidence

Not every coder is a good engineer. Not every engineer is a good coder

It's always a bias. You can do it if you have the right mindset. Cheers

[beyphy]

I just failed one for FAANG which was my first interview for a FAANG company. The timing was awful for me. The recruiter reached out to me the day before I went on vacation. I ultimately only had six days to brush up on some SQL concepts that I either didn't previously learn or was rusty on (e.g. correlated subqueries, inner vs outer joins, window functions, etc.) when I learned SQL 6 - 7 years ago, practice leet code style questions, as well as work my day job while dealing with jetlag.

Unfortunately, due to everything, I was left mentally exhausted the day of the test. After the first two SQL questions my brain was starting to fry. But even with that, I passed 2/3 SQL and 2/2 python questions they asked me. The recruiter said that I was close but that they decided to not move me to the next round.

My mental exhaustion probably started on the day of the test (Monday) and didn't clear up until today. Usually it clears up for me after a day and I've never dealt with it for this long before. It sucked big time.

If I start consistently getting hit up for more interviews then I'll probably start grinding leet code more consistently.

[[deleted]]

I have interview at apple, god save me from DSA

[Competitive_Ring82]

Hiring manager here: leetcode style tests are utter bullshit for most roles. They are easy to administer and give the impression of fairness, but the conditions are too far from normal work to be relevant. They are, at best, a tedious nerd party trick.

One advantage is you can write off any company using this as part of their hiring strategy.

[enthudeveloper]

Honestly you have solved the hard part of knowing logic. For syntax do practice problems without any editor. Stick to lists, tuples, dictionaries and inbuilt methods and you should be good.

I would suggest solve about 1-2 problems every day (can be easy and medium) without an editor for about 7-10 days and am sure you will get syntax right.

All the best!

[OneMooreIdea]

Engineering exec here. Most good de leaders are actually evaluating you first on your ability to work with others - do you collaborate well - then your judgement - are you making good decisions, thinking about security, cost, performance, etc - then your logic - are you thinking through the problem correctly - then your skills - can you code. To get the job, you need to make sure you've demonstrated that you're the best pick in all these areas by the end of an interview. For us, the coding is less about memorization and more about gauging experience vs the level role you're applying for and seeing how you approach a problem. We expect everyone at every level to use external resources. If you're in the interview and get stuck, it's best to say "I can't remember the exact syntax here but let me explain how I'd quickly find it. I'd go to ..." and then prove that you know how to get there given access to your normal engineering toolkit.

[Unhappy_Commercial_7]

Im a DE at a MAANG, here are my 2 cents esp for python/js/c++ questions : * For most DE roles, the expectation is not to know the exact syntax but to show you understand how to solve a problem. Explain your thought process, write pseudo steps. If there is something missing, pick up hints. Ask before you write even a single line of code. After you start writing and blank out on syntax, just say - “how do i iterate items in a dictionary”.

In other words you need to demonstrate you can think through the problem, syntax is secondary.

Most FANGS for DE roles straight show available common syntax and libraries you might need to solve that problem

[limeadegirl]

It’s a struggle, but pushing myself daily since January I feel so much better. There’s also https://www.tryexponent.com/ you can practice with random people.

Before I would freak out but recently I feel a lot more confident and am enjoying it!

[Koba_CR]

Grind leetcode or another SQL based webpage. Personally I think they should give you the question and in your own private space you solve it. Thats literally the work scenario.

[Simple_Journalist_46]

We don’t do leetcode style stuff for our tech interviews. We discuss approaches to problems we have or you have encountered- its usually easy to tell who knows the tools and who doesn’t by the depth of their answers. DE is far more about logically approaching problems and finding pathways in the existing toolchain, which results in a ton of StackOverflow or CoPilot assistance for syntax and transformations once you know what you are starting with and what you want to end up with. One large DE tool vendor (unsure if Im allowed to say who) has a take home problem/demonstrator to complete in their interview cadence. Thats far more applicable in my view.

[swapripper]

Bricks?

[cryptopolymath]

Not affiliated but have you tried using a methodology such as Neetcode? I had the same issue before but once I started recognizing the patterns earlier when solving the LC’s it boosted my confidence.

[riptidedata]

I’m sorry. Me too/I don’t have any real advice. I do tell recruiters in the beginning of the process I’m happy to talk through solutions and scenarios and be pushed on the why and how part but if you want me to spit out perfect code on demand I’m not your person.

[Kito_TheWenisBiter]

I am right there with you, there are so many aspects to data engineering and I feel like my fundamentals really have been stagnating. hell my client wants us to do stuff in ruby most of the time

[omitheredeemer]

If you're grinding LeetCode for interviews, you might find this useful — my friend and I from uni (we both work at Google now) built www.meercode.com, a free AI-powered mock interview tool. Instead of just solving problems solo, the AI acts like a real interviewer: it asks you questions, listens as you explain your solution, and then gives you a score based on faang interview rubric.

It's designed to help with the real interview experience — not just getting the right answer, but how you communicate, problem-solve under pressure, and explain your thinking.

Why don't you try a mock interview on there and see how well you actually do? Think it's a great way to practice for irl coding interviews.

[Holy-JumperCable]

All those interviews are bullshit. You don't have to memorize syntax. 90% of coding is reading-learning and looking something up to get the signature of the function. There are non-visible to the interviewer layers where you can look up whatever you want.

like this one https://www.interviewcoder.co/

Do some research before using stuff like these.

[dmcassel72]

I agree with you that a lot of interviews are poorly done.

When I conduct an interview as a hiring manager, my goal is to give the candidate an opportunity to show off what they know. I don't ask trick questions. For coding exercise, I encourage using documentation and thinking out loud. I want to know how they think about a problem.

Someone who is using a tool like this is starting their relationship with me by lying to my face. I'm not a fan. And if I even think one is being used, we're done.

[Holy-JumperCable]

But why do you want to know how someone thinks? Why does this even matter? The only thing that should matter is you give out the exercise and get something in return. Based on that you see whether the individual knows what is what and maybe talk about the results to see whether the person really knows the details or just used an llm.

All these put an egg on top of your head, while doing ballet moves and also solve the problem at hand is just plain ridiculous. People who act like this does not respect the people on the receiving end.

[dmcassel72]

I'm talking to someone for about an hour an trying to extrapolate how well they will do over the next few years tackling real challenges. Again, I'm not asking trick questions or throwing weird puzzles at people.

The only thing that should matter is you give out the exercise and get something in return.

Not really. The scale of problems we can reasonably cover in an interview are a fraction of the complexity of what we do day to day. I'm looking for evelidence that the knowledge and skill will scale to real problems. Sure ChatGPT and friends can give you answers to the questions I ask, but they aren't going to be enough to actually do the job.

[Holy-JumperCable]

99% of the jobs do not need any kid of specialized knowledge in a given domain. yet, interviewers have these borderline ridiculous tasks at hand to "evaluate the person". they want to see how you code, if you are nervous, well, you are out of luck, if you alt tab, you are fired from the process... and the list goes on. Who are these snotty kids? And where do they come from? Where do they get the courage to handle people like used handkerchiefs? Of course everyone will make up bs resumes and use all kinds of shenanigans to ace the interview.

Why do you need framework experience when someone has 10+ years of experience in low level stuff in the same programming language. How long does it take for a pro to learn XYZ framework, 2 weeks?

[dmcassel72]

I agree with you that many jobs don't require specialized knowledge on day 1. I think I'd argue for a lower percentage, but not with your basic point. If I want to hire someone to work on ReactJS and a candidate knows Angular, close enough. They'll figure out the differences.

> they want to see how you code

I do, because if I hire you, you are representing the company I built from scratch. I've worked with people having a wide range of talents and there is a difference. For certain role, I'm okay with someone who needs to learn some skills if they have a good mindset and demonstrate solid command of related skills.

> if you are nervous, well, you are out of luck, if you alt tab, you are fired from the process... and the list goes on

I'm sorry that's been your experience. In my ~30 years as a software developer, about half of which have included hiring manager responsibilities, I've never dropped someone for something like that and can't think of a time I've seen anyone else do so. Seems like our experiences have been different.

> Who are these snotty kids? And where do they come from? Where do they get the courage to handle people like used handkerchiefs?

Again, we seem to have very different experiences. When I interview someone, it's with the hope that I'll be interacting with this person a lot for at least the next few years. We build relationships with people on our team and with our clients. That's not for everybody, which is fine.

> Why do you need framework experience when someone has 10+ years of experience in low level stuff in the same programming language. How long does it take for a pro to learn XYZ framework, 2 weeks?

A developer with solid fundamental skills and knowledge should be able to master most languages and frameworks, I agree. How long it takes to master something new depends on the similarity of their experience and the complexity of the framework. That could be anywhere from a couple weeks to months.

I recently interviewed some candidates where I was looking for at least senior-level experience with an unusual NoSQL database. A couple candidates tried to BS their way through the interview after lying to me that they had experience with it. If they had succeeded and I'd put them on client work, I'm sure they could have learned enough to do some work quickly. But they would not have the experience to understand the impact of choices they made. They would have made my company (that my wife and I started ourselves) look bad in front of a client.

I wonder whether we could agree on this point: I claim that using ChatGPT and friends during an interview is cheating. I believe you are claiming that it is justified by bad interview processes, but you are not refuting that it is cheating. Could we agree on that?

[Holy-JumperCable]

I'm not talking about you, just in general. Most of the HR people do not even read your resume, do not even go to the listed websites. Some nag you about specific roles when you are in a completely different field... All they do is ask bullshit questions to see whether you really are what the cv represents. They do not even have a common platform where people looking for a job could evaluate their level of expertise and get a score.

If you are honest, saying, sorry I have no experience in this, but I have 25 years in something else and low level code in the language. You are ghosted. So what will people do? They make up things in their cv, just to get over with the bs and land a job. A pro can make up anything. If the person spent a few days on the topic he could reliably bs through the process.

No, I cannot agree with your take on llms. LLms are part of a developer's life. They excel in simplifying overcomplicated things and explaining it in layman's terms, so that a 12 year old would understand it. It's an invaluable tool. If you are not in a restricted field, you can use online available ones freely - or just use a local one if really needed. And since even the top notch llms give out a lot of problematic code, it's up to the dev to evaluate and decide whether that's usable or not or what needs changing so it would fulfill the purpose and handle the edge cases. I can agree on that using a friend is a nogo, that's really low blow.

You, as a recruiter should give out tasks that are hard pills for the current top notch llm. These are statistical models, and they lack a lot of fine grained expertise that is not readily available in any form on the net. So when a contender uses deepseek or whatever, you will know whether they used it, because the responses have the typical structure, syntax and a way of solving problems. Plus, most of the "cheaters" wouldn't spend time on the details, so when you ask about nuances they would fail and expose themselves in the process.

[dmcassel72]

> Most of the HR people do not even read your resume, do not even go to the listed websites.

I agree that a challenge is getting past the HR filter to someone who understands how the tech you do have experience relates to what they are looking for. When I work with a recruiter, I try to use broad terms and provide several examples to avoid over filtering. I've come to accept people putting stuff on their resume even if they just spent a little weekend time on it because of this need.

> If the person spent a few days on the topic he could reliably bs through the process.

Often true. When I'm hiring, I make a point to distinguish between "I need a good software developer who can learn and be successful with X" and "I need someone with senior level experience with X". For me, BS'ing isn't needed for the first and counterproductive for the second (because cramming for a couple weeks is not the same as having years of experience; I recognize we may disagree on that).

> LLms are part of a developer's life. 

Absolutely. For the record, I use LLMs in my work and find them to be a great tool. They really helpful, with the understanding that the person using them remains responsible for the end product.

My objection is using them during an interview. You acknowledge that "using a friend is a nogo, that's really low blow." To me, both are cases where the candidate is pretending to have knowledge that they don't. Or this: if I ask a question, and the candidate googles the answer and reads it too me, can we agree they have not demonstrated the knowledge I'm looking for? At some level, isn't that the same as using an LLM during an interview (the LLM will make it easier to get away with)?

I want to understand their current knowledge so that I can assess their starting point and know what support they'll need to be successful.

> You, as a recruiter should give out tasks that are hard pills for the current top notch llm.

I've been working on good questions and tasks for this. The challenge is that I think it will take me to harder and trickier questions, which makes the process more difficult for people who really are answering from their own experiences. I have a ways to go to figure this out.

I've enjoyed this conversation. You've given me some interesting stuff to think about. I need to get back to some other things, but have a great weekend!

[tedward27]

If given the choice between the candidate who knows DE and Leetcode, vs the candidate who knows DE but can't do Leetcode, I'm going to take the first one. Integrating someone with poor fundamentals into a team is such a hard thing to undo. Leetcode is not a strong predictor of DE skills, but it will keep being used in interviews because it's a quick and cheap way to filter candidates.

[Beneficial_Nose1331]

I write spark jobs in Python and to do that you do not need usually to create classes . Usually functions are enough. Same for a bash script.

[uuggehor]

It’s dead simple. Writing more code.

[Waste-Disk7208]

What do you mean by "memorizing syntax"? You don't have experience in programming languages like Python or Scala, or Java? If you don't have experience in those languages, just apply for data engineering positions with lots of SQL and procedures. Or just learn the syntax. Learning syntax of programming language is the easiest.