41–50 of 161 posts
I'm tempted to run the job interview myself and instruct them on how to properly assess and interview developers, and then go ahead and interview myself for the role with them watching on.
But of course the outcome of that would be a rejection for insubordination - "not a team player".
You can't win so you just have to shut up and hope that some random series of events will get you a job.
Perhaps a bit of an unpopular opinion but as far as interviews go, I think that seeing how someone reacts unprepared is a lot more valuable then seeing their work with them knowing what to expect. You see their ability to adapt and improvise, which is far more valuable then being picky about a particular library or technology. Yes, the quality of their tests will be lower, but that's fine and you can take that into a…
It's a pity job interviews aren't generally better run. I'm tempted to run the job interview myself and instruct them on how to properly assess and interview developers, and then go ahead and interview myself for the role with them watching on. But of course the outcome of that would be a rejection for insubordination - "not a team player". You can't win so you just have to shut up and hope that some random series of…
Earlier quoted context omitted.
> We expect you to use git, commit code as you go along, and build the app iteratively -- just as you would during a normal workday. This seems a little bit odd to me. How long do you expect people to work on their home assigments in order for them to commit often? Is it days, or weeks? I don't imagine multiple commits for a 3 hour poject. For a new project there aren't any well defined states of the code that make s…
The exercise itself is a simple note-taking app with a couple of screens. We don't impose a time limit on candidates interviewing to complete this stage. > For a new project there aren't any well defined states of the code that make sense to be persisted. This means the commits will be arbitrary and their messeages not very meaningful. I didn't understand this? The problem is well scoped and defined. Regardless of wh…
One is to make disciplined incremental progress: write a test, make the test pass, do minimal cleanup, commit, see a refactoring opportunity, do it, commit, write another test, see a related bug, write the bug down but don't fix it, make the test pass, clean up, commit, tackle the bug, commit, etc.
The other is to flail about wildly until you have something which more or less works, and then commit it. Then make a few follow-up commits fixing bugs.
People who have only experienced the latter will find the idea of making numerous commits during the day absurd.
Earlier quoted context omitted.
It is not expected to be 3 hours project. Target easily 3 days for it. Requirement to get more points for this assignment from that page: “Detailed documentation with setup, screenshots, configuration instructions, etc.” This alone might take couple hours.
You expect candidates to spend 20-30 hours on a task, and you don't even guarantee an interview? Talk about exploitative. Hell, that's incredibly biased. Can you imagine a young parent being able to do that?
It's a pity job interviews aren't generally better run. I'm tempted to run the job interview myself and instruct them on how to properly assess and interview developers, and then go ahead and interview myself for the role with them watching on. But of course the outcome of that would be a rejection for insubordination - "not a team player". You can't win so you just have to shut up and hope that some random series of…
I usually ask for feedback on the interview process from the candidate. Not sure how common this is.
I'm yet to encounter a company that thinks their interview process is anything but awesome. Companies really aren't interested in feedback. This is human nature - pretty much anyone, when given "feedback", it is taken as criticism and the status quo is defended and the feedback disregarded.
Companies who say they want feedback I think like the idea of asking for feedback but not acting on it or internalising it.
If a candidate was not good enough for a job with a company, why would they be qualified to advise that company on how to improve?
Don't believe me? Run an experiment - next time a candidate is rejected, ask them to give feedback to other members of your team, and in the unlikely event you get considered feedback, observe what happens to that feedback - don't intervene - just do the experiment to see whether the above assertions are correct or not.
Also get feedback from candidates, especially rejected ones. The people who get offers will assume that the process works, since it validates their self-worth. Even if the process is very stupid. I've had processes that were so so bad from top companies. Like "here's a repo, clone it, write a program that will be judged by automated tests that you can't see". I had to basically guess what the tests were going to do,…
I think it's instructive to look at this from the other side to see why these processes exist. At my last job, I wanted to hire a frontend engineer with some experience beyond tweaking HTML and CSS (we used gRPC/Web and Typescript, so some actual programming experience was going to make them pretty productive, and that's what I was looking for). Anyway, I wrote up a req and posted it to the usual career sites, and wi…
If you have written your job description tailored to the ideal candidate you would have had a smaller candidate pool and a better match to the actual job.
Earlier quoted context omitted.
I think you've just failed that part of the test. If you've got more than an extremely simple project there are multiple point s where you should commit. If you implement a piece of logic with passing tests, then commit. It takes seconds to do but makes reviewing so much easier.
Or the company failed to attract the most suitable people for the job. As I said - I don't see a reason for multiple commits for a few hours project. It is not how people start a new project. This is an exploratory phase, you check this, test that. Very often it becomes a mess. Eventually your idea of the project gets clearer, then you clean the code, or start again from scratch. I don't see why these steps need to b…
I have had interview projects that were much more open-ended and exploratory, and there, i would not expect to be cranking out neat atomic commits. But i don't think that's what they are doing here.
Earlier quoted context omitted.
I think it's instructive to look at this from the other side to see why these processes exist. At my last job, I wanted to hire a frontend engineer with some experience beyond tweaking HTML and CSS (we used gRPC/Web and Typescript, so some actual programming experience was going to make them pretty productive, and that's what I was looking for). Anyway, I wrote up a req and posted it to the usual career sites, and wi…
I am sorry but this tells me exactly one thing: that you don't know how to write a job description. If you have written your job description tailored to the ideal candidate you would have had a smaller candidate pool and a better match to the actual job.
"How to Apply to All Jobs on AngelList (Script)"
https://alejandrorioja.com/how-to-apply-to-a-lot-of-jobs-on-...