|
|
|
|
|
|
by dev_throw
2606 days ago
|
|
|
This would be more applicable if the interviewing process had any correlation with on the job expectations. Working on a job also requires:
1. Communication about expectations with team lead, PM and other stakeholders, vetting requirements, and pushing back where necessary.
2. Writing tests that cover as many edge cases as possible (This actually takes just as long as coding a feature if done right)
3. Understanding the pipeline and release cycle, and being able to build new hooks
4. Look at stack traces to debug application crashes. This usually involves debugging code that other people have written.
5. Review other engineer's merge requests, and communicate in a emotionally aware manner. A leetcode/hackerrank type interview does not test any of these skills. If I work on improving these skills that make me an amazing engineer, it does not get me far in a typical interview, hence my frustration with their "weeding". |
|
|