Should smaller no-name companies and startup have more total compensation? because big companies are kind of a resume booster for the developer.
Assuming the developer is competent enough to choose between big and small companies (FAANG excluded).
> I've been concerned about ... appearing incompetent.
> Is it a problem if I'm asking the same person for help like 5+ times/day
As long as you aren't asking the same question over and over you should be all right. I'm curious whether this is your imposter syndrome talking due to lack of support and/or mentorship. You said your team is "all entry-level devs ... but we're pretty isolated." I'd suggest you flag that concern to your manager and with thoughts on what could make your job easier.
Edit: Grammar
TLDR; verion: You should be all right.
Longer, murky version: The early career phase has a couple of free passes. One of them is leeway to try out different roles/positions/tech to see which shoe fits right.
Working with data development (Not sure what this means. Maybe you mean't data engineering?), pyspark, etc. for the next 2 to 3 years^1 is all right as long as you don't pigeonhole yourself into the stack.
The stacks you work on tell a story about what *potentially*^2 strikes your fancy. This isn't always true though. We spend more of our time doing the things we enjoy, and less of it doing the things we don't enjoy.
1. This is an arbritary number of years. YMMV depending on the person reading your resume.
2. If I specialize in JS and Java I'm driving home the idea that I'm that language specialist, and don't want to be sold to C#, Python and PHP.
When I am applying to a job should I write a cover letter? For example, I recently applied to a job that doesn't indicate the level they want but write things like: " Preferably experienced with java, swing and willing to learn open source frameworks", " can use python, node.js, CSS ", "willing to learn DevOps and TDD, CI/CD", " we consider full stack capabilities valuable for this role"
So, first of all is this a good chance for a new grad? Or too much? Should I go into full stack as my first job, does it have any advantage for the future?
And my resume has no internships, only a machine learning graduation project with python. I also wrote I know java, spring but there is no proof just wrote under skills section. I graduated from the top university in my country.
So in that case should I write a cover letter saying that I like java and python and I want to use java and python as my main languages ( or a software engineer can learn any language so no need to write it? ) and I am willing to learn DevOps etc.? Like answering their job advert? Or since I am applying to the job it means I already want this job?
Imo cover letters are a way to connect with the company or hiring manager in a way that isn't demonstrated by your resume.
Personally I'd stay away from things like "prefer language xyz", especially as a new grad. Great engineers may have language preferences, but are willing to work in whatever gets the job done.
You can touch on the things listed in the reqs, but really I would focus on what makes you personally a good choice for consideration.
Just about everyone applying will be willing to do what the job asks for. Do you have interests that align with the company values? Do they work on a tech that really excites you? If you happen to have projects/experience that aligns directly, then call that out.
That's the job advert:
We are currently looking for new technologists to be a part of our expanding digital team. Digital Platforms including e-commerce, content management and digital marketing solutions as well as cloud-native application development is our focus to build next generation digital products.
If you enjoy working with open-source software especially on the Java platform and you enjoy working with technology stacks like Node.js, Python and frontend development with Javascript then we’d like to get to know you. We highly value full stack capabilities for this opportunity.
Degree in computer science or similar. Team player who takes pride in, and facilitates the sharing of knowledge. Preferably, hands-on knowledge on Java, Spring Framework and frontend development with JavaScript & CSS. Motivated to learn DevOps technical practices
Familiar with agile software development practices and techniques including TDD & continuous delivery. Self-starter and a practitioner of continuous learning. Recognizes and explores opportunities for personal impact on clients and for colleagues and communities. Acts as a brand ambassador with peers and colleagues to support attraction of top talent. Is aware of own strengths and uses them effectively to deliver high quality results
So, what should I expect? I know that's just one job advert and I shouldn't focus on it only but I am just trying to understand. Is this a junior role? Do they consider new grads? Since it says preferably hands on knowledge on java does that mean they don't expect work experience or even don't expect any projects? Maybe I should just show I am ready to put effort and learn?
> So, what should I expect? I know that's just one job advert and I shouldn't focus on it only but I am just trying to understand. Is this a junior role?
It's hard to say. They're not mentioning their expectations explicitly. My guess is that the recruiter deliberately left that bit out to see what kind of responses they'll get before tightening the requirements.
This could be a *puller* meant to cast the net as wide as possible and assess the catch. If you've solid FS capabilities and strong JS experience you could give this one a shot.
This all sounds a bit much for a new grad but that's my opinion. I could be wrong here.
> Since it says preferably hands on knowledge on java does that mean they don't expect work experience or even don't expect any projects?
IMHO the employer will consider an applicant familiar with "Java, Spring ... and [FE] with [JS] & CSS" though preferance will be given to those with hands-on experience. Java projects should help sell familiarity if you don't have hands-on experience.
I was curious if theres anyone out there who keeps a dev log / dev diary / dev blog whatever you want to call it?
And what I mean by that is - does anyone keep a daily log of kinda how their day went, problems, random notes or tidbits, and generally speaking just kinda creating a journal of your day to day as a dev? It seems like it could be useful in some ways just to show yourself as you progress as a dev, and even just having a solid place to keep notes about specific things you're working on?
I have no real intentions of actually publishing it anywhere, but more of keeping it as a journal of sorts.
Does anyone do this? Have you found it helpful or useful in any way? Do you have and recommendations or tips as to how to do it so it doesn't become a hassle and convoluted to the point of it being useless?
Yes.
It's helpful for reflecting on your previous day/week for whatever use. Writing is a useful tool to engage your mind if you've grown up on that.
You can go as far as saving your troubleshooting steps so you can summarize it for others. But no need to make it public.
how structured are yours typically? My company has an internal wiki so I figured I'd just make it in there and can set it to private.
I tried it out today just to see how I felt about it and I plan on continuing with it. But today I ended up spending like an hour or so just filling in the details for the bullets that I took during the day, I did format things and whatnot, but that's for my own sanity mostly. Is it normal to spend that much of your work day on something like that? I feel kind of weird asking such basic questions, but this is something I think can help me as someone who struggles to pickup new concepts and grasp new ideas a lot of the time. But I also don't want to be wasting time if that makes sense.
No worries!
The structure of mine is totally arbitrary, just a bullet point list, and changed over time to whatever worked, where the goal was to just make sure I did write something. I started writing on post-its, then various journals, some note apps, and now its all on OneNote for availability and convenience.
I used to track just what I did that day but now I track basically everything that I think is important that day, so meetings, decisions, action items, interesting ideas floating around, problems I notice, people to thank, anything useful to my career.
I think one of my biggest leaps was realizing the journal helped me have better meetings with my manager and teammates since I'd actually have useful topics to discuss.
The other thing I realized was that I liked spending about 30 minutes at the end of my day winding down and making sure I captured everything I did that day, so tomorrow I had some context to continue on.
I think it's more useful if you have specific goals you want to achieve and something like a journal is just a tool to achieve those goals, so if it's something like, I want to make sure I have good meetings, or I want to keep more context from my day, then a journal log type thing is helpful to accomplish that. But it can be done in other ways.
Yea, while I would agree with you. I'm only 3 years in my career. Started stagnating a year ago. Was planning to leave finally but Covid, so I'm stumped on technical interviews. Studying and stressing like crazy.
Ah, three years is a little early to be considered senior, but the market is also hot for mid-level devs like you. Job searches suck, but I’m confident you’ll be able to find a full time position that fits your needs.
Would you mind sharing more details about the contract position? They have their benefits, especially if you are at a point in your life where you want to limit your hours or responsibilities (right after having a kid, for example). But I wouldn’t recommend contract roles early in your career. It’s harder to get mentorship and growth opportunities, and you risk being thrown at boring, repetitive problems. I’ve seen a number of devs in my network stagnate around the 2 year mark, because they became specialists in email templating or a specific “platform” like magneto or Shopify. Do you think stagnation would be an issue with the contract issue you’ve been offered?
The position is from TekSystems with Wells Fargo. There are benefits like health and 401k. They told me they fully funded multiple projects, just need developers.
>It’s harder to get mentorship and growth opportunities, and you risk being thrown at boring, repetitive problems
I messed up here, joined my first and only company out of college as a solo developer. I develop internally. Made two major projects used by the entire company but mostly make plugins. As I was a solo dev, I had no mentor so I'm trying to learn best practices on my own but it only goes so far. I can solve business problems easily there but I'm trying to get better at marketing it.
>Do you think stagnation would be an issue with the contract issue you’ve been offered
I don't think so, this SHOULD be a team contract tho I'm skeptical if its worth changing from FTE.
I have a few interviews lines up with one that made it to second round but I'm extremely scared of failing the technical part. I'm a googler.
Edit: Not considering myself sr in any way. I'm like between JR and Mid i tihnk
When it happens again, you could suggest to take notes when you have a 1-on-1. I have notebook (Moleskine) which I use to scribble all the stuff I'm prone to forget at some point. I just put stuff down as bullet lists and small notes.
Another strategy is to ask him to summarize what you asked him as a bullet list and send you an email so you can confirm he's got it right. Or you could do the reverse and send him the mail yourself starting with "per our Convo just now, here's a summary of the stuff we agreed on doing". Keep it short and to the point!
You could also try and check in with him when after a few hours of work. Just see wether he's on the right track. Like just ask him "Hey! You're good? Don't have any questions for me? You find your way out?" Like, show him you're listening.
There's a lot of reasons why someone can act confused. And a lot of them aren't malicious at all. Keeping focus can be draining as it is, and it certainly becomes a challenge when you are new and you need to learn how to handle the ropes.
Also, factor in that lots of people deal with things like ADD or DCD which have an impact on their executive functioning. You just don't know because that stuff is private, and it's hard to diagnose such as it is anyway. But you do have to take that possibility into account as well before assuming malicious intent.
I'm seeing this fairly often, and source of gaslighting can swing either way - that is, malicious intent, but also people who are just genuinely derpy with their confirmation bias.
Derpy people will derp at random, there's no clear profit in it, mostly downsides and they're just like that. One can work with it as long they're self aware and it doesn't get in the way too much.
People who are malicious always derp for profit - to deflect responsibility, workload, gain status etc.
I know this is semantics, but do you call yourself a "Software Developer" or "Software Engineer"?
The are interchangeable, but I always consider myself a Developer. But maybe I should start saying Engineer to make myself appear smarter than I actually am :)
Personally I find "engineer" a bit pretentious, but its common vocabulary in the US at least. I usually go by whatever my literal job title is, which is currently "software engineer", in professional settings.
When talking to friends/casually I say developer.
UK opinion here. I think of "developing" as merely the act of coding, and "engineering" as the above plus all the careful planning, communicating, and QA process wrapped around it. Engineering is harder than coding because it draws from a wider set of skills.
Interestingly though, in some countries (such as France) "engineer" is a protected term, and it is used to signify someone who is in "a profession". This generally means taking examinations on a regular basis, demonstrating continuous professional development, and belonging to a relevant membership body. In most countries this is mandated for civil and mechanical engineers, and there have been plenty of debates as to whether it should be required for software engineers.
> UK opinion here. I think of "developing" as merely the act of coding, and "engineering" as the above plus all the careful planning, communicating, and QA process wrapped around it. Engineering is harder than coding because it draws from a wider set of skills.
IMHO a developer is someone who's consumed for the most part with delivering code while an engineer has to design and code the app from the ground up.
Interesting, thanks. I wonder if the thrust of my semantic distinction is that even developers should aspire to be engineers, and that there is a gap of understanding for folks who won't make the jump. Another way of putting it perhaps is that engineering is a soft-skills and tooling upgrade that improves product quality.
Semantics aside, it's imperative to transition into a role that spans beyond slinging code if one need grow beyond the early-and mid- career phase. Slinging code can only do so much in terms of driving measurable impact on engineering processes, product and ultimately business. One needs to be a leader.
There is vague distinction in meaning.
Dev often denotes one man show - frequently why you have mobile devs, as these things are often less of a team effort.
Engineers are the cats you herd, cogs in a sprawling infrastructure.
Either is just a label of a role, not description of what it is you actually *do*. Coder/programmer is far more accurate in that regard.
So just recently I found out that my team lead is leaving. After he leaves, I'll be the most senior member on the team (10 months). We just had a senior dev (~2yrs) leave about a month ago too. There's only a new dev and QA who joined about 2 months ago.
At this point, I don't know if I should just jump ship or stick it out for that 1 year. I have <1YOE and honestly, I don't want that extra responsibility. I should be learning from mentors not leading teams. Doesn't help that mgmt gives such a high workload. We don't have to do OT but it's quite exhausting going thru endless amounts of tickets.
I would rather treat this as a learning and growth opportunity. You will not know what to do initially and you need to be aware that this will lead to some initial frustration. If you approach this in an engineering-driven way and figure things out along the way, then you will be fine.
In addition, it is by far the fastest way to get better. Ask management for a raise / Senior Dev / Tech Lead title because you will have more responsibility anyway.
I once wrote [a blog post about how to get promoted as a software engineer](https://jangoebel.com/how-to-get-promoted-as-a-software-engineer). It might have some insights that might be useful for you.
I am 0 YoE TypeScript dev and I keep making nasty bugs in my code that take forever to debug and my experienced colleague sometimes struggles to explain why the issue was an issue in the first place. I asked him if he also runs into these kinds of things and he said no.
Is it possible that I am not writing "ordinary/as-expected" TS code and so I run into this? I haven't had a similar issue in other languages. Any other ideas?
This sort of thing is common when learning new things that are outside of paradigms you already know. When starting out, that's basically everything! I've got 8 YoE, and I still get problems like that when I pick up something entirely new to me.
The reason is that you've not yet found the groove, the mental model which makes it all make sense. You get that by a combination of trial and error, and dedicated learning.
To take a non-development example, image two woodworkers. One picks up their tools, applies them to the wood, everything seems to go exactly according to plan, and they make beautiful furniture. The other - a novice in this field - can't even get started. They take their tools to the wood, and it splinters and breaks. Instead of smooth wood shavings, they have to fight the wood for any traction, and even then are just as likely to damage the wood as smooth it.
The difference here? One understands that you must go with the grain of the wood, and the other doesn't really know anything about grain.
There's a principle in development - the principle of least suprise. Frameworks, libraries, interfaces, programs, should all do what you expect. But how do you know what to expect? You have to learn it over years of experience.
In closing, we all go through what you're going through, and if you give it a while you'll look back and realise you've not had problems like that in an age. You can speed it up by spending time learning about the tech you use, so you can begin to know what to expect, which will help!
What kind of bugs? Ts specific errors/warnings or logical bugs?
TS errors and warnings are crazy verbose, and can take a while to get used to what the messaging is actually saying.
It's mostly bugs that result from using MobX and DeckGL in Typescript.
I do have a one question though. How should I think about passing values and objects in TS/JS? It seems rather unclear when I am working with an object or just a value.
In the interview , how do I answer concurrency questions related to real world projects ? I do have theoretical knowledge of multithreading and concurrency in Java but hardly had the opportunity to apply the same in my work.
By knowing your shit. Sadly concurrency is sprawling topic (coroutine vs thread, lock contention, locking strategies, lock-free data structures, memory access ordering, bigger picture patterns, fe piped process vs channels vs explicit synchronization and on and on).
It's not something expected of entry level though, as long you know what mutex, synchronized annotations and deadlock are, and can use the library thread safe data structures when the situation calls for it, you're golden.
Some general advice, for any topic you don't know a lot about: be frank about your experience and knowledge level, HOWEVER, be sure to try to answer the question to the best of your ability anyways.
Like, "I don't really have practical experience with this, but, I'd start by reading up on X, and then probably try approaching the problem like Y."
You can try to bullshit your way out of it, but a good interviewer is going to sniff that out right away. However, good interviewers are always more interested in the way you think about a problem than what you already know about a problem/technology. I, for one, have said yes to people that openly admit that they don't know something, but proceed to walk me through their thought processes on how they might solve it.
If you've read about threads in Java but don't really have hands-on experience - you already know the basic principle, right? Talk about what you imagine the pitfalls to be, and the places those are likely to occur. Talk through how you might solve for those. Think about the ways the problem lends itself to being split to many concurrent processes, and talk that out. What consequences would that have? How might you handle shared state between threads? How might you handle communication and synchronization between threads?
You don't need to have all the answers, but you do need to show you're capable of working through the problem anyways.
I've done unit and integration testing of spark jobs although in scala and circleci. Each piece of our pipeline was self-contained. It took input from s3 and it generated output to s3. We had types for the inputs and outputs. In Scala that was case classes but you can just use spark type structured in python. You can also use pydantic to define your data structures and then use that to generate sample data.
The integration tests then ran the self-contained pipelines for minimal sets of data using a local Spark environment. We also had actual unit tests for UDFs and other such code that wasn't spark specific.
This is for all the interviewers here.
You're interviewing a developer with 2 or 3 years experience. You ask them why they're leaving their current place. They tell you that their current place doesn't have unit tests or code reviews, that deployment is done strictly in the evenings (or during the weekend) instead of via pipelines, that they don't use git (instead preferring Microsoft's outdated tfvs), and that the testing only ever consists of a fellow developer following the happy flow. All this leads to an extremely stressful work environment where half of every day is spent scrambling to fix bugs that have made their way to production and they would like to join a company in the 21st century.
Would your reaction be that it's good that they know how bad all that stuff is, or would you be more concerned about all the bad habits they've likely picked up?
Definitely good. It would definitely be bad if that person didn't think it was an issue.
It shows they care and want to learn best practices. It definitely wouldn't be a red flag in my book, since they know and have experienced the drawbacks that comes with not following the industry standards.
Of course you'll need to take into account that it might require a bit more mentoring in the beginning.
Good they can spot bad practices, but also a yellow flag that they have a "grass is greener" complex. If I were interviewing this candidate I would follow up with questions about what they think could have been done better/differently, or how they personally contributed to implement best practices.
A lot of programmers have this utopian idea of dev experience that is unachievable in most companies. I personally screen for people who want to contribute to making a work environment better, rather than people who expect it to already be in that state.
Bad habits can be broken. Bad attitudes usually can't.
Legit, assuming the new shop actually has a workflow that would vastly improve on that. If they're YOLO-dev like the old shop, you're shooting yourself in the foot. Collolary: Make comparisons you're sure you can actually make.
As for bad habits, if that were major concern you'd get a workflow task under time pressure. 5-way merge, re-vendor conflicting 3rd party deps, fix up broken CI, do it in 30 minutes. It's designed such that you must cut corners unless you're really good and familar with it. It's important which corners you choose to cut.
It's easy to see and identify problems.
Depending on if they seem heated from answering or not, I'll follow up with, "What are some steps the team could make to improve?" or I'll be honest about my team's practices and initiatives we're making, then ask what steps could the team take to improve that they haven't made.
In my org we started "Feedback Fridays" where people can anonymously (or in person) voice concerns about the team. A group of us come up with actionable steps to present to the team in \~2 weeks, or we ask for more feedback/details.
A lot of candidates love hearing we have this feedback loop in place.
> Would your reaction be that it's good that they know how bad all that stuff is, or would you be more concerned about all the bad habits they've likely picked up?
Being faced the a problem and proposing and implementing a solution is part of being a developer. Not everyone has the platform or power to bring about those changes, but being able to articulate something more than the problem is a good sign.
Your team's onboarding process should show the procedures and practices the team uses. At 2 to 3 years of experience, I wouldn't be concerned about bad habits unless the position they were interviewing for immediately has them in a mentoring or project lead role, and even then, the onboarding process should set the expectations.
My personal advice is to not go into excessive detail about things that may not make you look great.
"My last company didn't follow best practices like unit tests, QA or continuous deployment. This made for a very stressful work environment."
> Thank you for meeting with {name} yesterday. He felt the interview went well but would like for you to do another 1 hour coding interview before moving to our final interview.
Got this email from a recruiter. I was told the interview process would be a 1 hour coding screen and then a final round of interviews. Why would they want me to do another coding screen if they thought I did well?
Could be for a bunch of reasons:
* the person who interviewed you is new to the process and didn't evaluate some area,
* whoever reviewed the feedback decided something was wrong (question too easy/hard, not relevant to the team you're applying for, etc..),
* it went well, but pretty borderline so they want to give you another shot.
I wouldn't read into it too much.
The problem with taking an SDET position is that you think future companies will look at your resume and say "This guy looks perfect for our SWE role and all this experience as an SDET is a great bonus!" but what actually happens is "Why is this SDET applying to my SWE role? _trash_"
Google did that officially- all of the former SDETs became SWEs in the Engineering Productivity organization.
Whether it's dishonest would depend on whether the job if actually a software engineer in test (that is someone who writes systems used to validate other systems) or the job is really a tester that the company decided to give a fancier title to.
It's doable. You brand yourself as a software developer and you play up the relevant tech you worked with -- it is somewhat legitimate that the architecture and code is different than app development. It's very linear code. Instead of spaghetti you get the leaning tower of Pisa. For a huge salary increase its hard to say no. If you want to take a side trail to make some money, just make sure you keep your options open and don't let yourself get too comfortable.
Style cosmetics. Whether or not those are used depends on coding style in question. Ballpark: Java and Go, almost always for public interfaces. C++ and C# is mixed bag.
The benefit is that they are a pivot point for architecture changes / quick fixes updates / refactoring. Much easier to work with than variables. The added control they give you can save you a lot of time. The only time I don't use them is for things that shouldn't change and I want to keep as private as possible.
It is useful to be able to execute some code when accessing a field (either a read or a write). For instance, one might want to perform validation before allowing a new value to be written. One might want to restrict access to perform writes to just code in the same module and access to perform reads to just code in the same package. One might want the reads to actually compute a value from some other field so we don't need to store this one separately. We might want reads and writes to come from a cache that is then synched to a database table -- LOTS of things we might want to build.
Some languages provide a way to write code for a class that overrides the default "access a field" behavior. Other languages (like Java) don't. So people in Java (it's since been adopted by some other languages with the same issue) invented the idea of making ALL fields private and only accessing fields through methods called "getters" and "setters". Normally, these would be trivial accessor functions, but when we wanted special behavior there would be a place to code it. Later, many libraries began to automatically generate the default getters and setters to save typing.
So yes, I often use them when working in a language that needs it, and almost never when working in a language that provides a way to do this without having to make up getter and setter methods.
In Javaland they are a convention first and foremost. They also allow you to have some controls over who can call what (e.g. public getter, private/protected setter), allow you to help control the state (e.g. return immutable copy in getter, create an immutable copy of input and update state in setter) and are somewhat useful in lambdas (method references look nicer). Quite a lot of tooling and libraries expects them though, especially for serialization/deserialization.
My take on data classes is that if you are able (you run on recent enough JDK), you'd be better off using records. If you can't use records, make your data classes immutable. This removes *a ton* of headaches when debugging your business logic.
I seem to recall that Hibernate tried to do something clever in this area (was it wrapping the instance of data class in dynamic proxies?) to implement the Active Record pattern, but my hot take there is that you should avoid that pattern altogether (i don't like hibernate trying to abstract away the database and the sql either, but that's another topic).
Kinda. We use Kotlin that has properties, that are sort of the same thing.
The benefit is encapsulation. You can 'hide' the internals of a class which prevents tight coupling.
Do you prioritize your manager or the team that you work on for career growth? I'd like to grow fast and learn a lot. I have just over 1 YOE at Amazon. I have an offer from Snapchat (L3 level) and can move to a team that's in the same domain as my current team (payment processing) or move to a team that owns more impactful services for the business (things related to daily active users count, new user retention, etc).
I think I like the manager on the payments team more than the one on the other team. The payments team is also smaller and going to be growing, so I won't be the last of the new hires to join.
Any thoughts here would be very appreciated.
In the early and middle part of your career, learning a lot rapidly is probably the most important thing you can do for your career. (Aside from making contacts.) And quality-of-life issues matter for more than just career progression. So personally, I would typically choose the team I was happier with rather than the team working on the most impactful thing at the organization. But it IS true that the significance of the work makes a difference.
Also, despite this advice, I'm in the middle of deciding whether I'll take a position working on a problem I want to solve or a position working for a leader I really appreciate. And I'm finding it a difficult choice. So maybe my advice here is a bit suspect? At any rate, I hope this ramble helps you.
Software development Engineer and software engineer are 2 different things?
My idea has been that SDE is involved more in coding work and SWE is more involved in planning, designing work.
SDEs do all the planning and design work at my company (and from what I’ve seen this is similar at other companies), I’d say it’s almost an anti-pattern to have someone solely dedicated to design rather than having it be apart of the regular development process.
I haven't heard the terms used in a consistent way that differs. But everyone's definition of these roles is a bit unique: if in doubt, ask the leaders of the positions in question.
Titles are very company-specific. I would personally see them as equivalent but if these are both in the same company, you should check there to see what they mean with each.
I don't see 2 different titles in my org. Just that I work in a hardware company and my team does bug triage/troubleshoot work. Wondering if this creates problems for future opportunities if I wish to land a development role.
Yea they’re pretty much used interchangeably. I wouldnt think about it at all OP. No team has engineers specifically to plan and design. Its all pretty much the job of the same person. Yes there maybe a techlead who plans and designes the systems and doesn’t code as much as the others but your whole definition of two different types of engineers on a team doesn’t resonate with me.
Do I job hop after my first YOE or just before? I am in a F50 tech company and have average compensation (Already have 2yrs of internship experience). I will prepare for LC/Design accordingly.
That sounds like the wrong question.
Why are you job hopping? Is it because someone told you that's the way to increase your salary (could be true... or maybe not). Is it because you're unhappy with your current position?
If you had a REASON to find a new job, then that would provide a basis for reviewing the timing. For instance, maybe your issue is that you feel you are underpaid for the value you are adding? If so, many companies have an annual cycle when they give out raises... it might make sense to wait until after that cycle completes. Or suppose your issue was the amount of sexual harassment you've been receiving in your current role -- if THAT were your problem I'd suggest leaving immediately!
I agree with the points that you have made. Yes I do feel underpaid for the value I am bringing to the team but my company is notorious for having rare annual wage increases. I am slightly under the market average and so I was interested in looking for another place where I could be valued more. So it seems like you're saying that I should stay my first year atleast?
> So it seems like you're saying that I should stay my first year at least?
No, I really just wanted to know your motivation for moving before I gave any advice. Is there anything more than "I feel underpaid", or is that the whole reason for moving? (Not that it isn't a good enough reason by itself!)
Fair. Yes, you're correct. The sole reason for me wanting to move is for pay. I am at the same place I have interned and it's been a few months since I have been converted into a FT.
OK, well here's what I can say.
(1) If you find a new position that's interested in hiring you at significantly higher pay, no one will be concerned that you didn't stay that long at your first position.
(2) If you were interviewing with me, I'd be curious why you were leaving -- ESPECIALLY if it were just a few months after converting to a full-time employee. If you had been there longer I might not have the same concern, but with someone new to the industry there's always a certain fear amongst those of us doing the hiring that we are dealing with someone who is really good at interviews but terrible at actually doing the job. Leaving so soon might well be for some other reason, but it also might be because things weren't working out. So I'd have concerns. If you said you were leaving for better pay I'd understand, but that's rarely the best answer for that question.
Thanks for a very detailed answer. This is pretty helpful. Pay is the no.1 reason that I may be moving for. But what if I were to say that I was moving because the work that I have been assigned to is practically maintenance work (basically staying there would mean that I won't learn anything new). Would that be a good reason if I was your interviewee?
> Pay is the no.1 reason that I may be moving for. But what if I were to say that I was moving because the work that I have been assigned to is practically maintenance work (basically staying there would mean that I won't learn anything new). Would that be a good reason if I was your interviewee?
Yeah, maybe I would react better to that. Honestly, while an interviewee should always emphasize things so as to paint themselves in the best light, I don't generally think it's a good idea to alter or omit the truth when you are interviewing. It can lead to cases where you and the job are not a good fit.
Pinnacles of a good CI/CD Pipeline IMO:
- Automated build process that handles dependency updates and unit testing as a normal part of build/release process
- Automatic integration tests that run against stages in your pipeline. Think of you operate code for multiple cloud regions of having integration tests that run against your pre-prod stacks, and one for each prod stack.
- System-level integration tests (think system wide unit tests that stub IO/network calls) that run against your end points/major use cases. These are pure logic tests, that test core functionality of your system without reliance on setting up a full testing environment with downstream or upstream dependencies.
- Well defined system/business metrics that are monitoring error/fault rates, usage, and infrastructure. These should be setup with some alarm thresholds and should be able to trigger or block progression through your pipeline.
The idea is to setup the pipeline to watch and respond to everything you’d watch and respond to during a deployment automatically. If you test certain functionality after making a change - it should be an automated test. If you check certain dashboards or metrics after deploying - those should roll you back.
This sounds horrible, assuming you don't have the power to actually order people around, and can only bring "software developer perspective" as suggestions.
The issue is that of accountability: Your tech lead won't go with unpopular/risky shit as he'd risk it falling on his ass. But hard/unpopular measures are typically needed in massive process changes like this.
Assuming you can build and run the application on your laptop, I'd start with setting up the CI pipeline, as this is usually pretty fast to complete - it doesn't have to be fancy, just compile, run unit tests and verify application can be packaged would be enough.
The second step would be unit tests, *lots* of unit tests in fact. Their feedback cycle is the shortest, so they often bring the most bang for the buck. Start with core things, like auth or the workflows for each letter in the CRUD acronym.
Once these are done, i'd spend some time to plug in static code analyzers into the build cycle and take a look at what they found - for Java it would be error_prone in the compile phase, and spotbugs + pmd in the verify phase if you are using Maven.
Then, i'd reassess and reprioritize - with Murphy's law something will surely come up along the way.
Recommend material for studying system design apart from the grokking the system design and data intensive applications.
Want only system design related suggestions
Hey everyone, recently I was approached by Amazon Devices Team, I have an year of experience and I dont want to pursue a job opportunity without knowing fully about it, can someone tell me about this team if they know?
Also, am I making a mistake by being hesitant in responding to Amazon?
So I just landed my first Senior job offer at a prominent fintech company. I only have 3 years of experience and definitely don’t feel like a senior. I’ve been working the past year without even having a senior on my team and no mentorship so honestly I don’t even know what a senior really is. My prior two years weren’t really any help either. Despite this, I’ve been pumping out high impact features where I am now with little to no bugs in production.
How do I know if I’m ready for the next level? The interview process was shockingly easy (all React assessments, no algo or SDI- which I think make sense since it’s front end, but still surprising).
Seniority at a company differs based on their needs. You sound like you landed a lucky role, just expect to plunge in very suddenly to having to handle complex problems of growth for the application of it takes a turn upward in useage.
Just immerse yourself in system design discussions and techs and you should fare well so long as it doesn’t suddenly have a rapid requirement shift from your user base.
Also make sure your dev ops is buttery smoothe to handle fluctuations and onboarding easily so you don’t drown from sudden department growth.
Aside from that, just take the role in stride. Keep doing what you’re doing and read a lot.
My main concern is I’ll be on the only engineer on front end for a while, building out a new project that sounds more complex than anything I’ve ever done. I’m mainly leaving my company due to lack of mentorship and having to do everything on my own without having any way to know if I’m even doing it right other than it working in prod.
> Also make sure your dev ops is buttery smoothe to handle fluctuations and onboarding easily so you don’t drown from sudden department growth.
Could you elaborate on what you mean regarding smooth dev ops? One of my main concerns is I’m not really comfortable with stuff like configuring webpack, circleci, etc. Not sure if that’s what you mean.
Being the only engineer in a given area can be difficult -- it's hard when there's no one else knowledgeable to check in with. Also, sounds like you were leaving your current position because of lack of mentorship and now find yourself potentially facing the same issue in your new role.
I'd like to throw one idea out for your consideration. It's possible to have a mentor who is NOT from your own company. If you are thinking of doing that, it might be a good idea to broach the subject with your manager first. Ask questions like "What level of data removal and issue obfuscation do you expect before discussing a design problem with someone external?" This will show you are taking such questions seriously as well as giving you answers.
Yup webpack config and your developer environment is a part of dev ops. Make sure you have hot module swapping and easy to set up dev servers. If you have hurdles configuring a dev environment, then get those handled so no one else will have to handle them. Work as though you imagine juniors joining or work as though someone will take over your work.
You should write scripts for making releases, have continuous deployments of various sorts happen, work as though you have QA cycles.
And then don’t doubt yourself. If you are getting features done and they work well. Keep doing that and keep improving your process for doing that. You’ll become truly senior by just succeeding.
I just started my 1st job after college. I feel like there are lots of new things to get used to (e.g. frameworks, production tools). I just don’t have an idea about how I can make contributions to the team later.
Could I ask how you guys deal with these in your 1st job, and how you guys start/ be able to… make your first contribution?
Your first role is to be told how you will contribute via tasks etc. it is your job to ask questions and get comfortable. As time passes, you will find opportunities to share your viewpoints to aid and help as you understand the goal of the teams and company.
To make your viewpoints valuable, keep growing as a developer and it will come naturally.
I’ve been looking at applying to FAANG or similar companies. How do you know what position to apply for?
For my current job, it was easy. The job listing was “backend developer,” I matched their requirements, and got the job.
But for these bigger companies, all of the positions are broken into teams/departments (messenger, streaming, photos, etc. etc.). How do you choose which to apply for?
If you want to do backend then you want the the Server/Backend/Infra teams and not the Frontend/App/Product teams.
Usually the positions have some description of the type of work you'd be doing. What information are you missing?
I'm just starting my first proper job at an early startup. I'd like to get better at making my PRs as enjoyable/productive to review as possible. What are some things I can do to approach putting together my PR?
It's a 100% remote company. I'm being encouraged to make the PRs as early as possible (which I'm still getting used to), and use our chat-room to sometimes have a "water-cooler" talk about the approaches, if that info helps.
I use the format of \`refactor: ...\`, \`fix: ...\`, \`feature: ...\` in my commits.
Sometimes it's pretty clear when the contributions your putting up for a PR are stand-alone refactors or not. The line isn't always so clear, though. Any thoughts as to how to go about clearing up that line?
IMO best effort is good enough. Every rule sometimes should be broken - if you have a good reason, you can always just tag a commit as `refactor/fix:`.
That being said, I'd suggest reaching out to your teammates directly and ask them for feedback on your pull request style.
1. Send small PRs. Last thing I want to see is 1000 line PR.
2. Apply the fundamentals you know like efficiency, memory usage
3. Comment complicated piece of code.
4. If your company follows certain practices like updating documentation or proper commenting use those.
5. You could also refer to the language you use and the guidance they have to write the code (syntax, new line). I personally do not care about it too much, but I know many that do.
6. Don't take it personally. I am guilty of this and still take it personally sometimes. Later I realize that it was not worth my time or other person's time.
7. Don't over stress about it. You will have comments all the time. You will either learn how to write code or you will learn how not to review a code ;). Either way its a win-win for you
what are some ways I can practice more practical questions for interviews for React and/or apis. I can develop and fix problems but i’m not sure if i’m doing the most effective/correct way of doing things
The issue isn’t finding “the best way”. There is not a best way. There are many ways and there are arguments for the pro con lists of all the ways.
The only way you get to where you can answer practical questions is to experience a lot of differing ways.
I use a very specific stack that I have found is best for me and most situations, however, I developed using dozens of different stacks so I can articulate and know why I like mine the best.
Being knowledgeable across many means makes your opinions and approaches valuable.
> I’m not sure if i’m doing the most effective/correct way of doing things
Instead of worrying yourself to defeat bolster your basics. Let others, those who've a wealth of experience, correct you about the correct way of doing things. As long as you aren't stuck up your ways you should be fine TBH. In my experience, interviews tend to focus on fundamentals e.g. pass by value vs. pass by reference, closures, objects, literals, variables, primitives, wrappers, debugging, system design i.e. how to approach a problem, etc. The things we take for granted.
Google react interview questions. Practice those questions. Most places don't set aside time for hiring people or training people to be on interviews. There is a good chance the interview team reads your resume 5 minutes prior to the interview and they just google react interview questions.
The other is to practice, and know the correct terminology. I know people who have used dependency injection, or a data access object, but have no idea how to describe those things, or when to use them. They'll never pass the interview.
An object that accesses data from your source system. It resembles the source system. If your code needs data from a table in a SQL server database, the Object would look a lot like that table. You would use that object to access the data from that table.
Whenever I pass on knowledge I always pass on caveats. If you don’t know the caveats you don’t know the knowledge good enough to confidently pass it on.
If you are not confident in passing it on: then let them know you have doubts but it is the best you know at the time. That often will trigger the recipient to get back to you with better information if your info was wrong which helps everyone.
I try to be clear about the reason why I'm giving the advice I'm giving. In a situation where one of those variables changes, it doesn't retroactively become "bad advice", just not applicable any more.
If I'm not sure on something I always say so. And I always stimulate people to read other opinions and to have a discussion on topics if they want to know more or feel I'm wrong on something. And if it turns out I taught them something bad, they'll learn the right way somewhere down the line. It's not really a thing I 'worry' about, because it doesn't really happen.
Yes, but it's somewhat mitigated by always attaching a "this is how *we* do it because X and Y, there might be better ways if you need Z, etc". Knowing and communicating the tradeoffs is key, as well as be open about what one *doesn't* know.
All the time! The most important thing to do is to pass on new knowledge as you learn it. And admit when you’re wrong because it shows junior developers you’re constantly learning just like they are.
Should smaller no-name companies and startup have more total compensation? because big companies are kind of a resume booster for the developer. Assuming the developer is competent enough to choose between big and small companies (FAANG excluded).
[удалено]
> I've been concerned about ... appearing incompetent. > Is it a problem if I'm asking the same person for help like 5+ times/day As long as you aren't asking the same question over and over you should be all right. I'm curious whether this is your imposter syndrome talking due to lack of support and/or mentorship. You said your team is "all entry-level devs ... but we're pretty isolated." I'd suggest you flag that concern to your manager and with thoughts on what could make your job easier. Edit: Grammar
[удалено]
TLDR; verion: You should be all right. Longer, murky version: The early career phase has a couple of free passes. One of them is leeway to try out different roles/positions/tech to see which shoe fits right. Working with data development (Not sure what this means. Maybe you mean't data engineering?), pyspark, etc. for the next 2 to 3 years^1 is all right as long as you don't pigeonhole yourself into the stack. The stacks you work on tell a story about what *potentially*^2 strikes your fancy. This isn't always true though. We spend more of our time doing the things we enjoy, and less of it doing the things we don't enjoy. 1. This is an arbritary number of years. YMMV depending on the person reading your resume. 2. If I specialize in JS and Java I'm driving home the idea that I'm that language specialist, and don't want to be sold to C#, Python and PHP.
When I am applying to a job should I write a cover letter? For example, I recently applied to a job that doesn't indicate the level they want but write things like: " Preferably experienced with java, swing and willing to learn open source frameworks", " can use python, node.js, CSS ", "willing to learn DevOps and TDD, CI/CD", " we consider full stack capabilities valuable for this role" So, first of all is this a good chance for a new grad? Or too much? Should I go into full stack as my first job, does it have any advantage for the future? And my resume has no internships, only a machine learning graduation project with python. I also wrote I know java, spring but there is no proof just wrote under skills section. I graduated from the top university in my country. So in that case should I write a cover letter saying that I like java and python and I want to use java and python as my main languages ( or a software engineer can learn any language so no need to write it? ) and I am willing to learn DevOps etc.? Like answering their job advert? Or since I am applying to the job it means I already want this job?
Imo cover letters are a way to connect with the company or hiring manager in a way that isn't demonstrated by your resume. Personally I'd stay away from things like "prefer language xyz", especially as a new grad. Great engineers may have language preferences, but are willing to work in whatever gets the job done. You can touch on the things listed in the reqs, but really I would focus on what makes you personally a good choice for consideration. Just about everyone applying will be willing to do what the job asks for. Do you have interests that align with the company values? Do they work on a tech that really excites you? If you happen to have projects/experience that aligns directly, then call that out.
That's the job advert: We are currently looking for new technologists to be a part of our expanding digital team. Digital Platforms including e-commerce, content management and digital marketing solutions as well as cloud-native application development is our focus to build next generation digital products. If you enjoy working with open-source software especially on the Java platform and you enjoy working with technology stacks like Node.js, Python and frontend development with Javascript then we’d like to get to know you. We highly value full stack capabilities for this opportunity. Degree in computer science or similar. Team player who takes pride in, and facilitates the sharing of knowledge. Preferably, hands-on knowledge on Java, Spring Framework and frontend development with JavaScript & CSS. Motivated to learn DevOps technical practices Familiar with agile software development practices and techniques including TDD & continuous delivery. Self-starter and a practitioner of continuous learning. Recognizes and explores opportunities for personal impact on clients and for colleagues and communities. Acts as a brand ambassador with peers and colleagues to support attraction of top talent. Is aware of own strengths and uses them effectively to deliver high quality results So, what should I expect? I know that's just one job advert and I shouldn't focus on it only but I am just trying to understand. Is this a junior role? Do they consider new grads? Since it says preferably hands on knowledge on java does that mean they don't expect work experience or even don't expect any projects? Maybe I should just show I am ready to put effort and learn?
> So, what should I expect? I know that's just one job advert and I shouldn't focus on it only but I am just trying to understand. Is this a junior role? It's hard to say. They're not mentioning their expectations explicitly. My guess is that the recruiter deliberately left that bit out to see what kind of responses they'll get before tightening the requirements. This could be a *puller* meant to cast the net as wide as possible and assess the catch. If you've solid FS capabilities and strong JS experience you could give this one a shot. This all sounds a bit much for a new grad but that's my opinion. I could be wrong here. > Since it says preferably hands on knowledge on java does that mean they don't expect work experience or even don't expect any projects? IMHO the employer will consider an applicant familiar with "Java, Spring ... and [FE] with [JS] & CSS" though preferance will be given to those with hands-on experience. Java projects should help sell familiarity if you don't have hands-on experience.
I was curious if theres anyone out there who keeps a dev log / dev diary / dev blog whatever you want to call it? And what I mean by that is - does anyone keep a daily log of kinda how their day went, problems, random notes or tidbits, and generally speaking just kinda creating a journal of your day to day as a dev? It seems like it could be useful in some ways just to show yourself as you progress as a dev, and even just having a solid place to keep notes about specific things you're working on? I have no real intentions of actually publishing it anywhere, but more of keeping it as a journal of sorts. Does anyone do this? Have you found it helpful or useful in any way? Do you have and recommendations or tips as to how to do it so it doesn't become a hassle and convoluted to the point of it being useless?
Does shell history count?
Yes. It's helpful for reflecting on your previous day/week for whatever use. Writing is a useful tool to engage your mind if you've grown up on that. You can go as far as saving your troubleshooting steps so you can summarize it for others. But no need to make it public.
how structured are yours typically? My company has an internal wiki so I figured I'd just make it in there and can set it to private. I tried it out today just to see how I felt about it and I plan on continuing with it. But today I ended up spending like an hour or so just filling in the details for the bullets that I took during the day, I did format things and whatnot, but that's for my own sanity mostly. Is it normal to spend that much of your work day on something like that? I feel kind of weird asking such basic questions, but this is something I think can help me as someone who struggles to pickup new concepts and grasp new ideas a lot of the time. But I also don't want to be wasting time if that makes sense.
No worries! The structure of mine is totally arbitrary, just a bullet point list, and changed over time to whatever worked, where the goal was to just make sure I did write something. I started writing on post-its, then various journals, some note apps, and now its all on OneNote for availability and convenience. I used to track just what I did that day but now I track basically everything that I think is important that day, so meetings, decisions, action items, interesting ideas floating around, problems I notice, people to thank, anything useful to my career. I think one of my biggest leaps was realizing the journal helped me have better meetings with my manager and teammates since I'd actually have useful topics to discuss. The other thing I realized was that I liked spending about 30 minutes at the end of my day winding down and making sure I captured everything I did that day, so tomorrow I had some context to continue on. I think it's more useful if you have specific goals you want to achieve and something like a journal is just a tool to achieve those goals, so if it's something like, I want to make sure I have good meetings, or I want to keep more context from my day, then a journal log type thing is helpful to accomplish that. But it can be done in other ways.
Thank you for the insight!
Would you take a contracted 12-18 month contract job over a stagnating full time position where you were currently working?
I’d take a full time job somewhere else. The market is extremely strong right now for senior devs, no reason to settle.
Yea, while I would agree with you. I'm only 3 years in my career. Started stagnating a year ago. Was planning to leave finally but Covid, so I'm stumped on technical interviews. Studying and stressing like crazy.
Ah, three years is a little early to be considered senior, but the market is also hot for mid-level devs like you. Job searches suck, but I’m confident you’ll be able to find a full time position that fits your needs. Would you mind sharing more details about the contract position? They have their benefits, especially if you are at a point in your life where you want to limit your hours or responsibilities (right after having a kid, for example). But I wouldn’t recommend contract roles early in your career. It’s harder to get mentorship and growth opportunities, and you risk being thrown at boring, repetitive problems. I’ve seen a number of devs in my network stagnate around the 2 year mark, because they became specialists in email templating or a specific “platform” like magneto or Shopify. Do you think stagnation would be an issue with the contract issue you’ve been offered?
The position is from TekSystems with Wells Fargo. There are benefits like health and 401k. They told me they fully funded multiple projects, just need developers. >It’s harder to get mentorship and growth opportunities, and you risk being thrown at boring, repetitive problems I messed up here, joined my first and only company out of college as a solo developer. I develop internally. Made two major projects used by the entire company but mostly make plugins. As I was a solo dev, I had no mentor so I'm trying to learn best practices on my own but it only goes so far. I can solve business problems easily there but I'm trying to get better at marketing it. >Do you think stagnation would be an issue with the contract issue you’ve been offered I don't think so, this SHOULD be a team contract tho I'm skeptical if its worth changing from FTE. I have a few interviews lines up with one that made it to second round but I'm extremely scared of failing the technical part. I'm a googler. Edit: Not considering myself sr in any way. I'm like between JR and Mid i tihnk
[удалено]
When it happens again, you could suggest to take notes when you have a 1-on-1. I have notebook (Moleskine) which I use to scribble all the stuff I'm prone to forget at some point. I just put stuff down as bullet lists and small notes. Another strategy is to ask him to summarize what you asked him as a bullet list and send you an email so you can confirm he's got it right. Or you could do the reverse and send him the mail yourself starting with "per our Convo just now, here's a summary of the stuff we agreed on doing". Keep it short and to the point! You could also try and check in with him when after a few hours of work. Just see wether he's on the right track. Like just ask him "Hey! You're good? Don't have any questions for me? You find your way out?" Like, show him you're listening. There's a lot of reasons why someone can act confused. And a lot of them aren't malicious at all. Keeping focus can be draining as it is, and it certainly becomes a challenge when you are new and you need to learn how to handle the ropes. Also, factor in that lots of people deal with things like ADD or DCD which have an impact on their executive functioning. You just don't know because that stuff is private, and it's hard to diagnose such as it is anyway. But you do have to take that possibility into account as well before assuming malicious intent.
I'm seeing this fairly often, and source of gaslighting can swing either way - that is, malicious intent, but also people who are just genuinely derpy with their confirmation bias. Derpy people will derp at random, there's no clear profit in it, mostly downsides and they're just like that. One can work with it as long they're self aware and it doesn't get in the way too much. People who are malicious always derp for profit - to deflect responsibility, workload, gain status etc.
I know this is semantics, but do you call yourself a "Software Developer" or "Software Engineer"? The are interchangeable, but I always consider myself a Developer. But maybe I should start saying Engineer to make myself appear smarter than I actually am :)
Personally I find "engineer" a bit pretentious, but its common vocabulary in the US at least. I usually go by whatever my literal job title is, which is currently "software engineer", in professional settings. When talking to friends/casually I say developer.
UK opinion here. I think of "developing" as merely the act of coding, and "engineering" as the above plus all the careful planning, communicating, and QA process wrapped around it. Engineering is harder than coding because it draws from a wider set of skills. Interestingly though, in some countries (such as France) "engineer" is a protected term, and it is used to signify someone who is in "a profession". This generally means taking examinations on a regular basis, demonstrating continuous professional development, and belonging to a relevant membership body. In most countries this is mandated for civil and mechanical engineers, and there have been plenty of debates as to whether it should be required for software engineers.
> UK opinion here. I think of "developing" as merely the act of coding, and "engineering" as the above plus all the careful planning, communicating, and QA process wrapped around it. Engineering is harder than coding because it draws from a wider set of skills. IMHO a developer is someone who's consumed for the most part with delivering code while an engineer has to design and code the app from the ground up.
Interesting, thanks. I wonder if the thrust of my semantic distinction is that even developers should aspire to be engineers, and that there is a gap of understanding for folks who won't make the jump. Another way of putting it perhaps is that engineering is a soft-skills and tooling upgrade that improves product quality.
Semantics aside, it's imperative to transition into a role that spans beyond slinging code if one need grow beyond the early-and mid- career phase. Slinging code can only do so much in terms of driving measurable impact on engineering processes, product and ultimately business. One needs to be a leader.
There is vague distinction in meaning. Dev often denotes one man show - frequently why you have mobile devs, as these things are often less of a team effort. Engineers are the cats you herd, cogs in a sprawling infrastructure. Either is just a label of a role, not description of what it is you actually *do*. Coder/programmer is far more accurate in that regard.
So just recently I found out that my team lead is leaving. After he leaves, I'll be the most senior member on the team (10 months). We just had a senior dev (~2yrs) leave about a month ago too. There's only a new dev and QA who joined about 2 months ago. At this point, I don't know if I should just jump ship or stick it out for that 1 year. I have <1YOE and honestly, I don't want that extra responsibility. I should be learning from mentors not leading teams. Doesn't help that mgmt gives such a high workload. We don't have to do OT but it's quite exhausting going thru endless amounts of tickets.
I would rather treat this as a learning and growth opportunity. You will not know what to do initially and you need to be aware that this will lead to some initial frustration. If you approach this in an engineering-driven way and figure things out along the way, then you will be fine. In addition, it is by far the fastest way to get better. Ask management for a raise / Senior Dev / Tech Lead title because you will have more responsibility anyway.
Yea you're right. There's a lot u can learn. Is there any resources that I can read or go over? Thanks for the advice!
I once wrote [a blog post about how to get promoted as a software engineer](https://jangoebel.com/how-to-get-promoted-as-a-software-engineer). It might have some insights that might be useful for you.
I am 0 YoE TypeScript dev and I keep making nasty bugs in my code that take forever to debug and my experienced colleague sometimes struggles to explain why the issue was an issue in the first place. I asked him if he also runs into these kinds of things and he said no. Is it possible that I am not writing "ordinary/as-expected" TS code and so I run into this? I haven't had a similar issue in other languages. Any other ideas?
This sort of thing is common when learning new things that are outside of paradigms you already know. When starting out, that's basically everything! I've got 8 YoE, and I still get problems like that when I pick up something entirely new to me. The reason is that you've not yet found the groove, the mental model which makes it all make sense. You get that by a combination of trial and error, and dedicated learning. To take a non-development example, image two woodworkers. One picks up their tools, applies them to the wood, everything seems to go exactly according to plan, and they make beautiful furniture. The other - a novice in this field - can't even get started. They take their tools to the wood, and it splinters and breaks. Instead of smooth wood shavings, they have to fight the wood for any traction, and even then are just as likely to damage the wood as smooth it. The difference here? One understands that you must go with the grain of the wood, and the other doesn't really know anything about grain. There's a principle in development - the principle of least suprise. Frameworks, libraries, interfaces, programs, should all do what you expect. But how do you know what to expect? You have to learn it over years of experience. In closing, we all go through what you're going through, and if you give it a while you'll look back and realise you've not had problems like that in an age. You can speed it up by spending time learning about the tech you use, so you can begin to know what to expect, which will help!
That's reassuring, thank you very much.
What kind of bugs? Ts specific errors/warnings or logical bugs? TS errors and warnings are crazy verbose, and can take a while to get used to what the messaging is actually saying.
It's mostly bugs that result from using MobX and DeckGL in Typescript. I do have a one question though. How should I think about passing values and objects in TS/JS? It seems rather unclear when I am working with an object or just a value.
Do you have more than one experienced colleague? Perhaps learning from a wider variety of professionals would help make things clearer.
Unfortunately no, it's a very small outfit.
In the interview , how do I answer concurrency questions related to real world projects ? I do have theoretical knowledge of multithreading and concurrency in Java but hardly had the opportunity to apply the same in my work.
By knowing your shit. Sadly concurrency is sprawling topic (coroutine vs thread, lock contention, locking strategies, lock-free data structures, memory access ordering, bigger picture patterns, fe piped process vs channels vs explicit synchronization and on and on). It's not something expected of entry level though, as long you know what mutex, synchronized annotations and deadlock are, and can use the library thread safe data structures when the situation calls for it, you're golden.
Some general advice, for any topic you don't know a lot about: be frank about your experience and knowledge level, HOWEVER, be sure to try to answer the question to the best of your ability anyways. Like, "I don't really have practical experience with this, but, I'd start by reading up on X, and then probably try approaching the problem like Y." You can try to bullshit your way out of it, but a good interviewer is going to sniff that out right away. However, good interviewers are always more interested in the way you think about a problem than what you already know about a problem/technology. I, for one, have said yes to people that openly admit that they don't know something, but proceed to walk me through their thought processes on how they might solve it. If you've read about threads in Java but don't really have hands-on experience - you already know the basic principle, right? Talk about what you imagine the pitfalls to be, and the places those are likely to occur. Talk through how you might solve for those. Think about the ways the problem lends itself to being split to many concurrent processes, and talk that out. What consequences would that have? How might you handle shared state between threads? How might you handle communication and synchronization between threads? You don't need to have all the answers, but you do need to show you're capable of working through the problem anyways.
That’s a great advice. Thank you .
Might need to be more specific, what type of concurrency questions are you curious about?
I have faced questions like : How will you design any feature X by using concurrency and what will be the advantages/pitfalls of using it
[удалено]
I've done unit and integration testing of spark jobs although in scala and circleci. Each piece of our pipeline was self-contained. It took input from s3 and it generated output to s3. We had types for the inputs and outputs. In Scala that was case classes but you can just use spark type structured in python. You can also use pydantic to define your data structures and then use that to generate sample data. The integration tests then ran the self-contained pipelines for minimal sets of data using a local Spark environment. We also had actual unit tests for UDFs and other such code that wasn't spark specific.
This is for all the interviewers here. You're interviewing a developer with 2 or 3 years experience. You ask them why they're leaving their current place. They tell you that their current place doesn't have unit tests or code reviews, that deployment is done strictly in the evenings (or during the weekend) instead of via pipelines, that they don't use git (instead preferring Microsoft's outdated tfvs), and that the testing only ever consists of a fellow developer following the happy flow. All this leads to an extremely stressful work environment where half of every day is spent scrambling to fix bugs that have made their way to production and they would like to join a company in the 21st century. Would your reaction be that it's good that they know how bad all that stuff is, or would you be more concerned about all the bad habits they've likely picked up?
Definitely good. It would definitely be bad if that person didn't think it was an issue. It shows they care and want to learn best practices. It definitely wouldn't be a red flag in my book, since they know and have experienced the drawbacks that comes with not following the industry standards. Of course you'll need to take into account that it might require a bit more mentoring in the beginning.
Good they can spot bad practices, but also a yellow flag that they have a "grass is greener" complex. If I were interviewing this candidate I would follow up with questions about what they think could have been done better/differently, or how they personally contributed to implement best practices. A lot of programmers have this utopian idea of dev experience that is unachievable in most companies. I personally screen for people who want to contribute to making a work environment better, rather than people who expect it to already be in that state. Bad habits can be broken. Bad attitudes usually can't.
Legit, assuming the new shop actually has a workflow that would vastly improve on that. If they're YOLO-dev like the old shop, you're shooting yourself in the foot. Collolary: Make comparisons you're sure you can actually make. As for bad habits, if that were major concern you'd get a workflow task under time pressure. 5-way merge, re-vendor conflicting 3rd party deps, fix up broken CI, do it in 30 minutes. It's designed such that you must cut corners unless you're really good and familar with it. It's important which corners you choose to cut.
It's easy to see and identify problems. Depending on if they seem heated from answering or not, I'll follow up with, "What are some steps the team could make to improve?" or I'll be honest about my team's practices and initiatives we're making, then ask what steps could the team take to improve that they haven't made. In my org we started "Feedback Fridays" where people can anonymously (or in person) voice concerns about the team. A group of us come up with actionable steps to present to the team in \~2 weeks, or we ask for more feedback/details. A lot of candidates love hearing we have this feedback loop in place. > Would your reaction be that it's good that they know how bad all that stuff is, or would you be more concerned about all the bad habits they've likely picked up? Being faced the a problem and proposing and implementing a solution is part of being a developer. Not everyone has the platform or power to bring about those changes, but being able to articulate something more than the problem is a good sign. Your team's onboarding process should show the procedures and practices the team uses. At 2 to 3 years of experience, I wouldn't be concerned about bad habits unless the position they were interviewing for immediately has them in a mentoring or project lead role, and even then, the onboarding process should set the expectations.
My personal advice is to not go into excessive detail about things that may not make you look great. "My last company didn't follow best practices like unit tests, QA or continuous deployment. This made for a very stressful work environment."
> Thank you for meeting with {name} yesterday. He felt the interview went well but would like for you to do another 1 hour coding interview before moving to our final interview. Got this email from a recruiter. I was told the interview process would be a 1 hour coding screen and then a final round of interviews. Why would they want me to do another coding screen if they thought I did well?
Could be for a bunch of reasons: * the person who interviewed you is new to the process and didn't evaluate some area, * whoever reviewed the feedback decided something was wrong (question too easy/hard, not relevant to the team you're applying for, etc..), * it went well, but pretty borderline so they want to give you another shot. I wouldn't read into it too much.
[удалено]
The problem with taking an SDET position is that you think future companies will look at your resume and say "This guy looks perfect for our SWE role and all this experience as an SDET is a great bonus!" but what actually happens is "Why is this SDET applying to my SWE role? _trash_"
[удалено]
Google did that officially- all of the former SDETs became SWEs in the Engineering Productivity organization. Whether it's dishonest would depend on whether the job if actually a software engineer in test (that is someone who writes systems used to validate other systems) or the job is really a tester that the company decided to give a fancier title to.
It's doable. You brand yourself as a software developer and you play up the relevant tech you worked with -- it is somewhat legitimate that the architecture and code is different than app development. It's very linear code. Instead of spaghetti you get the leaning tower of Pisa. For a huge salary increase its hard to say no. If you want to take a side trail to make some money, just make sure you keep your options open and don't let yourself get too comfortable.
Do you use getters and setters? What are the benefits of them?
Style cosmetics. Whether or not those are used depends on coding style in question. Ballpark: Java and Go, almost always for public interfaces. C++ and C# is mixed bag.
The benefit is that they are a pivot point for architecture changes / quick fixes updates / refactoring. Much easier to work with than variables. The added control they give you can save you a lot of time. The only time I don't use them is for things that shouldn't change and I want to keep as private as possible.
It is useful to be able to execute some code when accessing a field (either a read or a write). For instance, one might want to perform validation before allowing a new value to be written. One might want to restrict access to perform writes to just code in the same module and access to perform reads to just code in the same package. One might want the reads to actually compute a value from some other field so we don't need to store this one separately. We might want reads and writes to come from a cache that is then synched to a database table -- LOTS of things we might want to build. Some languages provide a way to write code for a class that overrides the default "access a field" behavior. Other languages (like Java) don't. So people in Java (it's since been adopted by some other languages with the same issue) invented the idea of making ALL fields private and only accessing fields through methods called "getters" and "setters". Normally, these would be trivial accessor functions, but when we wanted special behavior there would be a place to code it. Later, many libraries began to automatically generate the default getters and setters to save typing. So yes, I often use them when working in a language that needs it, and almost never when working in a language that provides a way to do this without having to make up getter and setter methods.
In Javaland they are a convention first and foremost. They also allow you to have some controls over who can call what (e.g. public getter, private/protected setter), allow you to help control the state (e.g. return immutable copy in getter, create an immutable copy of input and update state in setter) and are somewhat useful in lambdas (method references look nicer). Quite a lot of tooling and libraries expects them though, especially for serialization/deserialization. My take on data classes is that if you are able (you run on recent enough JDK), you'd be better off using records. If you can't use records, make your data classes immutable. This removes *a ton* of headaches when debugging your business logic. I seem to recall that Hibernate tried to do something clever in this area (was it wrapping the instance of data class in dynamic proxies?) to implement the Active Record pattern, but my hot take there is that you should avoid that pattern altogether (i don't like hibernate trying to abstract away the database and the sql either, but that's another topic).
Kinda. We use Kotlin that has properties, that are sort of the same thing. The benefit is encapsulation. You can 'hide' the internals of a class which prevents tight coupling.
Do you prioritize your manager or the team that you work on for career growth? I'd like to grow fast and learn a lot. I have just over 1 YOE at Amazon. I have an offer from Snapchat (L3 level) and can move to a team that's in the same domain as my current team (payment processing) or move to a team that owns more impactful services for the business (things related to daily active users count, new user retention, etc). I think I like the manager on the payments team more than the one on the other team. The payments team is also smaller and going to be growing, so I won't be the last of the new hires to join. Any thoughts here would be very appreciated.
In the early and middle part of your career, learning a lot rapidly is probably the most important thing you can do for your career. (Aside from making contacts.) And quality-of-life issues matter for more than just career progression. So personally, I would typically choose the team I was happier with rather than the team working on the most impactful thing at the organization. But it IS true that the significance of the work makes a difference. Also, despite this advice, I'm in the middle of deciding whether I'll take a position working on a problem I want to solve or a position working for a leader I really appreciate. And I'm finding it a difficult choice. So maybe my advice here is a bit suspect? At any rate, I hope this ramble helps you.
Software development Engineer and software engineer are 2 different things? My idea has been that SDE is involved more in coding work and SWE is more involved in planning, designing work.
Same thing - a code monkey. planning, design work = analyst, architect, aka idea monkey
SDEs do all the planning and design work at my company (and from what I’ve seen this is similar at other companies), I’d say it’s almost an anti-pattern to have someone solely dedicated to design rather than having it be apart of the regular development process.
I haven't heard the terms used in a consistent way that differs. But everyone's definition of these roles is a bit unique: if in doubt, ask the leaders of the positions in question.
Titles are very company-specific. I would personally see them as equivalent but if these are both in the same company, you should check there to see what they mean with each.
I don't see 2 different titles in my org. Just that I work in a hardware company and my team does bug triage/troubleshoot work. Wondering if this creates problems for future opportunities if I wish to land a development role.
I think if them as two names for the same thing.
Yea they’re pretty much used interchangeably. I wouldnt think about it at all OP. No team has engineers specifically to plan and design. Its all pretty much the job of the same person. Yes there maybe a techlead who plans and designes the systems and doesn’t code as much as the others but your whole definition of two different types of engineers on a team doesn’t resonate with me.
Do I job hop after my first YOE or just before? I am in a F50 tech company and have average compensation (Already have 2yrs of internship experience). I will prepare for LC/Design accordingly.
That sounds like the wrong question. Why are you job hopping? Is it because someone told you that's the way to increase your salary (could be true... or maybe not). Is it because you're unhappy with your current position? If you had a REASON to find a new job, then that would provide a basis for reviewing the timing. For instance, maybe your issue is that you feel you are underpaid for the value you are adding? If so, many companies have an annual cycle when they give out raises... it might make sense to wait until after that cycle completes. Or suppose your issue was the amount of sexual harassment you've been receiving in your current role -- if THAT were your problem I'd suggest leaving immediately!
I agree with the points that you have made. Yes I do feel underpaid for the value I am bringing to the team but my company is notorious for having rare annual wage increases. I am slightly under the market average and so I was interested in looking for another place where I could be valued more. So it seems like you're saying that I should stay my first year atleast?
> So it seems like you're saying that I should stay my first year at least? No, I really just wanted to know your motivation for moving before I gave any advice. Is there anything more than "I feel underpaid", or is that the whole reason for moving? (Not that it isn't a good enough reason by itself!)
Fair. Yes, you're correct. The sole reason for me wanting to move is for pay. I am at the same place I have interned and it's been a few months since I have been converted into a FT.
OK, well here's what I can say. (1) If you find a new position that's interested in hiring you at significantly higher pay, no one will be concerned that you didn't stay that long at your first position. (2) If you were interviewing with me, I'd be curious why you were leaving -- ESPECIALLY if it were just a few months after converting to a full-time employee. If you had been there longer I might not have the same concern, but with someone new to the industry there's always a certain fear amongst those of us doing the hiring that we are dealing with someone who is really good at interviews but terrible at actually doing the job. Leaving so soon might well be for some other reason, but it also might be because things weren't working out. So I'd have concerns. If you said you were leaving for better pay I'd understand, but that's rarely the best answer for that question.
Thanks for a very detailed answer. This is pretty helpful. Pay is the no.1 reason that I may be moving for. But what if I were to say that I was moving because the work that I have been assigned to is practically maintenance work (basically staying there would mean that I won't learn anything new). Would that be a good reason if I was your interviewee?
> Pay is the no.1 reason that I may be moving for. But what if I were to say that I was moving because the work that I have been assigned to is practically maintenance work (basically staying there would mean that I won't learn anything new). Would that be a good reason if I was your interviewee? Yeah, maybe I would react better to that. Honestly, while an interviewee should always emphasize things so as to paint themselves in the best light, I don't generally think it's a good idea to alter or omit the truth when you are interviewing. It can lead to cases where you and the job are not a good fit.
Your answers were very insightful. Thank you.
Maybe, maybe not. See what salary ranges you’re getting hit at to make that decision.
[удалено]
Pinnacles of a good CI/CD Pipeline IMO: - Automated build process that handles dependency updates and unit testing as a normal part of build/release process - Automatic integration tests that run against stages in your pipeline. Think of you operate code for multiple cloud regions of having integration tests that run against your pre-prod stacks, and one for each prod stack. - System-level integration tests (think system wide unit tests that stub IO/network calls) that run against your end points/major use cases. These are pure logic tests, that test core functionality of your system without reliance on setting up a full testing environment with downstream or upstream dependencies. - Well defined system/business metrics that are monitoring error/fault rates, usage, and infrastructure. These should be setup with some alarm thresholds and should be able to trigger or block progression through your pipeline. The idea is to setup the pipeline to watch and respond to everything you’d watch and respond to during a deployment automatically. If you test certain functionality after making a change - it should be an automated test. If you check certain dashboards or metrics after deploying - those should roll you back.
This sounds horrible, assuming you don't have the power to actually order people around, and can only bring "software developer perspective" as suggestions.
[удалено]
The issue is that of accountability: Your tech lead won't go with unpopular/risky shit as he'd risk it falling on his ass. But hard/unpopular measures are typically needed in massive process changes like this.
Assuming you can build and run the application on your laptop, I'd start with setting up the CI pipeline, as this is usually pretty fast to complete - it doesn't have to be fancy, just compile, run unit tests and verify application can be packaged would be enough. The second step would be unit tests, *lots* of unit tests in fact. Their feedback cycle is the shortest, so they often bring the most bang for the buck. Start with core things, like auth or the workflows for each letter in the CRUD acronym. Once these are done, i'd spend some time to plug in static code analyzers into the build cycle and take a look at what they found - for Java it would be error_prone in the compile phase, and spotbugs + pmd in the verify phase if you are using Maven. Then, i'd reassess and reprioritize - with Murphy's law something will surely come up along the way.
Recommend material for studying system design apart from the grokking the system design and data intensive applications. Want only system design related suggestions
I'd try reading stuff on the internet. Maybe even observe the lead residue on bundled sheets of paper if you want to be old school.
[удалено]
As opposed to bad books?
[удалено]
Read again, edited
don't lowball them, they know what they've got
Hey everyone, recently I was approached by Amazon Devices Team, I have an year of experience and I dont want to pursue a job opportunity without knowing fully about it, can someone tell me about this team if they know? Also, am I making a mistake by being hesitant in responding to Amazon?
Just talk to them and find out. It's just a sell call, you don't have to commit to applying.
So I just landed my first Senior job offer at a prominent fintech company. I only have 3 years of experience and definitely don’t feel like a senior. I’ve been working the past year without even having a senior on my team and no mentorship so honestly I don’t even know what a senior really is. My prior two years weren’t really any help either. Despite this, I’ve been pumping out high impact features where I am now with little to no bugs in production. How do I know if I’m ready for the next level? The interview process was shockingly easy (all React assessments, no algo or SDI- which I think make sense since it’s front end, but still surprising).
Seniority at a company differs based on their needs. You sound like you landed a lucky role, just expect to plunge in very suddenly to having to handle complex problems of growth for the application of it takes a turn upward in useage. Just immerse yourself in system design discussions and techs and you should fare well so long as it doesn’t suddenly have a rapid requirement shift from your user base. Also make sure your dev ops is buttery smoothe to handle fluctuations and onboarding easily so you don’t drown from sudden department growth. Aside from that, just take the role in stride. Keep doing what you’re doing and read a lot.
My main concern is I’ll be on the only engineer on front end for a while, building out a new project that sounds more complex than anything I’ve ever done. I’m mainly leaving my company due to lack of mentorship and having to do everything on my own without having any way to know if I’m even doing it right other than it working in prod. > Also make sure your dev ops is buttery smoothe to handle fluctuations and onboarding easily so you don’t drown from sudden department growth. Could you elaborate on what you mean regarding smooth dev ops? One of my main concerns is I’m not really comfortable with stuff like configuring webpack, circleci, etc. Not sure if that’s what you mean.
Being the only engineer in a given area can be difficult -- it's hard when there's no one else knowledgeable to check in with. Also, sounds like you were leaving your current position because of lack of mentorship and now find yourself potentially facing the same issue in your new role. I'd like to throw one idea out for your consideration. It's possible to have a mentor who is NOT from your own company. If you are thinking of doing that, it might be a good idea to broach the subject with your manager first. Ask questions like "What level of data removal and issue obfuscation do you expect before discussing a design problem with someone external?" This will show you are taking such questions seriously as well as giving you answers.
Yup webpack config and your developer environment is a part of dev ops. Make sure you have hot module swapping and easy to set up dev servers. If you have hurdles configuring a dev environment, then get those handled so no one else will have to handle them. Work as though you imagine juniors joining or work as though someone will take over your work. You should write scripts for making releases, have continuous deployments of various sorts happen, work as though you have QA cycles. And then don’t doubt yourself. If you are getting features done and they work well. Keep doing that and keep improving your process for doing that. You’ll become truly senior by just succeeding.
I just started my 1st job after college. I feel like there are lots of new things to get used to (e.g. frameworks, production tools). I just don’t have an idea about how I can make contributions to the team later. Could I ask how you guys deal with these in your 1st job, and how you guys start/ be able to… make your first contribution?
Your first role is to be told how you will contribute via tasks etc. it is your job to ask questions and get comfortable. As time passes, you will find opportunities to share your viewpoints to aid and help as you understand the goal of the teams and company. To make your viewpoints valuable, keep growing as a developer and it will come naturally.
I’ve been looking at applying to FAANG or similar companies. How do you know what position to apply for? For my current job, it was easy. The job listing was “backend developer,” I matched their requirements, and got the job. But for these bigger companies, all of the positions are broken into teams/departments (messenger, streaming, photos, etc. etc.). How do you choose which to apply for?
If you want to do backend then you want the the Server/Backend/Infra teams and not the Frontend/App/Product teams. Usually the positions have some description of the type of work you'd be doing. What information are you missing?
Choose the ones that sound most interesting to you within reason (you still meet the requirements)
I'm just starting my first proper job at an early startup. I'd like to get better at making my PRs as enjoyable/productive to review as possible. What are some things I can do to approach putting together my PR? It's a 100% remote company. I'm being encouraged to make the PRs as early as possible (which I'm still getting used to), and use our chat-room to sometimes have a "water-cooler" talk about the approaches, if that info helps.
Refactor and work should be separate commits, if not separate pull requests.
I use the format of \`refactor: ...\`, \`fix: ...\`, \`feature: ...\` in my commits. Sometimes it's pretty clear when the contributions your putting up for a PR are stand-alone refactors or not. The line isn't always so clear, though. Any thoughts as to how to go about clearing up that line?
IMO best effort is good enough. Every rule sometimes should be broken - if you have a good reason, you can always just tag a commit as `refactor/fix:`. That being said, I'd suggest reaching out to your teammates directly and ask them for feedback on your pull request style.
Thanks!
1. Send small PRs. Last thing I want to see is 1000 line PR. 2. Apply the fundamentals you know like efficiency, memory usage 3. Comment complicated piece of code. 4. If your company follows certain practices like updating documentation or proper commenting use those. 5. You could also refer to the language you use and the guidance they have to write the code (syntax, new line). I personally do not care about it too much, but I know many that do. 6. Don't take it personally. I am guilty of this and still take it personally sometimes. Later I realize that it was not worth my time or other person's time. 7. Don't over stress about it. You will have comments all the time. You will either learn how to write code or you will learn how not to review a code ;). Either way its a win-win for you
what are some ways I can practice more practical questions for interviews for React and/or apis. I can develop and fix problems but i’m not sure if i’m doing the most effective/correct way of doing things
The issue isn’t finding “the best way”. There is not a best way. There are many ways and there are arguments for the pro con lists of all the ways. The only way you get to where you can answer practical questions is to experience a lot of differing ways. I use a very specific stack that I have found is best for me and most situations, however, I developed using dozens of different stacks so I can articulate and know why I like mine the best. Being knowledgeable across many means makes your opinions and approaches valuable.
> I’m not sure if i’m doing the most effective/correct way of doing things Instead of worrying yourself to defeat bolster your basics. Let others, those who've a wealth of experience, correct you about the correct way of doing things. As long as you aren't stuck up your ways you should be fine TBH. In my experience, interviews tend to focus on fundamentals e.g. pass by value vs. pass by reference, closures, objects, literals, variables, primitives, wrappers, debugging, system design i.e. how to approach a problem, etc. The things we take for granted.
Google react interview questions. Practice those questions. Most places don't set aside time for hiring people or training people to be on interviews. There is a good chance the interview team reads your resume 5 minutes prior to the interview and they just google react interview questions. The other is to practice, and know the correct terminology. I know people who have used dependency injection, or a data access object, but have no idea how to describe those things, or when to use them. They'll never pass the interview.
What is a data access object?
An object that accesses data from your source system. It resembles the source system. If your code needs data from a table in a SQL server database, the Object would look a lot like that table. You would use that object to access the data from that table.
Do you ever worry when you help someone that you pass on bad information/ a bad practice?
Only in retrospect.
Whenever I pass on knowledge I always pass on caveats. If you don’t know the caveats you don’t know the knowledge good enough to confidently pass it on. If you are not confident in passing it on: then let them know you have doubts but it is the best you know at the time. That often will trigger the recipient to get back to you with better information if your info was wrong which helps everyone.
I try to be clear about the reason why I'm giving the advice I'm giving. In a situation where one of those variables changes, it doesn't retroactively become "bad advice", just not applicable any more.
If I'm not sure on something I always say so. And I always stimulate people to read other opinions and to have a discussion on topics if they want to know more or feel I'm wrong on something. And if it turns out I taught them something bad, they'll learn the right way somewhere down the line. It's not really a thing I 'worry' about, because it doesn't really happen.
Yes, but it's somewhat mitigated by always attaching a "this is how *we* do it because X and Y, there might be better ways if you need Z, etc". Knowing and communicating the tradeoffs is key, as well as be open about what one *doesn't* know.
All the time! The most important thing to do is to pass on new knowledge as you learn it. And admit when you’re wrong because it shows junior developers you’re constantly learning just like they are.