Fuck! I am never gonna get hired again. I fucking suck at live coding. My mind just fucking gets blocked. On simple shit like arrays. I still suck at regular expressions though. Fucking failed Amazon and now wayfare.!!!! Fuck my fucking god dam life.

If it's any consolation I can't live code for shit either. I think it's a fairly common thing. Who sits and talks out loud while coding normally? Or have someone drop by their desk and be like "implement this function right now!"? It was just a bad interview, doesn't say anything about your skills. In fact I'd say it says more about the company, using shitty interview tactics that will never give them an accurate picture of the person they're interviewing. Here's to hoping the industry as a whole will bury that whole practice soon.

I don't think I could live code either. Usually, I'd look around in the source code, trying to get orientation. Then grepping (Notepad++ "find in files"), looking here and there and piecing things together. For an outsider, it would look totally erratic. On the other hand, I've never had to do live coding anyway.

Live coding is the most stupid thing to do...

I can write code from my mind, yes. But still make mistakes after more than 15 years in PHP.

The better way would be to ask for pseudo code or a description.

When you can give a solution like....

To solve this, I would need to apply a function to all elements of the array, collect the specific values in an array based on .... (and so on)

It's more than obvious that you could turn this to code.

And - especially in Frameworks / existing solutions (projects) you will need time to adapt. Every large codebase is like a new programming language...

Noone should ask If you can write in something that's unfamiliar to you in an interview.

Coding is half of the job, thinking and tinkering a solution the other.

One can be learned, the other requires a certain amount of ability.

The best coders are those that cant live code. Because they are forced to think about it harder.

Live coding. Timed coding. Algos. I’m fucking trash so don’t worry. You’re not alone.

I’m a builder

I mean I can code live, but only from pieces I have rehearsed multiple times because i have to type it often. But it's something you just fuckin cant do. What I struggled with big time in school is contextless coding. Like write function x for interface y that does this and that. And I am like cool? But can i use this library? Does this need a flag? Is this even good practice? And then I internally reee really loud.

very common thing bro, rehearse on your own, live coding for interviews is jorrible anyways, pressure makes it harder to code

I faced the same problem. Then the below stuffs worked for me.

Forget the other person is there and if he talks, think as if your best friend is talking to you. Think as if you are explain to him why you are making the changes.

Best tip always speak out loud what you're thinking even if it's dumb shit minus the cursing part - they are always trying to know understand your thought process.

Worst part: I developed a habit of muttering while I am coding at work.
I think it's a good thing

My advise would be not to write code, well at least not until it's a last resort.

Live coding is pretty similar to whiteboarding in the terms that it exists to test your problem solving ability and coding habits / style not your ability to memorize arbitrary syntax. So when I interview and ask a dev to write some code it's more about checking that he can work through and solve problems without help, has some kind of coding / indentation standards and doesn't name variable "x" or "foo".

My advise is

1. When speaking, talk them through your thinking as if it's a dev coming to you for help.

2. Talk through the problem first and mention any potential caveats or upsides of possible approaches. Pick the simplest approach in terms of time and loc that will work. If it's a little sketchy or won't scale make it known and explain that you have chosen your approach for time constraints / demo purposes move on and solve the initial problem you were asked. Unless you were asked to write scalable code or a solution with 0(1) it's not part of the problem.

3. Walk through the problem again, this time adding comments or pseudo code for each step needed to solve it.

4. Finally write the code. At this point they already know if your a good candidate and your in as long as your code style doesnt make them cringe - focus on structure and clean variable names. If you can't remember the exact syntax to map an array or split a string usually no one cares because it's obvious that you know the data type and it's common methods and your interviewer will usually help you along.

Most candidates I hire don't get far enough to compile / test the code because I already know are skilled enough between 2 & 3 so I stop them after writing a few lines and move on.
Most who do finish coding I don't hire because I was either curious if their crap would actually compile or they took far too long and I didn't want to demoralize and stop them.