Instahyre Reviews

When I first saw a review posted by another colleague, I felt relieved that someone finally spoke up for us juniors. But I was disappointed when management’s response chose to dismiss it outright as a “poor performer’s rant” instead of even considering that there might be valid concerns worth addressing. Since, I joined Instahyre fairly recently, I can’t comment on what happened years ago, but I can certainly talk about what I see and experience now. And much of what the earlier reviewer mentioned rings true. Some of those issues I’ve personally faced, while others I’ve seen colleagues struggle with. Also I wasn't once pinged by either management nor team lead for poor performer. So, I believe that I am doing fairly well. - Engineering leadership mainly focuses on meeting deadlines, often at the expense of code quality. While it may look good to management as deadlines are being met, developers are burning themselves out to maintain standards since they don't want the standard of code to drop. If this continues, quality will eventually slip, since devs will stop caring about code quality and major bugs will surface. - The idea that older employees are “poor performers” and only new hires are “good” is misleading. From my experience, old colleagues are equally, if not more, capable. In fact, newer hires, including SDE 2s, often turn to them for support, which shows their value. - In my time here, I haven’t seen engineering leadership actively unblock developers. Instead, progress is often slowed down with unnecessary explanations, frequent follow-ups, or being pulled into long discussions that usually end with “check with the CEO/PM”—something already done. This wastes time and forces developers to work extra hours, creating mental burnout. - Engineering leadership does not seem to align with company goals either, focusing more on avoiding accountability. If bugs appear, the blame is shifted to developers. If deadlines (decided without consulting developers) are missed because developers are trying to maintain quality, the same thing happens again—developers are unfairly blamed. Overall, what worries me is that concerns from employees are being brushed aside instead of even being acknowledged. That dismissal, more than the deadlines or the interruptions, is what hurts morale the most.

Very little consideration for developer well-being; decisions often ignore basic realities on the ground. Paid leave policy is already below market, and the company only "benchmarks" when it benefits leadership. Mandatory office attendance during high AQI periods has led to predictable outcomes: people get sick and burn through limited leave. Employees who relocated to Noida for the coworking setup are now effectively stuck, with limited ability to travel home during holidays/festivals once leave is exhausted. Many companies even worse provide some flexibility (hybrid/WFH blocks) around holidays or during health/environmental issues. Here, even reasonable requests are routinely rejected with vague or inconsistent justification. Requests for practical mitigation (e.g., hybrid schedule, air purifiers, basic workplace health measures) have been ignored. Pre-planned leaves routinely get questioned, stalled, or quietly blocked—often because management can’t plan capacity. Any pushback gets labeled "not aligned," and quickly turns into performance pressure (including PIP talk) or selective scrutiny. Expect an always-on culture: weekend/after-hours pings. Boundaries aren’t respected because planning is weak and urgency is manufactured. The 5-days/week coworking mandate reads less like collaboration and more like control and micromanagement. Initially it seemed like engineering leadership was the issue; later it became clear broader leadership endorses this culture i.e prioritizing compliance and control over competence.