Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

141–150 of 340 posts

Re: Ten years of experience, still failing phone screens

#141

Earlier quoted context omitted.

> There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven. You know how they made a program pass the Turing test? They didn't make it smart, they hardcoded a conversation where the program drove the conversation to where it wanted it to be. That way the person interacting with the program was passive, so they never noticed that they were just interacting with…

The person could have just learned to code in all that time spent watching conference Q&A sessions to con interviewers. This does seem to be the threat model many interview processes are meant to protect against though. I understand there are costs involved in hiring then firing someone, but maybe that should be reserved as a way to deal with the most outlandish fakers and let the rest of us have a quick Google or tw…

[deleted]

Re: Ten years of experience, still failing phone screens

#142

Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get another set of blog posts complaining how ridiculous his interview questions were. "Why is it bad to write a file to the disk one byte at a time?" What are they interviewing for, low level disk experts? "Here's a stack trace from an open source project, can you tel…

What are they interviewing for, low level disk experts?

Writing one byte at a time may be “bad” at many levels. First, on a hardware level it is inefficient because the unit is a sector/block and the access latency kicks in hard, together with a wear leveling on ssds. Embedded low level indeed. On an os/syscall level it is inefficient because of a syscall time itself. It is a system level touching C and unbuffered writes in “middle-level” languages/libs. On an application level it may be inefficient if a stream has a processing pipeline with some expensive setup/try/teardown (e.g. a jsonl parser which “tries” the buffer at every new chunk). Is this still low level?

This is a question about streaming, buffering and latency avoidance, which you may not know in hw detail, but have to have at least a vague grasp of. If a candidate seems confused, one may ask them about other situations where one-at-a-time may become “bad”: sql select one row at a time, fetch NNN items one by one, use heavy_expr().x, heavy_expr().y repeatedly or in a loop. If nothing comes to their mind, chances are you are interviewing a completely inexperienced person, because there is no way they didn’t meet that or think of that before.

I totally agree that it shouldn’t be the reason to skip a candidate, but hiring is an analyzing process, and how do you find their limit if not asking deep open questions? I think that the issue is pushing hard on these areas as if it was laughable for a professional to not know it.

Re: Ten years of experience, still failing phone screens

#143

Earlier quoted context omitted.

The person could have just learned to code in all that time spent watching conference Q&A sessions to con interviewers. This does seem to be the threat model many interview processes are meant to protect against though. I understand there are costs involved in hiring then firing someone, but maybe that should be reserved as a way to deal with the most outlandish fakers and let the rest of us have a quick Google or tw…

If you are smart and a hard worker then learning it properly is easier, yeah. But if you are lazy and prefers talking to people and watching videos, so you spend your day talking about these conferences with your colleagues rather than doing work then you have the scenario I'm talking about. It doesn't require some genius conman, basically any guy who prefers to talk about things instead of doing things will more or…

[deleted]

Re: Ten years of experience, still failing phone screens

#144
post #119

Earlier quoted context omitted.

> People who can write a program without any setup can solve it even on paper, As someone who had courses in C on paper, i can only say that it's a colossal waste of time. Tooling exists to make lives easier, gain time and productivity, why avoid it? It'd be like saying only the farmer who can do everything by hand without any tools increasing their productivity is a real one. Or an accountant refusing to use Excel/c…

> It'd be like saying only the farmer who can do everything by hand without any tools increasing their productivity is a real one. Or an accountant refusing to use Excel/calcuators/ERPs and writing everything on paper. You're trying to map manual work onto engineering. And absolutely I'd rather work with accountnant who can write me on paper without Excel/calculator/ERP his logic. It's like you're being obtuse just f…

When one of the mediums actively helps and avoids small human errors, I'd prefer the person knowing using it instead of sticking an old and imperfect method out of pride.

Re: Ten years of experience, still failing phone screens

#145

Earlier quoted context omitted.

> he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time If I was floundering because the interviewer found a hole in my knowledge (and there are many holes in Albert Hall) I'd proactively state that and say where the holes weren't and ask for a question about that. For example, I've implemented a complete C compiler, front to back, so at one point…

> There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven. You know how they made a program pass the Turing test? They didn't make it smart, they hardcoded a conversation where the program drove the conversation to where it wanted it to be. That way the person interacting with the program was passive, so they never noticed that they were just interacting with…

5 minutes isn't long enough to notice that the conversation switched topics every time you asked a deeper question.

If I accidentally hired a guy like that, I'd consider him for a marketing position. :-)

Re: Ten years of experience, still failing phone screens

#146
As Jensson points out, smart people can grind leetcode, so if you have good experience, grinding leetcode shows you're smart enough to get the job. If you don't grind, there's no signal of how good you are at coding, so it's a no hire.

Really, it's on you if you don't do what needs to be done to get the job. So get grinding! Or remain unemployed.

Re: Ten years of experience, still failing phone screens

#147

One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…

[deleted]

Re: Ten years of experience, still failing phone screens

#148

yeah and if you are an anxious person like me, (i may be on the spectrum, i have some social issues), writing code in front of people makes me very anxious, it takes me back to my childhood when my dad would scream at me for being dyslexic, i got my b’s and d’s mixed up. i know that is not what is happening during an interview but, it’s how i feel. and this prevents me from getting ahead in an industry i am madly pas…

[deleted]

Re: Ten years of experience, still failing phone screens

#149
About 11-years ago, I was in a bad shape after a disastrous Startup failure. I was looking for a job and out of many prospects, I had an interview with bookings.com. It started with a phone interview and they wanted to go technical right away; so started asking me the basics of CSS.

I was taken off-guard because I don’t remember what is the default value of float, or the list of default values for many CSS objects.

I explained that I don’t remember those as they usually pop up in the IDE when I start typing. However, if they want, I can show my open-source bare-bone drop-in grid framework I wrote sometime back or I can walk them through CSS Box-Model or even explain how I can help bridge the gap between designers and engineers.

Unfortunately, it ended as their time ran out. I got a rejected reply because I could not pass the basis of CSS on a phone call. That was the incident I promise myself that any candidates I interview in future will always get a chance to explain/prove their worth in the ways they know best.

Re: Ten years of experience, still failing phone screens

#150
> ” I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.”

That’s exactly what happens to me. The thing is, I am not as fast or experienced as the author. I don’t do well on those Triplebyte quizzes because they put data structures and algorithm question among even in the frontend quiz. And also ask trick questions that I usually run the code to see what happens, not spend 3 minutes imagining what the outcome would be. I much prefer take-home tasks even if I take 4 to 5 hours when instructions said I should take two.

So, I am just terrible at technical assessments in general. And I don’t have that solid CS knowledge that some positions require or people think is the minimum necessary for me to be called “engineer. I don’t care. I am happy being called a “developer”.

The challenge is: how do I find a job post that would hire for what I am good at?

I am good at shipping things. I am good at communicating with non-engineers in general. I am good at scoping, understanding the problem that people want to solve with code and proposing the fastest way to get there. I am good at creating simple code that it’s easy to understand and do what’s needed to be done with good performance. I am good at writing tests that make sense. I am good at focusing and organizing my time to deliver working code in the agreed deadline. I am good of delivering good work with autonomy. I am good at working as a team. I am quick to learn new tech. I am quick to understand legacy code and to improve it.

Despite my poor technical interview skills, I was never fired for poor technical skills. On the contrary, I was always complimented for what I ship, how quickly I learn and contribute when dealing with new tech/codebase, and how I quickly improve upon feedback.

So, how do I find a job whose hiring process value those, not the former?

I am considering not even trying if the process has a mandatory live-code step or leet code.

Post reply on HN