I have 10 yrs of Exp. Failed 4 takehome projects. What am I doing wrong?

A take home test as a first round filter usually means they are not that serious about hiring and it costs them no time, money. Meanwhile you need to invest 4 hours (they actually want you to spend 8 hours) for a position you have no idea if you are really interested in yet.

The chance you will get ghosted? Very high.

The four hours could be better spent.. you are more likely to get a response by cold emailing other companies.

Send them open source work and ask them to judge your ability/style based on that. If they are not interested they were never going to judge your submission based om your style / abilities and the four (8) hours can be better spent.

I would assert that the mistake is accepting a take home assignment in the first place. I would walk away at the mere suggestion, because they do not respect the value of your time.

If they do not value your time while you are interviewing, there is zero reason to believe they will respect it once you are hired.

There's a million reasons why you could and will get rejected that have nothing to do with the code you've written for the take home exercise. My usual solution is to ignore the losses and carry on with the grind. You only need to win once. Good luck!

One easy change: You could take a bit more care to make your code tidier. As an example, you're wildly mixing " and ' without any good reason (copy paste from somewhere?). The style of your line breaks also varies a lot. Just use any formatting tool and your code will look much more cohesive. Some structure in the packaging would also go a long way (folders don't cost anything).

This might seem superficial but as a super senior staff, I'd expect that you mentor your junior coworkers in how to build large yet maintainable projects. One important aspect is readability and consistent style. That's why black becomes more and more used even though some of its rules are fugly.

Second not so easy change: I find "The code was also not fully organized for testing" - this actually hints at you either not writing a lot of tests in your day to day life or being very inefficient in producing tested code. You also could have at least included one sample test.

This kind of comments are kind of useless it should be self explanatory

" # returns the path and current count that was just made.

return {"path": path, "count": int(data[0])}"

also maybe extract variables and name them better like:

"pipeline_execution_result = await pipeline.execute()

count = int(pipeline_execution_result[0])"

same here:

    return [{"path": path.decode('utf-8'), "count": count} for path, count in response]

what's in settings.py should probably be in an env file

overall: variables and methods name could be clearer, use good names instead of bad comments, extract variables, don't define methods inside of methods

it's definitely not BAD code, but I'd expect a guy with 10YoE to do better

orgs are chaos, “person” “reason” are both assumptions. for example perhaps there were 8 interviews that week for one position and it was earmarked for an internal candidate anyway. perhaps the position went away. perhaps your submission was too good and they hired a junior instead. perhaps the recruiter ran the standard process and the hiring manager didn’t even see your submission. perhaps your submission was best but the reviewer didn’t understand it. perhaps the reviewer was 24 years old. perhaps they hired someone who had higher status companies on their resume and that person didn’t even have to do the test. perhaps the manager is on a pet functional programming kick this year. perhaps you like FP but the manager had a bad experience with that this year. perhaps they wanted a woman. perhaps you’re a woman and they wanted a man. perhaps the manager is a red bull code smash bro. i could go on all day

The code overall looks reasonable and I don’t write much python but:

- requirements.txt is the standard for specifying deps, right?

- making a README explaining the project might be good (I see you have this, but maybe switch documentation.md to README.md)

- tests?

- building the flask application via a function is a bit more testable

- reading settings from ENV is preferred (12 factor apps)

- output not sanitized for /test endpoint

- generator in util could have been pulled out probably? It’s created every time

- generate test path function seems a bit longer than it should be — all those lambdas should probably just be functions since you’re going to use them a lot

- did you have to define your own Json type? Is that complete? Where’s null?

- url generate function should probably template hostname — that’s more important than host, most of the time for running in different environments

- trailing slashes matter in flask, evidently, and every request without one gets redirected (test suite would have caught this)

- on the usage of redis, I wonder if scanning + in-memory aggregation is better… zincr/zrank/zrevrange is good, but you’ll have to hold all data in memory (and receive it in one large response) and logN anyway, might as well do it simply with a set with a dynamic prefix and scan while building the output data structure as you go.

- do your API endpoints return JSON?

- error handling around points of failure like redis

— your app goes down if the connection is flaky right?

- zrevrange is deprecated now btw

Hard to tell for far they wanted you to go, but asking might have made sense… some nice-to-haves:

- healthz endpoints?

- metrics?

- tracing?

- error reporting (ex. Sentry)

The payback on take home tests is seldom worth it. There is too much liability and risk and very little incentive to the company to provide honest feedback.

You should learn to accept the fact that you will not get an honest review. If you choose to enter in to a take home test go in to it with that understanding.

The interview process is a chance for them to review you, but also for you to review them. Make sure the process is equitable. If they ask for too much you owe it to yourself to push back. Ultimately they will respect you more if you stand up for yourself. It shows you have healthy boundaries and will protect their interests when you work for them.

I am a staff engineer with 10 years of experience who has recently gone through the hiring gauntlet and dealt with something similar.

I interviewed for a company in May that gave me a takehome that was very vague and probably would have taken my entire weekend to do it. So I declined and moved on.

My rule of thumb though is to spend no more than 2-3 hours on a takehome challenge. If you think it will take any longer, don't do it. And lack of any feedback from the company pass or fail is ridiculous to me.

As for your submission it LGTM. I'd bring you in and probably ask about how you'd want to improve it if you had more time, expecting the usual best practices and scalability things. I'm not sure your Python experience, but given the context of the problem space, I'd ask why you wouldn't consider other approaches like adding the url metric logic in a decorator or some other modularization that could be reused to "performance test" future API calls. I'd ask about your submission's lack of tests (getting at unit tests here) and how you could refactor your solution to facilitate better test coverage if you had more time. Deepdive about the tradeoffs of using Python coroutines as opposed to other concurrency methods.

Unfortunately there's always going to be a desperate developer out there who will spend every waking second overengineering a solution that will set a high standard for everyone else to be compared against.

Wishing you the best of luck!

Looking at the requirements, they feel very understandable to me since I have worked with Flask quite a bit. Then when I look at your repo, I see poetry and quart, both things which aren't even in the requirements. If I had written these requirements, and received your assignments, I would have passed on them the moment I see something I don't know or didn't specify (like quart).

There's some nitpicky bits (like how "utils.py contains two utility functions" is then followed by _three_ bullet points :P ) but one big one that jumped out was using "zrank" to get the new score.

That's not going to return the right value most of the time - for instance, in the example from the docs at https://redis.io/docs/data-types/sorted-sets/ has this:

    zrank hackers "Anita Borg" is 4

but "Anita Borg"'s score is 1949. The operation you likely wanted was "zscore".

It would be straightforward to check this, either manually or in an automated test - simulate hitting "/api/abc/" once and "/api/xyz/" three times. The result of 3 of the 4 requests will be wrong:

    for /api/abc/: will have count=0 because /api/abc/ is the only entry in the sorted set
    first one for /api/xyz/ will have count=1 because /api/abc/ sorts before /api/xyz/ and they both have a score of 1
    second one for /api/xyz/ will have count=1 because /api/xyz/ has a higher score than /api/abc/
    third one for /api/xyz/ will have count=1 because that's still true

Now, it's true that the assignment didn't say anything about what the service should return: you might have done better on this assignment by returning HTTP 204 and an empty body.

IMO when a "super senior / staff engineer" chooses to write code, they should write WORKING CODE and verify that that's true.

From your documentation: ----- Self Criticism or things I would've done if I had more time. testing: -----

That first part over there blew up your whole effort. No matter how good as an engineer you are, if you don't provide any unit tests, most often it's an automatic rejection.

Also why did you put that self-criticism section anyway? You don't owe them anything nor should they owe you as well.

As a final thought when you are doing the effort to apply to work for someone else then they can reject you for pretty much anything so don't sweat it too much.

Not hearing anything has little if anything to do with you. Sadly, most companies can't be bothered to follow up in any way. Consider it a signal as to how much a organization values communication and culture, etc.

I understand. It's disheartening. But it's not you, it's them.

I've aced take homes and still been turned down for various nitpicks. A lot of times I think the person reviewing the code is looking for their pet preferences to be met rather than evaluating the potential of the candidate.

If I was evaluating your code for production standard, then no testing is automatic failure. I assume you didn't run python formatter like black. Some of the codes aren't my personal style, but I won't deduct any points for that.

Take-home exam is bullshit in my opinion. I've done total of 3 in my career, and nothing came out of it. Zero feedback other than you are not what we are looking for. I've long since declined about any take home exams. I rather leetcode than take home because leetcode can scale, while take home is just unpaid work.

> ...came back as failures with zero feedback given.

Maybe a dumb question, but did you follow up and ask for feedback? Sometimes people just don't think to provide feedback, but they would if prompted to.

Other than that, I think the code is completely fine. Stylistically I can see people having non-consequential nit-picks based on what they like but I think it wouldn't be an issue to get weeded out by.

I would email the recruiter back asking for feedback on the project. The worst they can say is no, and at best you get some insight into their reasoning.

Code review: For a senior dev, I would expect tests even if I didn't ask for them explicitly. I'm also surprised to see that the functions are in a generic utils instead of better named files.

The reality: 1. other people are spending more time on these takehomes. 2. Being more senior means that there are higher expectations. 3. The takehomes are typically a qualitative assessment

Honestly, your code looks great. Yes, there are thousands things that can be done better, so there will always be people saying so (just like in this thread). But that's no reason to deny a candidate a chance. Mature companies realize this and aren't really looking for the perfect code. They are more interested in the thought process behind the assignment. I think you're just having a hard luck, specially with a tight tech job market.

Impressive for only 4h of work and good caveats list in the documentation. I can't see the restriction on number of path segments in the code ("/api/ followed by 1 to 6 path segments") and they might have insisted on tests while not mentioning tests. Nobody can tell what "production readiness, and code structure" might mean for them.

Your code is fine. Now you've got a decent sample, in future just respond to any other takehome requests with a link to this above, since it already shows you're competent and know how to reason.

No need to waste another 4 hours per company (a ridiculously large task).

Interviewing is a process that can make anyone, no matter how great they are, question themselves. Sometimes evaluators have some weird criteria that is important to them and you'll never know why!

Have take homes become a lot more common these days? I think I've done maybe 4 in my whole career.

With 10 yrs of experience maybe you can call some contact and remove the first round coding exam?