Earlier quoted context omitted.
>Interviewers kept on saying things like, "I managed to pick out enough of the right words that he probably answered me, but I wasn't sure." Did it ever occur to them to ask "Sorry, could you repeat that?" Sometimes it takes a bit more effort to understand someone, whether it's because of an accent or a speech disorder or whatever. As an interviewer, you're in a position of power, and you have an obligation to put in…
Have you really never been in this situation. I have, several times. Yes, of course i ask the candidate to repeat what they said. And again when i don't get that. And again. Varying my question a little too see if they'll say it differently. I'll go about 5 times before giving up and either moving on to another topic in the desperate hope that it's the specific words that are the problem, or switching to a chat chann…
I know why rejection emails suck – I write them
401–410 of 426 posts
Re: I know why rejection emails suck – I write them
#402Earlier quoted context omitted.
> What do these people do all day, if not design and build software? Indeed this is a fascinating question, and I explored it a few times. Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling.…
How do I stop being a bottom feeder?
Pick up a good introductory programming book. I recommend Think Python 2e:
http://greenteapress.com/wp/think-python-2e/
Go through it cover to cover and do all the exercises. All of them. Don't skip a single page or exercise, not even if you think "I already know this", and certainly not because it's too tough.
Once you're done, you should be able to start applying for jobs in whatever language that book taught you. If you're still not passing interviews, take on a serious - but manageable - programming project, such as some simple application for yourself or someone you know. If you're a web developer, a simple dynamic database-driven website is an excellent choice. If you want to do front-end, a simple Javascript game will teach you a lot.
You don't always have to apply for new jobs so early. Lots of tech shops have some teams where actual programming happens, even if most of the rest of the company is "paint by numbers" pseudo-programming. Often you can start to take on more responsibilities that involve actual coding if you show the necessary abilities. You won't have to change companies, or even change teams.
Good luck!
Re: I know why rejection emails suck – I write them
#403Earlier quoted context omitted.
This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?
I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over t…
> the ability to read code
How do you test for that in isolation?
There are exercises that do that: you show the candidate a piece of code, and ask them to find the bug. They have all the worst issues that folks here are complaining about, amplified: stressful, awkward, etc. In my experience these types of exercises are also more random: i.e. depend more on luck. Sometimes great candidates fail them, and poor candidates get them right on a fluke. So they are overall less indicative.
Ultimately, though, it's back to the first point: how do I test if the candidate can do their job, i.e. code?
A candidate may communicate really well, say all the right things in best-practice questions like the one you mentioned, write well in English, but still unable to code their way out of a matchbox.
Re: I know why rejection emails suck – I write them
#404Earlier quoted context omitted.
Hiring has become such a litigation-prone Where? I've never seen anyone sue a company for not hiring them, and no company I've ever worked at has been sued for not hiring someone. If it was litigation-prone, I'd expect to see some litigation. I don't work in the US; maybe this is a weird US thing? Maybe people who do work in the US can give us some numbers? What proportion of companies one has worked for have been su…
It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court). But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"
If everyone is so cautious about hiring for fear of litigation, do they still happen? Since everyone is so cautious.
Re: I know why rejection emails suck – I write them
#405Earlier quoted context omitted.
This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative? My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks. How else do I figure that out, if not by a coding exercise?
I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult. Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over t…
Interesting, and I won't look up the article again before writing this comment.
I remember it as saying he was having a hard time finding people that can code at all, that a FizzBuzz is weeding out a large percentage of applicants. I don't recall it as a gateway to move on after.
Re: I know why rejection emails suck – I write them
#406Earlier quoted context omitted.
We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient. It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then…
> they’ve just shown that they’re not going to be able to write clean code unsupervised. The opposite, shown they can’t write supervised under the gun, which never happens On the job.
I think I can do okay in coding interviews, but only if I prep for that style of work first. It's definitely different. I'm perfectly (or at least acceptably) competent in my day to day.
Re: I know why rejection emails suck – I write them
#407I believe that the article is fundamentally wrong. The bulk of the article is true. But companies are not lying when they say that legal risk is a reason not to send feedback. Triplebyte is in the unusual position of being able to say, "Everyone who has enough technical skill gets through the interview." And that fact is sufficient to defuse their risk. But real companies don't have the luxury of ignoring non-technic…
On the point of legal risk, I’m concerned by the authors naïveté in believing that as long as you’re not actually discriminating based on race/sex/religion, you won’t be accused of it. The more data you put out there, the more likely that someone will crunch it and find some statistical patterns that they will label “racism” or "sexism". Even if you’re innocent, you will get dragged through the mud in the press and m…
I've noticed you've used "guy" 185 times in the past 5 years, but only used "girl" 58 times. This is a statistically significant difference. You will hear from my lawyers.
Re: I know why rejection emails suck – I write them
#408Earlier quoted context omitted.
It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court). But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"
So are they real? No numbers, no talking about it, just people in HR saying "No no, I promise you, they are real!" If everyone is so cautious about hiring for fear of litigation, do they still happen? Since everyone is so cautious.
Anecdotally, call centers seem to be a particularly good source of interesting HR lawsuits.
Re: I know why rejection emails suck – I write them
#409Earlier quoted context omitted.
Actually, no. You're referring to the Americans with Disability Act. What it requires depends on the "essential duties of the job" and what is consider a "reasonable accommodation". Those are judgement calls. Those judgement calls need to be made by executives on the advice of HR. My lay understanding is that the law does not insist that the job requirements change. So if being able to participate in design meetings,…
This is a really weird argument. It seems unlikely that you would succeed in legally justifying excluding deaf people from your team based on the idea that verbal communication is an essential duty of a software developer, which is the analysis that would likely be used against you. Also: if your management decided to exclude deaf people from your team, wouldn't you quit? I would quit.
As for protesting choices that you don't like by quitting, that is your right. Speaking personally, deciding not to hire someone because you believe that they will be unproductive in that role seems to me to be a perfectly reasonable thing for a business to do. And I don't see a moral distinction between different reasons why someone is expected to be unproductive.
Re: I know why rejection emails suck – I write them
#410Earlier quoted context omitted.
We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient. It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then…
> they’ve just shown that they’re not going to be able to write clean code unsupervised. The opposite, shown they can’t write supervised under the gun, which never happens On the job.
I don’t think it’s reasonable to say that people’s problem solving skills (which is what we’re actually testing) become exponentially less efficient during an interview. But even if it was, the test is still doing it’s job, because what would we expect to happen when we give a person like that a deadline, or ask them to review a PR?