Live data from Hacker News

No engineer has ever sued because of constructive post-interview feedback

blog.interviewing.io

481–490 of 646 posts

Re: No engineer has ever sued because of constructive post-interview feedback

#481
post #335

Earlier quoted context omitted.

If they're dissecting it at that close a level, it's probably not a company you'd want to work for anyway. At least how I judge take home tests (for a simple backend CRUD app spec), I'm definitely not disqualifying based on surface level details like that. I don't even bother running it on my machine most of the time. What I'm looking for that it doesn't have obvious SQL injections (I've seen this a depressing number…

There are plenty of things in what you wrote. For example, My assignment was to build a command line app. The spec given said nothing about how bad inputs should be handled. How should they be handled? No Op? Throw exception? Friendly error messages? How? 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 t…

> In 24 hours?

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/',
                    view_func=PostResource.as_view('post'))
    docs.register(PostResource, endpoint='post')

    app.add_url_rule('/posts//comments',
                    view_func=PostCommentResource.as_view('post_comment'))
    docs.register(PostCommentResource, endpoint='post_comment')

Re: No engineer has ever sued because of constructive post-interview feedback

#482

I'm so disappointed to read comments on this thread to the effect of "There's nothing in it for the company but risk". 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 ze…

You probably wouldn't like the feedback. Most interviews these days are random because our field is obsessed with finding 10x megarockstar GTD superprogrammers. I can't think of a single field where interviews are such awful experiences. 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 g…

If you can do this effectively you will beat Triplebyte easily. You're missing out on millions of dollars by not doing this.

Re: No engineer has ever sued because of constructive post-interview feedback

#483
Personally I'd rather not know, unless I do. Process of receiving feedback can be awful. In a hiring role (done that too) I'd rather save people the embarrassment of a dressing-down. I wouldn't want for them to bear more resentment towards the company than necessary.

Re: No engineer has ever sued because of constructive post-interview feedback

#484

Earlier quoted context omitted.

I can't find the article because its hidden behind Google's previously admitted coin flip, brain teasers. 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 tak…

I simply have to disagree. The amount of unqualified candidates that have a decent CV and are reasonable to talk to, but completely unable to correctly write a while loop is too damn high. That is what my whiteboard questions filter out. They're super easy stuff such as "I give you as input a list of integers, return the index of the first consecutive pair of numbers that when added is 42 - you can use any language o…

> The amount of unqualified candidates that have a decent CV and are reasonable to talk to, but completely unable to correctly write a while loop is too damn high.

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.

Re: No engineer has ever sued because of constructive post-interview feedback

#485

Earlier quoted context omitted.

> 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. bulletsDodged += 1

Real programmers would write bulletsDodged++;

Thing is, that's not valid Python - but the OP's version is ;-)

Re: No engineer has ever sued because of constructive post-interview feedback

#486

Earlier quoted context omitted.

This is a tried and true practice in dating, and it translates well to hiring, which is basically the same thing. 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.

Then maybe there can be a system that provides a disclaimer where they waive all ability to sue or otherwise get into a fight with you.

Are you serious? Imagine the first HN headline that reads "Company X requires you to waive your ability to sue if you apply to them". Come on, man. Apply some tests to your ideas.

Re: No engineer has ever sued because of constructive post-interview feedback

#487

Earlier quoted context omitted.

where did you get those figures?

I made them up.

Of course they're made up. That's why I asked.

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.

Re: No engineer has ever sued because of constructive post-interview feedback

#488

Earlier quoted context omitted.

> In Germany every single lawyer or HR responsible would tell you not to send any reason at all 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 laws…

Well, I have no trouble giving feedback these days because life's too short not to, but that isn't even an accurate description of the problem. 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…

What if the other 99 other places do the same thing because it's the new norm now? Do you stay unemployed?

Re: No engineer has ever sued because of constructive post-interview feedback

#489

Earlier quoted context omitted.

where did you get those figures?

I’m gonna go out on a limb here and say: they’re guesses, feel free to post better ones. Especially if it changes the conclusion.

So you are suggesting that (from their behavior) people are oblivious to the low risk/high reward indicated by those figures?

Or maybe they don't like assuming risks based on other's bogus data when they already have their version of bogus data that is probably closer to reality?

Re: No engineer has ever sued because of constructive post-interview feedback

#490

Earlier quoted context omitted.

I made them up.

Of course they're made up. That's why I asked. 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.

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

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?

Post reply on HN