Director of Engineering @Docker
⌇ Leadership • JavaScript • Kindnessship ⌇ DMs open, here to help ⌇ Follow for tips + news + a friend 🚶
https://twitter.com/shawnaxsom
Coffee chats, resume reviews, career advice, etc. When I have time! Find more on how I or others can help on: http://heretohelp.social
Hey Narmada Nannaka ! Nope, we keep the information shared about the candidate confidential to the hiring panel. The hiring manager is usually the direct manager of the individual, and the manager will therefore have the knowledge of the strengths/weaknesses (along with aspirations, ideal work environment, etc that I often ask about), and some of that may carry over to employment.
Great topic. Diversity and psychological safety help prevent groupthink. Diversity helps bring diverse viewpoints. Psychological safety helps make sure those individuals feel safe to share their viewpoints, rather than going with the group. Other aspects for avoiding groupthink include anchoring. In the book "Leadership is Language" IIRC (or some recent book I read 😅), it discussed if you're the leader, don't be the first to speak up, or you anchor the conversation, reducing variability of follow-up ideas more so than other people due to appealing to peoples' bias towards authority.
Yeah! Fullstack vs Frontend/Backend is a great example. It's nice to have a mix of deep knowledge, along with others that are flexible when frontend/backend ebbs and flows. Fullstack engineers can be great for throwing together POCs, unpacking tightly coupled UIs with APIs, etc. Frontend or Backend can have much deeper experience in their domains and in areas like design, accessibility, or devops, infra, cloud. Teams with both can work well for most teams. And for specialists, it can be good to have a more technical Frontend Engineer, a more designer-focused Frontend Engineer, etc. Specialization doesn't stop at Frontend versus Fullstack.
Great article, Allan! It's true, people need to show their work, and they need to work towards having worked on a production system. Work up the complexity ladder: Tutorials Side projects Joint projects Open source projects Freelancing paid projects Production codebases Something like that. Depends on the projects of course. Some open-source projects may be more complex than a production codebase. Each of those rungs can be more complex than the rest, though. Don't stick to tutorials and expect to be able to make the leap to a 10-year-old codebase. You can do it certainly, but having practice reading other peoples' code can help make it a more seamless transition.