I once put in about 8 hours on a take home project at a company (well known in these parts) that I had tremendous respect for, only to get an email back with "sorry, not up to par. We need someone with more experience".

I asked them for a couple quick points on what I could have done better. I had zero intention of fighting them on it. No response

The whole experience made me feel very ill, especially after putting in as much effort as I did, and obviously I feel quite differently about that company now.

On the other hand, 5 years ago when looking for my first tech job, a virtually unknown startup that rejected me after a take home project and day long onsite gave me very thorough and specific feedback, encouragement, and even a bunch of reading suggestions. Even though I didn't get hired, I have very fond memories of that interview and reached out to them when I did land my first job to thank them again.

Did it have any tangible implications for their bottom line to give me that feedback? Not really. But they treated me with compassion rather than like garbage. I have never named and shamed the first company and never intend to, but I personally think there's more risk involved in habitually treating people like garbage than like human beings.

This has to do with how law is structured here: giving feedback gives an attack surface to candidates that could sue you for the feedback you gave (because they do not agree with it).

So this is it, companies do not do this because they're evil, they do this because nobody wants legal consequences.

The trick is to ask legal "I'm doing this, how can I minimize our legal exposure". Not to ask "can we do this". The second question will invariably get you a "no" (if you thought to ask, there must be _some_ risk). The first question will get a lot of grumbling, but if you're in a high-enough position, will eventually lead to useful advice.

(1) The basic idea is that in the early stages, you need to prove traction/market interest for your idea. As such, it needs to show no signs that it's backed by Adobe - it's trivially easy to get a BizzFeudNews article about "Adobe launches ShitDraw Pro" or whatnot; it's very easy to get thousands of people curious & signing up. All this is much harder when you're a John Doe, and don't lean on the brand recognition, but on the intrinsic value of your idea/product. However, this all means is that by design in the early stages you will have company employees, paying with company money, to "launch" services & get people to subscribe while hiding the true entity behind those services. No nefarious motivation behind it, but surely you can see the potential legal challenges.

I can't imagine that this makes any sense.

Let's say you give every interviewee feedback:

- 90% of candidates will be grateful

- 10% of candidates will not like the feedback and start to argue (at this point ignoring emails might make sense to avoid wasting time)

- 0.01% of candidates will actually sue you over it

The lawsuit will probably go nowhere, and in the worst case cost €10.000 in legal fees.

But all the good will from the other people must be worth something! Maybe one of all those people who you gave good feedback refers a friend, and they apply to your company. If you hire that person, you just saved 10.000€ that you don't have to pay a recruiter!

So either all these lawyers are giving bad advise, or maybe my numbers are wrong? I've never heard of a lawsuit where a candidate sued a company as a consequence of interview feedback that they got, so I assume that must be a very rare occurrence.

The lawyer isn't likely to get upside of giving feedback, they will likely get the downside of the company gets involved in legal stuff.

A good lawyer should also tell you how big the risk is that you are avoiding, otherwise their advise is worthless.

But at the same time they're sponsoring meetups and conferences, hosting coding contests, sending people to career fairs, buying huge ads on job platforms to advertise company culture, just to get people to apply?

I can't talk about all of Europe, but here in Linz a lot of companies struggle to get candidates, and they spend a lot of money and effort to get a good reputation as an employer.

A prospective job seeker goes on Glassdoor. 100 companies. 99 with only positive and neutral reviews, maybe some negative saying "rejected without feedback". 1 with a rant about how they're disrespectful dicks who are just assholes. "It wasn't the feedback. They weren't even correct and they just told me I wasn't up to their so-called 'standards'. Completely rude in their email correspondence.".

Go on, you read that, you have 99 other places to apply to. What do you actually do?

I feel you overestimate the amount of fucks managers and HR give about Glasdoor feedback from rejected candidates in Germany. No company I interviewed at gave any meaningful feedback(for legal reasons) or seemed to care about opinions of rejected candidates knowing recruiters are constantly flooding them with resumes from new potential candidates on a daily basis and also most rejected candidates won't bother writing feedback on Glassdoor because once you've been around the block a few times you realize it's the norm and you're basically preaching to the choir.

The hell they don't. The root post of this very thread could easily have been a "ranting screed" on Glassdoor if the poster was of a different mindset.

Is it possible that there may be a distinction to be made between all the good will from the other people being worth something and all the good will being worth more than the legal headaches, PR headaches, and other potential consequences of someone reacting badly to feedback?

This is the kind of question that demands a quantitative analysis, but I hardly know where to begin beyond that it's an expected value question. Where do you go about putting a number to the value of something that "must be worth something"?

This is a healthier way of looking at online discourse than constantly asking people to provide sources and citations. If they didn’t mention them, you can safely assume it’s a guess. It’s implicit. Don’t like the guess, great: help us improve. We’re all in this together. It’s not a battle of “who has the best opinion”.

Maybe that’s what you were trying to do, in which case I’m sorry for misunderstanding. I genuinely didn’t understand your comment, please forgive me :)

I was on the receiving end of no-reply and didn't like it. But if I were to switch sides to a company, then after a couple of honest attempts at feedback I will most likely say fuck-off and send a stock letter instead.

If you make a conclusion on made up data you get bogus conclusion.

It may be a good conclusion, but not for real life where facts don't match made up data.

No. You work with made up numbers to understand the problem. Then you can make conclusions even without knowing the precise numbers.

For example, my analysis doesn't change much wheter the rate of lawsuits is 0.1% or 0.01% or 0.001%. It would change if the rate of lawsuits is 1%.

But I am pretty sure that the rate of lawsuits after interview rejection is much less than 1%. So I can make a conclusion without knowing precise numbers.

Calculations based on estimates come up all the time, and they are very valuable. They make it clear what assumptions your decisions are based on.

What's the alternative? You have to make a decision. If you don't want to use estimates, what are you going to base your decision on? Whatever feels right?

Your (guess) data is probably right but it discounts too much the downsides. When you present your hypothesis to them (e.g. me) they will tell you (rightly so) to try it yourself first.

As one example: it is illegal to say anything negative in a letter of reference. See https://workplace.stackexchange.com/questions/74438/recommen...

Why anyone would anyone take a risk? To make someone feel better?

Straight out of college I got rejected by failing miserably at a technical interview almost to the point of tears when I realized how little I knew. Maybe my interviewer saw this but I got very practical feedback, and knew exactly what to do with myself that summer to get hired.

Normally, in Germany, in your resume you should have a photo and specify your birthday/age and nationality, especially important when applying at traditional engineering companies. This opens you up for a lot of silent discrimination.

So, if they reject you for being the wrong age, nationality or skin color (yes that happens, a former German manager explicitly told HR he doesn't want Indian candidates on his team) or for speaking German with a strange accent, they definitely don't want this information getting back to you as you can sue them for that so the only feedback you're gonna get is the legally safe copy-paste "unfortunately, we're looking for a candidate that better suits our needs".

Can you name one case where this actually happened?

The only practical way someone could sue you is through "Allgemeines Gleichbehandlungsgesetz (AGG)" if they can prove that you discriminated them based on their age, gender or ethnicity.

All interviews could be simple Q&A sessions to make sure the person isn't a charlatan and then sell them on the position.

HR isn't a science, and it never will be. The FAANGs spend god knows how much time and money on it, and they admit that their interviews aren't better than a coin flip.

I'm curious what this means. Whiteboard style interviews aren't perfect, but at the very least they demonstrate 1. You can communicate with another engineer on a technical problem (simply writing the code with no explanation isn't sufficient), and 2. You have the determination to study CS topics for a long enough time to be prepared for an interview.

Both of those skills should have at least some correlation with success at your job, certainly better than a coin flip.

An interview only has one question to answer: How long will it take this person to do what I need? Everything after that is you trying to sell the company to the candidate. After you do the interviews, you pick the person who needs the least ramp time.

Quietly staring at a person writing on a whiteboard while taking notes isn't communication. It isn't normal. It tests nothing except the candidate's whiteboard interview technique. You test their communication ability... by communicating with them. Have a conversation.

Testing someone's determination to do useless studying for your ridiculous company is pointless. I am not here to get you to join my cult. I am here to pay you to do things. That's it. Unless your job is to design and review algorithms, I don't care if you can draw depth first search on a whiteboard blindfolded.

There are a million ways to figure out how long it will take to get a person up to speed. I make a list of the skills needed for a position. I write down an approximate time to learn each one. In each interview, I figure out what skills the person has by discussing that skill. That's it.

You'd be shocked how many people that write years of relevant programming experience and fail that. Do we get some false negatives, probably. But it's a reasonable price to pay compared to hiring someone unqualified.

I think a big reason for this, is that you can teach yourself to be a developer, and all the millions of articles and videos on the topic mean you can get something done without understanding the fundamentals. I think this, for some, create a false sense of competency.

It's easier with say, structural engineers - if they have an exam and or relevant work experience, there is a pretty high chance that they're up for the job. And you wouldn't hire a junior engineers without a senior person overseeing and checking their work for grave mistakes.

I don't think false negatives are good. How many positions go unfilled for months and years? A lot. At a larger company, it won't take long before they remove the position entirely. They might not be wrong to do so either. Eventually your bus factor goes to zero, and whole teams go away. I have never seen anything beyond FizzBuzz, experience, and conversations be predictive for actual work. Even these only weed out the most outrageous candidates.

I work in the chemical engineering industry. They sort resumes, ask questions, and call references. They don't ask them to do sophomore level process energy and mass balance with multiple components and vapor-liquid equilibria on a whiteboard. Most aren't Professional Engineers either. Junior engineers used to be a crap shoot. Now there are so many graduates compared to junior positions that most companies will only hire people that interned with them.

I'd rather that happen, than hire unqualified people. Hire and then fire someone is damn expensive - months of salary and a lot of hours wasted. If you don't get them out of the door fast enough, the damage they can do with incompetency is even greater.

Doing 7 hours of whiteboarding interviews for every candidate won't flush out any of these. Not a single one. If you can tell me the magic 8 ball I need to shake to fix this, I am wide open to suggestions.

You would have considered me a false positive then, despite the success of my career.

A phone app is one thing, ERP or accounting is another, avionics is another.

That's not saying much. I'm in my 40s, been in the industry for a long time, studied CS, etc ... but put the proverbial gun to my head and ask me to perform with judgement like that, I'd probably forget how to spell my own name.

There was some research into this, and IIRC, only half the programmers, both experienced and junior, got a while loop right (IE: no off by ones etc) the first time.

I wouldn't say getting it right on the first try is the most important thing. Writing code, logically thinking it through, and running through test cases to fix mistakes is pretty similar to how coding on the job is, albeit with less contrived problems.

Do you find people who did well on a preliminary test where they wrote some code fail this? If not, then why do the whiteboard? If people do fail, do you assume it's because they cheated on the previous test?

I think your stated explanation is incoherent, because you are claiming that self-taught developers can "get something done" without being able to write your ultra-simple algorithm. How can that be? You're not saying that someone can't handle B-Trees and you therefore won't hire them, you're saying they can't do anything and yet somehow they were hired and do stuff at other places. If they can "get something done", why are they useless?

If your comments are based on a lot of genuine experience and sincere and heartfelt, had you considered that maybe what's going on is simply that a large percentage of the people in the industry do not and cannot do whiteboard programming, but only write code at a computer? I have literally never had to, to get a job, and I'm not sure I can remember doing it in undergraduate classes either.

Joel Spolsky (and no doubt others) wrote something about how you can't hire the best people by just advertising a job because mostly the same people apply to all the jobs and the really good ones aren't in your pool.

But a corollary to that, I think, is that when you do hire some decent people, and you go on doing it, because it worked adequately, you are likely to wrongly conclude that is what decent people look like. It's not just the rock stars that are missing from your pool, it's the people who are terrible at interviews and are much more loyal to a job than those who can handle whiteboards and small talk. You may be in a bubble where you, and the people you hire, are working much harder than people in another bubble, but it's just a different way of doing things, not the only way.

I think this idea of your hiring pool not being representative and getting wrong ideas of what good and bad people are like has implications for diversity of various types, but I'm not going to flesh that out here.

My preliminary test is a phone call if there is more candidates I want to interview than I have time for. No coding.

> you're saying they can't do anything and yet somehow they were hired and do stuff at other places.

I have not stated that they've worked other places. I said that they claim to have worked at other places - that is a very important distinction.

> If they can "get something done", why are they useless?

I don't need people that can "get something done", I need people that can work in a team, do code review on both sides, do pair programming when the situation calls for it.

> It's not just the rock stars that are missing from your pool

I do NOT want a rockstar. They're expensive and not that much more productive. I want a great team and you build that carefully with hard working people that complement each other.

> it's the people who are terrible at interviews and are much more loyal to a job than those who can handle whiteboards and small talk.

We've had our share of people unable to perform a whiteboard "problem" as interns and for one-off things. Commonly for those that was unable to function in teamwork, was that they want a task and be left alone. That is not how you produce great software, and it certainly is not how we do it because of the software we write.

> I think this idea of your hiring pool not being representative and getting wrong ideas of what good and bad people are like has implications for diversity of various types, but I'm not going to flesh that out here.

Again, my goals are people that can work in a team. A whiteboard is representative for both communication and a basic level of competency.

Ok, but what does that have to do with writing code on a whiteboard? I'm telling you a fact - there is a whole world out there that doesn't do it, before or after a hire, and yes, of course they work in teams. I'm not out for an argument on how people should do things, so don't make it into one.

I have had a team that wanted to just chat on Slack and approach the tasks in a divide'n'conquer fashion. It does not work, and introducing a "lead architect" to structure everything is like pulling the reins of a mule - it will move backwards. Everyone needs to participate and feel shared ownership.

So if people cannot code simple shit on a whiteboard, it's my experience that they are a poor fit for this way of working.

I work really bad under pressure and don't like memorizing algorithms. I hate programming anything complex on a whiteboard or anyway on-site.

Simple stuff, like your example is fine. It's a good way to weed out charlatans. A few points what I consider a good test:

* No previous algorithm knowledge required.

* No ticks.

* An average candidate should finish it in 5 minutes. (So we gave them 10 mins)

* It can be written in 10-15 lines.

* Pseudocode is fine

Why should this be inadequate to demonstrate technical skills?

I can write Rubyish, Goish, Pythonish or PHPish pseudocode, but the syntax will be only 90% correct. I remember distinguishing features(like Ruby blocks), but features that all language has always a blur.

Looks like this is a common pattern with take home projects. I faced a very similar problem a few weeks back.

Though they called me for the interview. The general approach is to take some ones overnight deadline coding and code review it for a week. Then they dissect your code written in deadline duress like they are some masters of the universe. They also told me my code passed through their automated test suite, and then some programmers in their office reviewed it too.

And then after two rounds of interviews they rejected me because apparently 'cat error.log | grep 'ERROR:' | wc -l' is not how real programmers find error count, but write python programs every single time they face such a problem.

In short these places with take home interviews generally tend to be people who are full of themselves. They are also a kind of workplace full self-congratulatory people who have fallen in love with their own legend.

Haven't had a single good experience with places that give take home tests.

bulletsDodged += 1

What I'm looking for that it doesn't have obvious SQL injections (I've seen this a depressing number of times), it has some semblance of unit/automated tests, API validation, error handling, database migrations, good naming, and the code isn't all jammed in to one or two files.

Note how the evaluation changes from one person to other, you could be someone who expects an exception to be printed, I could be someone who expects an exception to be the wrong way, and would rather prefer a No Op.

As you yourself mentioned, SQL injection validations are important to you. Think of it from a candidate's perspective, you gave them a project with a certain set of features to finish in a deadline, and they need to finish it while holding a full time job. The candidate does the best they can to finish all the features. But you seem to have an invisible/opaque measurement in the form of SQL injection validation. The candidate might think you measure in terms of feature completion(Which would be correct, the project needs to work to be considered finished). The candidate could implement your spec 100% and yet get rejected.

>>it has some semblance of unit/automated tests, API validation, error handling, database migrations, good naming, and the code isn't all jammed in to one or two files.

In 24 hours?

What are you hiring for really? And why that kind of tearing hurry?

Having people to finish this kind of a high intensity ultramarathon coding drill under a crippling deadline. And then expect them to not just finish the assignment but also comply to your invisible quality checklist which no one knows but you.

For a change try taking such tests yourself. Like biggish projects, under super tough time limitations, and while you are at your current day job, with all the quality checklist evaluations attached. And then have it reviewed by other programmers.

You will see everyone has their own evaluation methods, and big feature projects delivered under heroic efforts, with tough deadlines tend to force you into some or the other quality compromise.

_Some form_ of error handling and validation should be demonstrated, because that's a standard part of any program.

Equally SQL injection is _always_ important. That's not a 'hidden' judgement criteria. It's a fundamental security issue that should be protected against.

Again, I'm not rhinoceraptor, but the gist of their post seems correct. If I was reviewing some code and it had no error handling, no validation, lots of god classes and methods and was susceptible to the most common form of web-based security flaw, that is probably a sign that the candidate isn't suitable for the position.

Good, constructive feedback should then be provided.

>> Note how the evaluation changes from one person to other, you could be someone who expects an exception to be printed, I could be someone who expects an exception to be the wrong way, and would rather prefer a No Op.

I agree completely. Any good interviewer/code reviewer should be fine with someone using exceptions even if they prefer no ops.

If an interviewer did complain loads about that (without specifying how bad input should be handled), they are a bad interviewer.

>> The candidate could implement your spec 100% and yet get rejected.

But adding "The application should not be simple to hack" probably isn't something a company should need to add to the spec?

>> In 24 hours? What are you hiring for really? And why that kind of tearing hurry?

24 hours? really? Yes I understand your frustration, that's no-where near enough (assuming you mean a company asks for the solution back the day after requesting it).

If it was me, I'd assume that such a company doesn't value work-life balance and pass on them :)

No, not in 24 hours. In about 2 hours. The laundry list of things - api validation, error handling, db migrations, good naming - it's pretty routine. A person writing production apis will have no trouble integrating all of it in a very short period of time. This is after all what we do everyday. If a candidate thinks not having sql injection in the code is an explicit requirement or is going to take a lot of time, then that is not the person for the job.

Here is a pretty simple flask implementation of your laundry list - api validation, db migration, no sql injections, no n+1 queries, good naming, swagger ui...

    from flask import Flask, jsonify
    from flask_sqlalchemy import SQLAlchemy
    from flask_migrate import Migrate
    from flask_apispec import use_kwargs, marshal_with, MethodResource, FlaskApiSpec
    from marshmallow import Schema, fields, validate, ValidationError
    from sqlalchemy.orm import joinedload

    # setup

    app = Flask(__name__)
    app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///dev.db'
    db = SQLAlchemy(app)
    migrate = Migrate(app, db)
    docs = FlaskApiSpec(app)


    # Return validation errors as JSON
    @app.errorhandler(422)
    @app.errorhandler(400)
    def handle_error(err):
        headers = err.data.get("headers", None)
        messages = err.data.get("messages", ["Invalid request."])
        if headers:
            return jsonify({"errors": messages}), err.code, headers
        else:
            return jsonify({"errors": messages}), err.code

    # models


    POST_TITLE_LENGTH_MAX = 80
    POST_CONTENT_LENGTH_MAX = 5000


    class Post(db.Model):
        id = db.Column(db.Integer, primary_key=True)
        title = db.Column(db.String(POST_TITLE_LENGTH_MAX), nullable=False)
        content = db.Column(db.String(POST_CONTENT_LENGTH_MAX), nullable=False)

        comments = db.relationship('Comment', back_populates='post')


    COMMENTER_LENGTH_MAX = POST_TITLE_LENGTH_MAX
    COMMENT_LENGTH_MAX = POST_CONTENT_LENGTH_MAX


    class Comment(db.Model):
        id = db.Column(db.Integer, primary_key=True)
        commenter = db.Column(db.String(COMMENTER_LENGTH_MAX), nullable=False)
        comment = db.Column(db.String(COMMENT_LENGTH_MAX), nullable=False)

        post_id = db.Column(db.ForeignKey('post.id'))
        post = db.relationship('Post', uselist=False, back_populates='comments')


    # schemas

    class CommentSchema(Schema):
        id = fields.Int(required=True, dump_only=True)
        commenter = fields.Str(
            required=True, validate=validate.Length(max=COMMENTER_LENGTH_MAX))
        comment = fields.Str(
            required=True, validate=validate.Length(max=COMMENT_LENGTH_MAX))


    class PostSchema(Schema):
        id = fields.Int(required=True, dump_only=True)
        title = fields.Str(required=True, validate=validate.Length(
            max=POST_TITLE_LENGTH_MAX))
        content = fields.Str(required=True, validate=validate.Length(
            max=POST_CONTENT_LENGTH_MAX))
        comments = fields.Nested(CommentSchema, many=True, dump_only=True)


    # dal

    def get_post_list():
        return Post.query.all()


    def get_post(post_id):
        return Post.query.options(joinedload(Post.comments)).get(post_id)


    def create_post(title, content):
        post = Post(title=title, content=content)
        db.session.add(post)
        db.session.commit()
        return post


    def add_comment_to_post(post_id, commenter, comment):
        comment = Comment(commenter=commenter, comment=comment, post_id=post_id)
        db.session.add(comment)
        db.session.commit()
        return comment


    # views


    class PostListResource(MethodResource):
        @marshal_with(PostSchema(many=True))
        def get(self):
            return get_post_list()

        @marshal_with(PostSchema)
        @use_kwargs(PostSchema)
        def post(self, title, content):
            return create_post(title, content)


    class PostResource(MethodResource):
        @marshal_with(PostSchema)
        def get(self, post_id):
            return get_post(post_id)


    class PostCommentResource(MethodResource):
        @marshal_with(CommentSchema)
        @use_kwargs(CommentSchema)
        def post(self, post_id, commenter, comment):
            return add_comment_to_post(post_id, commenter, comment)


    app.add_url_rule('/posts', view_func=PostListResource.as_view('post_list'))
    docs.register(PostListResource, endpoint='post_list')

    app.add_url_rule('/posts/<int:post_id>',
                    view_func=PostResource.as_view('post'))
    docs.register(PostResource, endpoint='post')

    app.add_url_rule('/posts/<int:post_id>/comments',
                    view_func=PostCommentResource.as_view('post_comment'))
    docs.register(PostCommentResource, endpoint='post_comment')

You submitted code which doesn't have things in my laundry list. Noticeably your db calls aren't surrounded by try/except. You have written no documentation. You didn't ship the code with git repo. No unit or functional test cases. I also expect these days one would use Python's typing library. Most of this helps in code maintainability. The fact that your assignment has none of this means you can't be hired to write production code ....

... See where this is going?

Despite you having written the code, someone with a different laundry list of quality checks can fail you.

There is no laundry list. There is an expectation that a senior engineer writes codes like a senior engineer.

> You submitted code which doesn't have things in my laundry list. Noticeably your db calls aren't surrounded by try/except. You have written no documentation. You didn't ship the code with git repo. No unit or functional test cases. I also expect these days one would use Python's typing library. Most of this helps in code maintainability. The fact that your assignment has none of this means you can't be hired to write production code ....

Not sure if you are really this dense or playing dense - the point of the comment was to show that your assumption about api validation and sql injection being explicit requirements or taking too much time is ridiculous. It' simple that it can be written in a comment in about 10 minutes, not the "24 hours" or whatever you claim it is going to take.

The very fact that you think sql injection is an explicit requirement or takes work will be an instant deal breaker for any position with the possible exception of fresh grad positions.

> ... See where this is going?

Yes, I do. You are arguing reductio ad absurdum to hide the fact that the things which you claimed unreasonable are in fact routine, and your time estimates are off by order of 10.

Followed immediately by.

>>There is an expectation that a senior engineer writes codes like a senior engineer.

You have no written list, but an imaginary checklist running in your brain about how a senior engineer writes code. Other engineers have theirs. I ran some of it and guess what, in that list absence of basic documentation, unit test cases, basic exception handling, code with types. Or even input validation for functions, like null checks is a no go.

Yet, if you submitted your feature complete project under a tough deadline to me, I'm not going to sit down and split hairs about absence of a favorite add-on feature of mine. That is what we are discussing here.

The code you posted in the comment above obviously doesn't have things like documentation, or validating function variables. Not even None checks. This obviously happens when some one attempts to write and submit code in minutes. When you write code this quickly, you focus on the exact feature demand at hand. Which in this case was SQL injection.

Other people got their feature set, in which several security add-on features would have been good to have but not in the time given.

>>You are arguing reductio ad absurdum to hide the fact that the things which you claimed unreasonable are in fact routine, and your time estimates are off by order of 10.

Oh obviously anyone who can do produce thousand(s) lines of code 24 hour project in 2.4 hours, is some totally different beast altogether.

There sure could exist such people who can produce >1000 lines of highly tested, security hardened code. I have yet to meet them though.

The closest I've seen is people who could write Lisp macros. But even those people wouldn't recommend writing code at the rate of 1000 lines per hour.

[1] There is a lot wrong with your "improvements". db calls aren't randomly placed in try/catch - that will be absurd. And the None checks aren't there because of something which you can very clearly see in the sample code but you also very clearly don't understand.

>>Do you have any production experience >>db calls aren't randomly placed in try/catch - that will be absurd.

Calls to databases go wrong all the time. Session objects expire, if you have cert based auths, they expire all the time. Especially if you have a largish microservices stack. Or you have locks on db objects, which you would run into. Or that network got flaky, or that just a certain type of resources like maxing out on db connections. Or that you are just trying to do write something to a database that is not allowed, like a duplicate primary key.

Never assume a database or any IO call for that matter will always go right.

Always check for every possible exception that could likely be thrown and handle it appropriately. Preferably each db interaction function should be atomic, and exception should be bubbled/raised/thrown to the application/feature main loop so that appropriate action like a retry or a roll back can be taken.

>>And the None checks aren't necessary because of something which you can very clearly see in the sample code but you also very clearly don't understand.

Pretty much any large codebase, that passes objects around should always do Null pointer checks. This is because several times resource heavy objects are initialized only on certain conditions, and if such objects are passed around they must be checked.

Is that why you made that absurd claim about sql injection being an explicit requirement? And that weird figure of 24 hours for handling sql injection, and api validation?

> Never assume a database or any IO call for that matter will always go right.

I said "db calls aren't randomly placed in try/catch - that will be absurd". Because they will be handled at app level to return uniform error messages. Now I am sure you will go on pretending that when you said "db calls aren't in try/catch", what you meant was db calls can throw an exception and app will handle it.

> Pretty much any large codebase, that passes objects around should always do Null pointer checks. This is because several times resource heavy objects are initialized only on certain conditions, and if such objects are passed around they must be checked.

What did I say about None checks not necessary because of something which is visible in the code? What do you think those marshmallow schemas and use_kwargs is for?

I've been on the other end of that, where we were explicit that the goal of the exercise was to solve problem X with technology Y so that we could gauge the applicant's skill with Y. And yet, we'd still get submissions that used Z because it was way better at solving X than Y was. Well, yeah, we know that. That's not what we were trying to assess.

I'm not saying you did that. It just gave me flashbacks to those situations.

It sounds like you got multiple solutions that used the best tool Z, but yet you reward people for being fine with using an inferior tool. That's not exactly the pool of applicants I'd want to bias my search towards.

Edit: I just want to add that I don't mean to sound harsh. And maybe it would help to understand what X, Y, and Z are in your case. Details do matter!

What the interviewer wants to know in this example is whether the author understands Python and file IO and data structures. Sure, you'd use the Unix pipeline in a production setting because it's better tested and faster. But in an interview context, that doesn't tell you whether the candidate is more likely to store item counts in a list or a dict, and that's what you're really trying to dig into.

If a base requirement is the thing is implemented with X, like wanting a table made of teak wood, and you give me a table that doesn't have any teak in it you've ignored half of my requirements. I don't care if you assessed my needs as being better met by oak and you made a fine table, I need to put a teak table somewhere and you completely failed at that task.

The point of a take home test that says build foo in Python so we can see it in Python is not "to see if a person can get things done," it's to see how a person gets things done in Python.

You're kind of right about it being the XY problem, except it's where the misdirected candidate is trying to solve "how do I do thing X" when the real problem is "write a simple program in Y so we can know if you know Y". We aim to be very explicit about the project's requirements so that none of this is a surprise afterward.

Besides grep itself was built on work done by other people before.

https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

GNU grep uses the well-known Boyer-Moore algorithm, which looks first for the final letter of the target string, and uses a lookup table to tell it how far ahead it can skip in the input whenever it finds a non-matching character.

If the idea here is to test if the candidate can come with the Boyer-Moore algorithm in an hour then I doubt something like that is even possible. Things like that are not invented by some one in an hour, the original inventors themselves likely spent a life time studying and working on problems to produce anything novel.

On the other hand memorizing other people's work, which they themselves took years work in discovery, in the current of Google look-up-able knowledge, literally proves nothing. It's the exact opposite of a person capability to produce things.

The whole idea of a take home test is to demonstrate capability. If submitting a working project under a tough deadline doesn't pass that test, then Im not sure what the hiring panels are even trying to do here.

Original:

  cat error.log | grep 'ERROR:' | wc -l

  cat error.log | grep -v 'SENSITIVE' | grep 'ERROR:' | wc -l

Original:

  grep error.log 'ERROR:' | wc -l

  grep -v 'SENSITIVE' error.log | grep 'ERROR:' | wc -l

  gzip file.js | wc -c # oops, we've just removed file.js
  cat file.js | gzip | wc -c # shows compressed size

Perhaps real programmers would 'grep -c 'ERROR:' error.log'. I’m not sure what kind of overhead the extra pipes use.

With several of the companies, I managed to (via either vowing silence to recruiters, or having an inside guy) get feedback on my projects. Nobody volunteered feedback willingly. And honestly, based on what feedback I did get, I see why they didn't want to offer it. It was an unscientific mess.

Generally:

* There was either no rubric or very basic rubric for scoring the assignment * reviewer gut feel and comments were seemingly more important than the score (if present) anyway * frequently, reviewers disagreed over whether a cool doodad was indeed cool or over/under engineered. * frequently, there were "gotchas" where they were either expecting you to notice an "issue" with the prompt, or they gave a vague prompt and wanted you to fish around to discover specific non-obvious things they wanted to see.

Now obviously, it's not like any strategy for interviewing software people is all that great. But at least interviews take nearly an order of magnitude less time than projects, and also have some built-in feedback via facial/verbal cues and such. Instead of just shooting your project tarball into the abyss just to get a boolean back.

Engineers in many companies are already given far worse job experience than what is paradoxically required on their resume to get in. Interesting or valuable projects are rare and lots of people fight over them.

Whiteboard hazing tests for fealty or naivety that will let existing engineers remain superior to you a lot of the time. Really smart people who would leapfrog you aren’t going to agree to be infantilized like that.

So it’s a filter on a certain combination of both competence and fealty. The company / department as a whole might have an incentive to hire really good people, but because lower level managers and engineers own the loose rubric of what counts as a good candidate performance, their incentives to hire only a subset of competent people who are also manipulated into being in their control will take precedence.

It’s so bad that we even have things like TripleByte now that are outsourcing options for filtering based on fealty while disingenuously claiming to be objectively filtering on skill assessment.

I do think loyalty/fealty is a legitimate goal even if the things people do to try to get it are futile or counterproductive.

It's a real red flag.

It's just difficult - and while interviews are decent, whiteboard tasks are usually useless. If you have your own or contributed to open source projects, that's pretty good too for assessing code quality, but not everyone has that.

Ultimately paying for assignments would probably be the best solution, but not everyone can do that either.

But the problem is, some places provide a take-home assignment in the beginning, and then override their judgment with the programming test in the interview. Which makes it pointless, which probably leads to candidates rejecting the sort of place that does the take-home.

I immediately discard such companies (if they don't budge). They have shown, from the get go, they're not respecting their engineers. Why would you work for such a company? You're never going to be treated as an equal there.

But I only do homework after the on-site interview, so I know I really want to work there and they have some "skin in the game" too not just shotgunning random candidates that they never actually planning to hire.

Also, anything over 3 hours is a no go.

Edit to add: as far as getting paid, nobody expects to get paid for an onsite interview so I wouldn't expect to get paid for a take home project either. As long as it takes the same amount of time that the coding portion of an onsite interview reasonably would, that is.

What makes this whole thing complicated is how they go about measuring quality, extensibility, or if they measure feature completion.

Most companies that give you a take home assignment also get you onsite for one or two sessions of code review and feature addition.

If you don't take into account quality or extensibility you fail in the next rounds.

By no means are these 2 hour projects. Most of these projects take at least a few days to do well.

In some cases the person designing the questions just overshoots the measurement. I've heard sometimes they ask you do come up with a feature loaded contacts iOS app in like a weekend.

So please, stop making assumptions about companies and take home tests. Unless you've worked for that company in a hiring capacity you have no idea what their process and motivations are.

Also, I've conducted a number of interviews in my career and have been responsible for a number of hires and I've never needed to rely on a take home project to access a candidates worthiness of the position. Maybe it's because I was interviewing/hiring for positions which I was intimately familiar of the required tasks and I knew the right questions to ask.

However, as a candidate I have to make assumptions on where to put my time, and if there is a take home test prior to an interview I’m likely to pass- while you are a super diligent company that carefully reviews all the responses to the screener, I’ve definitely seen those that aren’t, including companies kept taking screeners answers despite having no positions actually open.

There is an straight forward answer to this though- don’t send the take home work till after the candidate does the interview loop, or at least has a good conversation with the hiring manager. At that point hiring org has demonstrated a clear interest in the candidate and has put up “earnest money” to prove it. The candidate also knows if the position is something they are interested in. I’ve done enough hiring in the past to be confident that the interviews are more predictive of long term success anyways.

It would have been a lot cheaper not to have the take home project, but we decided it was worthwhile anyway.

(Disclosure: our project looked a lot like a story you'd be asked to work on in your first week with us. There was none of that "hiring for a Python backend engineer; here's a Scala data engineering project" nonsense.)

Yet now the candidate has no luxury of that, and has to guess the assumptions required to not just produce all the features, but also the quality metrics the project will be measured against. All in the deadline given by you. And he is at day 1, and that's all the day they have.

This is really like expecting some one to fix a problem in a day, what the other person spent months solving.

What ensues is actually comical. During "grooming" sessions the "programmers" are meant to give accurate estimates of how long (I know time is not meant to be the metric but it always is) a story will take to complete. A story which there are many, many person hours of context baked in that the "programmer" is seeing for the first time.

Context is worth 80 IQ points --- Alan Kay.

I'd consider this to be pretty important for a salaried position.

The place I'm at now asked me if I wanted to come in and code as round one of interviews or code up a little something on my own time for a couple engineers to review.

For me, it was a no brainier to code at my comfy desk at home for a few hours. Going into the city would have been an hour each way and about $50 worth of gas and tolls. I would much prefer not to bother with all that unless and until somebody has looked at my work closely enough to decide they are interested.

The time you spend on-site grinding leetcode with some Google engineer is non-paid as well, so let’s not pretend it’s really any different.

> Oh you've been working in a relevant field for 10 years? Here take this written test first, so we can check how well you can memorize hundreds of random irrelevant algorithms...

I'd walk out, unless it was maybe some simpler algorithm that you can actually figure out yourself by thinking for a few minutes.

I was under the impression that pretty much any FAANG interviews will have significant data structures and algorithms components and/or whiteboarding over Leetcode-like problems. Maybe I am wrong on this.

Outside of FAANG, I've found it's hit or miss, but the smaller the company the less likely you'll have to deal with bullshit hiring practices, at least that was my experience.

> Oh you've been working in a relevant field for 10 years? Here take this written test first, so we can check how well you can memorize hundreds of random irrelevant algorithms...

Yeah, and it's even worse if you don't have a formal CS degree. People always say that it's important to know data structures or algorithms or Big O-complexity so you "don't do something horribly inefficient in production", but in retrospect, I haven't had many problems with performance in real life. When I did have problems, it was usually fixed by modifying a SQL or ORM query. Once I fixed someone's major performance issues just by recommending installing a different package to generate PDF's.

I seriously doubt anyone needs a computer-science degree and deep low-level data-structures and algorithms knowledge unless they are going to be writing databases or compilers or designing programming languages. Most of the time, some common-sense and a handful of "good practice" coding/software eng. rules will do the job.

Disclaimer: I work on typical web/server applications. I'd probably have a different opinion if I were working on life or death software, e.g. medical device software, airplane control systems software.

Had done the normal initial phone interview (overview of experience etc), a take home code challenge (only took ~1hr) then I was asked to come in for a final interview that was to be a 15-20min presentation on project I'd worked on (that related to what I would be doing at the new role) then 15-20min of questions on that project and the technical challenges/solutions. All this sounded great until I got an email the day before informing me the presentation and follow up questions would be ~20 mins total and then there would be a 20 minute whiteboard session on data structures and algorithms.

I retracted my application asap!

Are you sure they didn't just try to steal intellectual property of your last employer? ._.

And yep, many people do have other jobs. Some take vacation time and others do nights + weekends.

I have a family and personal life, I am not going to try out a few employers until I get the right one.

My employment contract also forbids working in other businesses at the same time, vacation or not.

A company that must rely on a take home project to get a meaningful assessment of your worthiness and competency for a position is a huge red flag.

Any engineer worth their salt can tell from an on sight interview if a candidate is bullshitting about their past accomplishments.

The same lack of understanding/appreciation can be felt in some jobs, but a change might be good?

Ultimately I'd work at a garden centre or something and be outside more, but the pay would be less ! In any case, hope you have a plan.

I have so much to write it causes me to choke on my words but I'm telling you people are wasting their lives away and I'm sure not having it

It's cool you've also branched off into something a bit off the beaten path I'd love to compare notes if you'd be up for it

https://www.popsci.com/story/technology/mcintosh-amp-factory...

This is how software could be instead it's a joyless endeavour perpetrated by sexless beta humanoids at the behest of busy waiting plate spinners and their poorly invested overlords

We should value our work more than becoming human hamsters in a corporate machine headed nowhere at light speed

If you have 50 candidates do a takehome assignment, then you will need an engineer to do code review and write comments on everything. Whereas it's easier to execute the code and have an engineer glance at the code quality. Their time is better spent looking more deeply candidate's who move onto the next round. I'm not saying it's morally right, but it's just more time efficient for companies to do this and that's how the power dynamics unfortunately work.

This is why I don't do such things. Want 8 hours of my time? Pay me.

Why are you against naming and shaming the company?

I feel your pain, but doing this gets them nothing and costs them effort.

It might also be harmful. If the advice is "we needed more experience in X", and your reaction to it was either not apply for jobs asking for X (because you are unlikely to get them), or to get more training in X then that would be wonderful outcome for both you and the company. But as someone who has hired people, the most likely outcome is you are training someone on how to lie better about their expertise in X.

That makes this a win for you, a lose for the company doing the hiring. In my experience that means it ain't going to happen.

You’d need to assume interview feedback is constructive and relevant to your professional growth, interviewers are well-trained, interview processes are fair, and candidates receiving feedback are capable and willing to act positively on it. From my experience, having all of these factors be true isn’t all that common, and one of these factors is beyond the company’s control.

The issues I have with this point of view is it's very short-sighted. Word travels. If people have a shitty selection experience when they apply to you they'll tell other people about it. That will impact your ability to hire the best talent. It's to companies' benefit to provide a good experience during the selection process, and that includes giving feedback.

They should have.

And there is less risk in assessing a piece of work you paid for.

I've also seen good reviews on Glassdoor from candidates who weren't hired but were given prompt and appropriate feedback.

You should. Does it look like they give a fuck about you? Who are they?

You know if someone you don't remember from an interaction ages ago emailed you to say "Hey, you probably don't remember this, but you once told me $thing, so I took $action, and now I've achieved $outcome. Thanks you for that, it really helped my career!", it'd make you feel great and would probably be the highlight of your day, right?

I remembered the person, but not anything about what I'd said that day. I assume it was just what I normally say. Having that last realization made me feel even better.

The easiest, most rewarding thing you can do daily in your life is appreciate the people around you. We all need that feedback.

I'd like to second that. Do it!

A few years ago, through some bizarre corporate scheduling (and turnover) accident I ended up interviewing almost all prospective interns and university hires at $work for a couple of years. I must have talked to a hundred second, third and fourth year students every spring, and at least twenty or thirty other people throughout the year. I definitely don't remember all of them, although I sure wish I did.

Since these were literally people who were still in school, I always gave detailed and constructive ideas for improvement. I always suggested things to read or what projects to look into, even to people who did very well on the interview and ended up being my colleagues. It wasn't some grand gesture -- these were young people who were still in school, so all I had to give were entry-level suggestions (read this chapter in this famous book, try this program, work on your understanding of these concepts) that any experienced professional in my field should be able to give with zero effort.

Lots of these young folks wrote me back after some time (mostly via Linkedin but one of them specifically came at the office to see me when they got hired by a company which had offices in the same building). Every time I see one of these messages I get the happies, even if I have no memory of ever talking to that person.

(Edit: FWIW, I often don't, but I understand the asymmetry here. Lots of us remember the first few interviews of our careers.)

The software industry has fewer and fewer islands of sanity and human decency. If you ended up on one, you should make friends with everyone you can, and if you appreciate something they did for you, you should let them know. The professional climate of our days rewards narcissism, arrogance and pettiness to such a degree that lots of things that would otherwise look tacky are viewed in a very different light. As the great philosopher and musician Sting once put it (maybe he stole it from somewhere though?), at night, a candle's brighter than the sun :-).

This also made my day because I saw the real-world impact of something on HackerNews. And perhaps it will make your day to know your comment has influenced more people than the poster you were replying to.

If he didn't remember you before, he'll remember you after. I've given thousands of semi strangers advice in various forms. I remember the two or three who followed up with me and said, "thank you for your advice, I followed it and have since reached my goal," and have kept in touch with them. It makes you feel really good to hear that.

What I’m getting at is, there will always be bad apples, or people who react in a way that damages your organization. But not providing useful feedback to people who ask for it simply because one person went crazy is punishing a lot more people because of that one. Who knows if all of their negative karma ends up being worse in the grand scheme of things?

I personally avoid applying to places that other engineers tell me to avoid because I trust their opinion more than I trust a company selling me the highlight reel in an interview. If a trusted engineer said he got a rejection in an interview, asked for feedback, and none was given, I’d avoid that place too.

They don't have to provide feedback, so they don't have to take the risk if they don't want to.

Don't really think your comparison was fair.

Most people, ESPECIALLY people who ask you for feedback, do not want feedback. They want to get in a fight with you.

Edit: I don't remember ghosting anyone personally in either setting, but it's happened to me plenty. Getting upset about it just means you're new to the experience.

The data I've seen suggests you're totally wrong about this.

I work at a company in the recruiting space. My primary role is interviewing technical candidates, and we provide very detailed feedback to candidates of all levels, regardless of whether or not we move forward with them.

People consistently tell us they love the feedback that we provide - in fact, people say the feedback we provide is one of the best parts of their experience with us.

Detailed feedback can mean a lot of different things. Recruiters always think they're giving people detailed feedback. That's nothing compared to an honest code review.

Bearing in mind that code reviews often cause tension even in fully employed people, it's hard to imagine they're always well received by job seekers.

The application process was partially automated, with multiple human reviewers that provided detailed scoring on the applicant’s performance.

Initially, we provided a score breakdown to applicants, but we turned this off within a few weeks after a cascade of hostility.

"Based on our interview we think you would really benefit from studying up on data structures and algorithms. If you want to study this stuff on your own, many people find (link) and (link) useful. But there's also (link) or (link) books available on amazon that we've had people recommend."

Or: "We were impressed by your spoken communication skills, but sometimes you seemed to struggle to remember specific technical terms for some of the concepts and areas we discussed...."

The feedback emails themselves are assembled from a mix of interviewer notes and reused snippets for comments we give frequently. This sort of stuff has been very time consuming for us to prepare. At the volume of candidates we interact with, we think its definitely worth it. But its possible that no feedback is better than bad feedback, and most organizations might not have the time to write good feedback to candidates.

But I can say with confidence that almost everyone really appreciates the feedback we send. While its easy for senior people to find work at the moment, there's lots of junior people out there sending dozens of resumes for every call back. Receiving rejection after rejection from companies (or worse, being ghosted) without even being told what you're doing wrong is a really awful experience.

I've been interviewing candidates for more than 15 years (for PhD /RA positions and then for Engineering) and every time I've given honest feedback, candidates just get into an argument on why they think the feedback does not apply to them...

It is just not worth it. If I want to know how am I at certain skills... I test myself in a less "charged" environment.

They want to explain themselves. There is a difference. What you consider an argument or fight is just a Hail Mary, almost an involuntary recovery attempt, for some.

Accepting feedback without trying to dig your way out of a hole or justify your actions is a sign of maturity.

Once you've been a hiring manager and reviewer long enough, it becomes obvious that, while the intent behind giving feedback is good, the reality of it is messy, and provides no consistent upside to the company.

How did I find all of this out? Over A month later, they called me back.

This was after I had been strung along by the business owner and the guy that interviewed me for over a week where they were going to make a final decision about hiring me..and then nothing. They couldn't be bothered to return my phone call or respond to any emails.

They left a message that I had to schedule an appointment with the guy that interviewed me to basically interview me again.

I, of course, never called them back, but sent both of them a nasty email telling them to fuck off in so many words.

I never thought I would be ghosted like this from a potential employer.

Get used to it. It sucks but if I got upset like I used to when a company ghosts me (I'm not just talking about after initial phone screens but even after lengthy on-site interviews), I'd be dead from the stress by now. It happens so often these days. Some companies behave decently but it seems that many more companies are following the lead of recruiters and behaving like jerks.

I'm sorry but that's just ridiculous: we give every applicant we speak to feedback and not once has anybody "got into a fight with us".

Here in Texas, at least, that sort of thing does not seem like something that would ever be a real legal risk. This is a right-to-work state; I figured it’s pretty hard to get sued here.

The advice you will get on HR side is because no binding arb. agreement is in place you are exposed to full litigation efforts including attorney fees.

These can involve disparate effect or implicit bias - which can be difficult to defend against.

> Most candidates finish the coding section in 40 minutes. You took 60 minutes.

> In the system design part of the interview, the candidates we hire talk about SLA requirements.

Facts. No interpretations.

I am not even telling the person what they should do.

A good typical whiteboard interview naturally includes hints, feedback, and collaboration. After several hours of it, we have a very good idea of how well they may respond to feedback from members of our organization.

Honestly, I love giving feedback. I love helping candidates be better at interviewing. Bad interviews are painful to the interviewer too. I'm out of a small market so people and word gets around.

If it really isn't their fault they didn't get the job, we try to make that very very clear. It really sucks when we have to pass up on someone who absolutely killed the interview because someone else did better.

The harsh reality is, many people that don't pass on the interview are people we do not want in the industry. The good ones we give every hint and help we can.

There's also more tactical ways of extracting feedback from companies rather than directly asking for it. We can't tell you about how you did well after rejection, but we can talk about what our expectations are during the interview; put two and two together. I've noticed the good candidates that are serious about improving their interviewing do it, and from the company side, it's a strong signal they're not trying to contest a decision.

Food for thought, when was the last time you gave a company feedback on their interview process? I've traded feedback for feedback quite successfully many times when I was interviewing.

Interviewer: you have great interpersonal communication but I think you need a bit more knowledge in python techniques XYZ. I like being up front and transparent, and the python stuff is a big deal to us, so although you had a great set of traits, we want someone stronger in python.

Me: Thank you for giving me a clear indication on what was important, where I was strong, and most importantly, for not giving me a “we’ll call you if we want to move forward” response. I highly respect you for not wasting my time unnecessarily.

It's pretty bold of you to claim your interview can accurately qualify candidates across the entire industry.

Maybe you have found an interview that works for most companies? There's chests of gold waiting for you if you have.

These are the candidates that can't FizzBuzz or even write a line of code and/or are humongous asshats.

So, your employer does give feedback to candidates on request? It must be difficult for you to find places that are acceptable to you to work, since very few companies typically give feedback. Or do your friends just not usually ask for feedback and as a result that clause on your criteria never trips (i.e. the company wouldn't have given feedback, but since your friend didn't ask, you don't strike it off your list)?

    Hot take: you could hire someone who did absolutely well in the interview, and they could find a few weeks into the job that they loathe everyone, and go on a social media rampage.