Great people, wonderful atmosphere, and fantastic benefits in London.
Poor management, sometimes condescending, who believe they know better than engineers "on the floor". This "features over quality, do what I say" attitude seems to have pervaded into what was once a dynamic, agile eBay subculture in London.
Unfortunately, this attitude will not improve anything; legacy code needs time and care. Despite the company touting that we should "deliver with impact", if you step out of line with delivery timelines or feature stack, you will be penalized for doing so.
Listen to your engineers. You do not always know best.
Recognise the talent you have, and respect there's more than your way to achieve something. Engineers know what they are doing; empower them, let them fail, and support them if they do.
Give them the real choices on how to achieve their goals, and trust their decisions. Stop telling them what good behaviours are according to you; they already know, especially the senior engineers.
For juniors, promote ways of learning what good behaviours are and how seniors should share those with others. Guide in policy and general attitude; stop dictating and controlling the narrative.
Stop attempting to deliver on broken software; recognise it needs fixing first.
Recognise you have probably been "lied" to in the past by devs worried about their careers and scared into delivery. Your software is (in places) terrible due to this "features at all costs" attitude.
Recognise engineering best practice is best practice for a reason.
Code is expensive; being sure of what is required before you write it is not.
Honestly, the fact I have to actually write any of this should make it entirely apparent to anyone that the eBay management system is currently broken. Attempting to explain any of this will be pretty much ignored, and you could even be penalised for it.
Good luck.
The interview process typically starts with an initial phone screening. This is followed by a moderate technical interview that includes behavioral questions and live coding. Finally, it concludes with an HR round.
Design Node.js modules for file operations: addFile, updateSize, addUser, getFile, removeFile. Implement robust Mocha tests covering happy paths, edge cases, error handling, and concurrency with filesystem mocks. Create tests: * addFile creates. *
Phone interview: 45 minutes. Start by discussing your experience, then a coding question, and finally you can ask one question to the interviewer. The conversation was friendly, open, fast-moving, and fluid.
The interview process typically starts with an initial phone screening. This is followed by a moderate technical interview that includes behavioral questions and live coding. Finally, it concludes with an HR round.
Design Node.js modules for file operations: addFile, updateSize, addUser, getFile, removeFile. Implement robust Mocha tests covering happy paths, edge cases, error handling, and concurrency with filesystem mocks. Create tests: * addFile creates. *
Phone interview: 45 minutes. Start by discussing your experience, then a coding question, and finally you can ask one question to the interviewer. The conversation was friendly, open, fast-moving, and fluid.