Top products from r/ExperiencedDevs

We found 25 product mentions on r/ExperiencedDevs. We ranked the 24 resulting products by number of redditors who mentioned them. Here are the top 20.

Next page

Top comments that mention products on r/ExperiencedDevs:

u/ShadowWebDeveloper · 2 pointsr/ExperiencedDevs

Yes, you should. Working at Google is awesome. The interview process can be intense but the benefits are worth it, and honestly I love the culture here.

Please get Cracking the Coding Interview if you don't already have it. Do the problems on paper and eventually time yourself to see if you can fit a solution into ~35 minutes.

I'd also recommend watching MIT OCW 6.006 Introduction to Algorithms if it's been a while since you did a Data Structures and Algorithms course (or, if like me, you never actually took one!)

Once you've got a few CTCI problems under your belt and have a wide enough range of knowledge, you can try some free practice interviews through interviewing.io (referral link). They'll match you up with interviewers from e.g. Google, Facebook, Amazon, AirBNB, etc. for free, anonymous mock online interviews, where (importantly!) you'll get full feedback from the interviewer afterward. They'll tell you if they'd move you to the next step, what you did well, and what you could improve. Notably, real interviewers are often barred from giving this feedback for legal reasons, so this can be very valuable.

One thing to note is that if you're interviewing for e.g. SWE, you can usually delay your interview as long as you need to in order to study. I delayed my phone screen for like a month and my onsite interviews for a few months.

Also note that many people who got hired here got rejected on a previous round. You can almost always try again later if you don't get through this time (usually after a year).

Good luck!

u/JaneTheSands · 3 pointsr/ExperiencedDevs

It sounds like you're in a position of an ad hoc decision maker / prioritiser. Ad hoc decision making, and attempting to satisfy everyone, is very stressful and ultimately impossible. Here's a step by step of how to get some clarity, if possible:

  1. Slow down.
  2. Start keeping a record of daily tasks. (Not too much detail. Some ideas: https://davidseah.com/node/the-emergent-task-timer/ or https://qotoqot.com/qbserve/ )
  3. Once you feel you have a representative sample of the work you do,
    1. Categorise the tasks (development, support, mentoring, etc.) and make a pie chart of how much time goes to each.
    2. Schedule a 1:1 with your manager, make sure you'll have at least one hour of interrupted time, bring the record with you.
    3. Ask them to assign a hierarchy of relative priorities to each of the task categories.
    4. Ask them if there are any "priority overrides" (this particular client, or that particular high-level employee.) Each override gets its own category. Who's more important to satisfy immediately, client X or executive Y? It's not your job to make that call.
    5. Ask them to divide a pie chart of "weekly work" into percentages of how much they'd ideally like you to spend on each category. Compare that with your existing pie chart.
  4. On your own, translate the pie chart to hours, given 100% = 40h (or however many it says in your contract.) That's your budget for X category.
  5. Schedule blocks of uninterrupted dev work, for as many hours as you ended up calculating in point 4. If people ignore them, call the blocks meetings, set yourself as busy, and maybe if your manager agrees, add them as a co-participant in the "meeting".
    1. Tip: if you're lucky to work in a place with flexible hours, shift your hours to start earlier than most (and leave earlier), or later than most (and leave later): this will give you a chunk of time when there are few people in the office who are likely to interrupt you.
  6. Continue keeping a record of daily tasks. Check if your effectiveness goes up. Hopefully it will, so maybe send your manager weekly emails with updates so that they can see prioritisation worked.
  7. If anyone tries to get you to switch priorities or go over budget on whatever category (meetings, support, whatever), tell them you'd love to, but this conflicts with priorities and goals your manager set out for you and your team. If they try to negotiate, push, or complain, send them to your manager, because the manager is responsible for team resources. Make sure your manager is on board with this before you do so. (But it's their job, so they should be.)

    Some notes:

    I remember reading a story about Dalai Lama, who recommended meditating for 1 hour a day. When asked what a busy person should do, he recommended meditating for 2 hours a day.

    Context switching generates overhead. Your manager may be not experienced enough, or trained enough, to understand that. They may also not be able to visualise the extent of the things you are asked to do, because the requests aren't coming through them. That's what you need the log and pie chart for.

    "I don't have the authority to..." is a common negotiation tactic - it works wonders when you're a line employee, but it will backfire if you're trying to increase your authority in the company and aiming for a promotion. In which case you will need to find some other ways to say "no" in a polite way.

    All this is designed to take emotions out of decision making as much as possible, while still allowing you to express empathy for the person asking for help. People in need of help are often in distress, and are not thinking rationally, and they will do what they can to resolve that distress ASAP. The task is not necessarily as urgent or important as they portray it - but they will describe it so that you share their feelings and thus their distress, to motivate you to help. So you have to find a way to empathise with them (because people do not take it well when you tell them "you're over-exaggerating") while not letting them make you solely responsible for solving the problem. "I can see it's urgent, and I'd love to help, but my boss..." is one way of doing that.

    In general, you have a limited amount of decisions your brain can make every day. Reserve them for the important stuff, and introduce as many routines into your life as possible. There's a number of books about that, for example "How to be a productivity ninja"

    (If possible, organise rotating "on call", "tech support" or "bugfix" roles - but this requires buy in from your manager and your team.)
u/Spawnbroker · 3 pointsr/ExperiencedDevs

If you really want to push the envelope on TC, especially as a more experienced dev, you're going to need to ace the system design interview(s).

I'm still learning this myself, but a good book you might want to check out is Designing Data-Intensive Applications. I've also heard good things about Grokking the System Design Interview.

Good luck! I'm going through the studying process as well, it's brutal.

u/TheSpoom · 2 pointsr/ExperiencedDevs

The Clean Coder is pretty great as it talks about being a professional developer and all that that entails. Very opinionated though (as all of Uncle Bob's books are). "If you don't do TDD, fuck you" is a fairly accurate paraphrasing of one chapter. Still, I found a lot of value there.

I recently read Rework which is a very quick read, but very dense with information on how Basecamp runs their business and many ideas of things that you should or should not do. If you do any freelancing or are thinking of starting your own business at some point, I'd recommend it.

Probably going to read Remote next as I'm working with remote business partners myself.

u/BinxyPrime · 1 pointr/ExperiencedDevs

you could probably just read one good book about code architecture, the truth is no architecture is perfect, you always make trade offs between time, money, readability, performance.

I hear this one mentioned very often on the podcast coding blocks
pragmatic programmer

But i would definitely ask around before dropping $50 on a book. Maybe read some of it at a book store and see if you like it first.

u/azCC · 3 pointsr/ExperiencedDevs

I've read this and "Stalling for Time: My Life as an FBI Hostage Negotiator." They are both very good companion pieces.

https://www.amazon.com/Stalling-Time-Life-Hostage-Negotiator/dp/1400067251

What I enjoyed most was how it changed my perspective on negotiating. Especially hearing stories where someone gives a hard deadline that is essentially meaningless, it's hard to create a mental model to map the Stalling for Time into real life scenarios, but Never Split the Difference does create these models and they are very useful.

u/porto88 · 1 pointr/ExperiencedDevs

Java Concurrency in Practice
Not only does it cover the specifics of the java concurrency packages and how to use them, but discusses lots of good programming practices that are essential to being a good programmer and not covered in many other books.

u/loveisdead · 9 pointsr/ExperiencedDevs

I'm going to assume that there are no actual differences between this interview and the interviews at other places other than the change in behavior you described for this answer. Keep in mind this could be a bad assessment.

Human nature does play in to the dynamics of an interview and negotiation. Perhaps you were to eager in your previous interviews and that ended up coming off wrong to the interviewers. What you might have done is made the interviewer think that they need to convince you to join them instead of you convincing them to let you join. Coquettish behavior can be very powerful when used correctly, assuming you have something people want. This book helped me understand a bit more about the various types of behaviors people tend to build for their personas either consciously or unconsciously.

https://www.amazon.com/Laws-Human-Nature-Robert-Greene/dp/0525428143

Obviously its very grain-of-salty, but these behaviors are definitely part of human nature in a general sense.

u/PM_me_goat_gifs · 1 pointr/ExperiencedDevs

I have heard good things about The Linux Programming Interface but cannot verify it is as specific as you are looking for.

I think some of Julia Evans stuff is good for this.

u/FrenchFryNinja · 3 pointsr/ExperiencedDevs

Radical Candor is good. Extreme Ownership also. I had an old CEO recommend Wooden, by John Wooden, but I didn't get a ton out of it at the time.


https://www.amazon.com/gp/product/0932633021/ref=ox_sc_saved_title_4?smid=ATVPDKIKX0DER&psc=1 Becoming a Technical Leader came highly recommended to me, but I haven't gotten into it yet.

u/tmorton · 3 pointsr/ExperiencedDevs

Is this your first role as a lead? You're adjusting to both a new company and a new job.

Some of these problems are just kind of "welcome to leadership" - for example, managing your meeting load is now a decent part of your job. You do need to be in a lot of meetings. You will also get invited to meetings that don't exactly need you. Figuring out what's important, and performing well in those meetings, is a big part of the lead's job.

I highly recommend the book The Manager's Path which has a section on the "tech lead" role. There is a sidebar that addresses almost your exact situation - a first-time lead that doesn't like the job. The author's answer was (very roughly) "yup, it sucks in some ways - that's the job." But the experience as a tech lead is necessary to get promoted beyond an individual contributor role.

Of course, there are also problems with the company. Every company is dysfunctional in some ways. You need to decide whether this company's problems are ones that you can fix and/or tolerate. It might be a good challenge if you want to level up your career.

u/roodammy44 · 1 pointr/ExperiencedDevs

I haven’t read it because I have no time and 2 young children, but I badly want to read exercises in programming style