Programming interviews are hard. This is how to be well prepared:

1. Build basic computer science fundamentals well by preparing these important interview topics:

- Data structures & algorithms
- Object Oriented Design
- Databases
- Operating Systems

Read my complete guide for some good resources for learning these: https://t.co/cUfAnhMLiA
2. Understand that programming interviews test your ability to solve problems through discussion, not your ability to spit out memorized algorithms or programming concepts

Develop this skill by practicing solving problems
My favorite websites to practice problem solving are

- https://t.co/ZvtO3EVBQl
- https://t.co/kglFgmudvi
- https://t.co/QJRZRoA7ed
3. You're required to have an in depth understanding of your projects including

- Which technologies were used?
- What problems were faced and how were they tackled?
- Which important decisions were made and how?

Understand your projects well.
4. You need to be able to demonstrate qualities of a good engineer and a leader. You might be asked questions on your previous projects like:

- How you resolved conflicts
- How you tackled hard situations
- How you delivered under pressure
5. Your ability to organize and articulate your thoughts well matter. If you can build a solution to a problem but cannot explain it to the interviewer, it is of no use.

Develop good communication skills by practicing with your friends.
6. Give interviews even if you think you're not ready. With each interview, you'll know something new to improve upon.

"I'm not ready yet" phase is just making you miss opportunities to learn & understand interviews better.
That's all for this thread. If you find this useful:

1. Retweet and leave a like on the first tweet - it encourages me to write more of similar content.

2. Follow me @ujjwalscript for more useful tips and threads 🙂
PS. For more FREE roadmaps, resource lists and handpicked tutorials, read my guides on programming & development here:

https://t.co/dhvLLLfCmV

More from All

You May Also Like

A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.

Legacy site *downloads* ~630 KB CSS per theme and writing direction.

6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices

https://t.co/qyl4Bt1i5x


PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.

735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices

https://t.co/w7oNG5KUkJ


The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.

The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.