paint-brush
The growing pains of becoming an Intermediate developerby@saurabhmaurya06
874 reads
874 reads

The growing pains of becoming an Intermediate developer

by SaurabhAugust 26th, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

You’ve gotten a little comfortable at work. Code reviews are shorter than your code. And you've shipped some stuff. So you’re motivated to branch out and learn more. But the sheer volume of resources is mind-boggling. Focus on these 5 areas: Low-level/Library Design, System Design, Concurrency, Design Patterns and General Coding Practices. You should be able to find equivalents for other languages. Most design concepts are language-agnostic anyway. You can expect a range of answers based on how skilled the interviewee is.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - The growing pains of becoming an Intermediate developer
Saurabh HackerNoon profile picture


So you’ve gotten a little comfortable at work. The deployment lifecycle is no longer black magic. Code reviews are shorter than your code. And you’ve shipped some stuff.

Hopefully, you’re motivated to branch out and learn more. But the sheer volume of resources is mind-boggling!

One pragmatic approach is to stick to things that will also help you interview better.

That way, you will have a sense of progression and a goal to stay focused on.

Focus on these 5 areas — 
1. Low-level/Library Design
2. System Design
3. Concurrency
4. Design Patterns
5. General Coding Practices

The resources I’ve listed will be Java-heavy but you should be able to find equivalents for other languages. Most design concepts are language-agnostic anyway.

Low-level/Library Design

If you look at past interview questions for SDE2/3 at Uber, Amazon et al., you’ll see at least one round tends to ask such low-level design. Two commons ones I’ve heard of are — 

1. Design a Logger Library
2. Implement the Streams Framework in Java

I especially like the Logger question; you can expect a range of answers based on how skilled the interviewee is.

Stop for a minute and try it. Once you’re done, ask yourself the following questions —

1. Did you decompose your implementation into different interfaces? Or is it one super-class with everything?

2. Are you cognizant of the thread-safety of your classes?Is your Logger a singleton?

3. Lazy loaded or eager loaded? Why?

4. Is it pluggable? Can a third-party extend your library with alternative implementations?

5. What about garbage collection? Are you creating too many objects and causing memory pressure?

Log4j2 does an amazing job of documenting it’s own design. Go take a peek when you’re done trying the problem.

I haven’t been able to find any other good resources for low-design. Holler below in the comments if you find anything useful.

System Design

This is more in line with what developers tend to think of when someone says “design questions”. Two commons one here are — 
1. Design a URL shortening system
2. Design Twitter’s Newsfeed system

A solid way to get started is Donne Martin’s Design Primer. It’s long but it’s an excellent breadth-first approach to getting comfortable with system design.

At the least, you should be comfortable with — 
1. Async v/s Sync writes; Messaging Queues
2. Consistency patterns — especially eventual consistency
3. Database types (SQL v/s NoSQL) and scaling patterns
4. Caching at different levels
5. Breaking a problem statement down into different independent services

A great follow-up resource is Grokking the System Design Interview. It has detailed discussions on specific system design questions such as the two I mentioned above. It’s a paid resource but an excellent one.

[Source: https://github.com/donnemartin/system-design-primer]

Concurrency

Concurrency is another topic that distinguishes junior engineers from more senior ones. It’s surprisingly hard to get right.

“Java Concurrency in Practice” should be required reading. You’ll walk away with a much better understanding of — 
1. Java’s Memory Model
2. Happens-before relationships
3.Spurious wakeup calls
4. Volatile v/s Synchronized
5. Thread safety, wait and notify and many others

If you code in a different language, find an equivalent book. Debugging race-conditions without a thorough grasp of the concepts will be very painful.

Java Multithreading and Concurrency by Educative is a great follow-up resource. Read through the concepts; then stare at a couple of solved interview questions. This will be much easier than attempting them cold-turkey.

Design Patterns

You aren’t likely to be pop-quizzed on these. But you will see them emerge as you plow through different design problems.

Once you read up on them, you’ll start seeing them everywhere. A few examples — 
1. Adapter — Arrays.asList()
2. Decorator — Collections.synchronizedCollection(new ArrayList<>())
3. Prototype — Immutables.copyOf()
4. Command — Runnable interface
5. Strategy — java.util.Comparator#compare()

StackOver has a huge list of patterns found in Java’s core libraries here.

I tried reading the legendary GoF book — Design Patterns: Elements of Reusable Object-Oriented Software, but I confess I couldn’t make my way through it.

Instead, I tried Head First Design Patterns. It doesn’t look like a technical book at all but it’s actually a great read.

The different oddball stories stick and do a great job of teasing out the subtleties of similar patterns. I finished this over a weekend and laughed through a lot of the book.

I’ll give the GoF another try a couple of months later. The discussions in it are probably more relatable with experience.

General Coding

Books, Books, Books

“Effective Java”. This is an excellent way to get used to Java’s idioms and best practices. It’s chunked up into 90 independent topics — each a couple of pages long. So you can read the sections relevant to what you’re working on.

“Clean Code” — Last one I promise! — is another excellent read and very handy when you start reviewing other people’s code. It’ll help you pick out code smells in a heartbeat. Like “Effective Java”, only thumb through the sections you think are relevant right now.

Getting Comfortable with your IDE

Fine, this doesn’t pass the “makes you better at interviewing” test. But really, becoming fluent with your IDE makes coding a helluva lot more fun!

I use IntelliJ and it has a nifty “Key Promoter X” plugin. Each time you use your mouse instead of a keyboard shortcut, it screams at you. You should feel like a pro (and very harassed) in a couple of weeks. If you’re using another IDE, try finding the equivalent there. Or use IntelliJ, it’s awesome.

42 IntelliJ Idea Tips and Tricks is a conference talk on Youtube. It’s an entertaining way to get acquainted with the most used power features in there.

This is a big list — And it has books! Instead of being in a rush to finish things, think of improving a little every day by going through some of these. Good luck!

Oh and by the way, I’m assuming most readers have 0–4 years of experience. If you haven’t started working yet, stick to LeetCoding. Come back to this later.

Design concepts don’t tend to sink in until you’ve worked with a couple of systems in the real world.

Appendix

Links

Log4J2 Architecture

Donne Martin's System Design Primer

Grokking the System Design Interview by Educative

Java Concurrency Course by Educative

Stack Overflow Glossary of Design Patterns in Java Libraries

Tips and tricks using the IntelliJ IDE

Books

I like picking one good book in each foundation area and making sure each book is orthogonal to the rest.

Effective Java — Primer on Java best practices. Very easy read.

Clean Code — Good rules of thumb for coding

Java Concurrency In Practice — Foundational book for grasping concurrency

Head First Design Patterns — Fun, effective way of thinking about Object-Oriented Design

Designing Data Intensive Applications — Highest rated technical book I’ve ever seen. Great for System Design but huuuuge. Best to read a little at a time.