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…
Ten years of experience, still failing phone screens
141–150 of 340 posts
Re: Ten years of experience, still failing phone screens
#142Interviewing 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…
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
#143Earlier 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…
Re: Ten years of experience, still failing phone screens
#144Earlier 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…
Re: Ten years of experience, still failing phone screens
#145Earlier 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…
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
#146Really, 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
#147One 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…
Re: Ten years of experience, still failing phone screens
#148yeah 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…
Re: Ten years of experience, still failing phone screens
#149I 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
#150That’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.