Hacker News Reader

Comment by redisman | Hacker News Reader

I totally agree that this trend is dumb. It doesn’t even pass very common sense checks. Just because its numbers doesn’t make it a good signal. Anyone can cherry pick numbers that make their contribution look godlike. Oh I improved the loading time of our internal tool by 1000% by applying very basic optimizations I googled 5 minutes before that no one had bothered to do since it’s low priority.

Especially at smaller companies where you can easily 100-10000x specific things that no one has had time to optimize yet since they haven’t been top priority. To a smaller extent at big tech but the point is that optimization numbers without a great amount of context is completely meaningless (like the parent said)

View on HN

Numbers are good. These are the wrong numbers to include. You want something that indicates the scale, scope, and complexity of what you did. I don't care that you increased user engagement by X%. I care that you've designed and implemented the type of things that I need designef and implemented.

But what number would you like to see on a one liner bullet point to indicate “scale, scope, and complexity”?

Designed and implemented GraphQL API for 30 objects serving 200 Queries per second

To me that would still tell nothing. Did you just implement 30 queries that are “get item by key” from a database someone else designed so that your job was extremely easy ?

Even if it doesn't answer every question it gives you at least some insight into the scale and scope of what they did. Sure numbers can always be fudged but it's better than no numbers.

How would you write that line?

> Sure numbers can always be fudged but it's better than no numbers.

You can make the same argument for user engagement or business metrics numbers too. For most managers reviewing resumes, any number is better than none.

Thanks for the comments. Perhaps I can be helpful by walking backwards from something you do perceive as valuable? For hiring conversations, what's a great one look like to you?

That still seems meaningless.

200 queries per second, while pegging 8 CPU cores. Meanwhile my coworker got the short straw implemented a less-used API serving 10 queries, but did it much better than me and used no CPU.

That's far from a perfect statement, but it's not the worst that you see. As an interviewer, the difference is between junior and senior developers. It's an indication that they they understand the currency and some metrics for an area/business, but more than that, it sets out their position.

That position is something I should be challenging in the interview with questions to probe deeper:

* Can you tell more about the GraphQL API? Was this new or replacing an API? Tell me about the constraints and goals you were working towards?

* What issues did you have getting to that level of performance? What trade-offs did you make when you hit issues?

* What are the challenges with running your API in production?

* Can the API you implemented scale higher? If so, what would need to be changed with it as you scale to 400 and 1200 queries per second?

If this person has done the work this should be a good discussion and you can start to bring in some of your business or technical problems. It will be very evident whether someone has just invented metrics, or the statement is describing the work of others.

I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews.

OP here. This is exactly right: "I feel it's important for technical interviewers to have some experience with STAR/behavioral interviewing. This assists with screening/selecting resumes and exploring these areas in interviews."

Hope you don't mind if I steal some of your comment to use in the update of my post! :)

Quote away!

OP here. Hope you don't mind if I borrow this for the update of my post!

How many daily users? How many posts/orders/sales per day? (that one depends on what your company sells or does) How many GB of traffic?

How many people did you work with in your team/department? If you provide internal or public libraries, to how many developers?

I don't think it's shocking to have a line "Worked in the web team with a total of 4 developers in charge of the website of the company (react), backend API (nodeJS), and the Android application."

Improved the performance of a rendering system from 10000 objects per second to 100000.

Super vague, means basically nothing. Maybe it should be written with a bit more detail about what kind of rendering system this is. Still I would be interested, and in the interview I would ask them to explain the system and what they did. However, if it was something stupid (the original code was just super bad) then they would look dumb for bringing it up. Basically, if you put something like this in your CV, it should be something you're proud of for a good reason, not a result of trying to think of anything where you can reduce the impact of your work to a number.

The impact of most work cannot be reduced to a number, so it's perfectly fine to not have any "measurable successes" like that in your CV. In my experience, 75% of people don't, and 75% of people who do have stupid ones that just make them look worse (ie they read online resume-writing advice and put in something like the example this discussion is about). So there is no point in actively trying to think of something like that to put in your CV. If you have something, put it in, if not, that's fine. There's a pretty good way to decide whether to include it: does imagining your interviewer reading it make you feel proud or embarrassed?

But what if you implemented the same rendering system from scratch? If you put in a number, it will mean basically nothing. You can just describe what you built. You don't need to reduce your work to a number. This is simply incorrect advice in the linked blog post. The people hiring you are not judging you based on numbers which claim you contributed to the business in a measureble way. This is simply not true. Ideas like this are usually pushed by people who are not even in SD and are instead self-proclaimed "experts" in the field of "finding jobs" or whatever and are painting all industries with the same brush.

OP here. I agree with your feedback. At a small startup, engagement might be relevant. At a larger company, scale, scope and complexity, relevant to the level, are absolutely more appropriate.

I agree, but I also believe this is what the HR department would respond to best, if you happen to go through them first. All too often that is the case.

OP here. Readers of your resume, and ultimately hiring managers, will make assessments of your overall capabilities based on the type of achievements you use in your resume.

If a senior engineer cited an improved loading time that could be googled in 5 minutes as one of the 4 or 5 accomplishments in her or his two years at a company, they'd be sending a bad signal about the type and scale of achievements they're capable of. Hiring managers will be looking for something more level-appropriate and that indicates a relevant level of skill.

Reply on news.ycombinator.com